Hi things are looking very bright for dgraph, before I forget this feature request eternally in my notes I just wanted to drop it here
@ All please add your thoughts about this implementation
INFO: current state of the dgraph subscription feature: it is just long polling, afaik. Also there is afaik no field level authentication. The authentication is being done on the node level. Also there is no DDOS protection. I overall recommend not only for the websocket solution, but also for the GraphQL/DQL endpoint, Cloudflare Load Balancer which uses multiple Cloudflare Tunnel (as i understood) Tunnel | Zero Trust App Connector
more info: Kubernetes Security & Performance ----- Cloudflare + Google Cloud Platform | Cloud Services ----- Cloudflare + GCP and this article Argo Tunnels: Spread the Load
check out this discussion for more
So, the feature request:
true websockets and not just longpolling. true websockets shall be enabled through subscribing to the replication stream. If there is none because there is no HA, the replication stream still shall happen, but since there is no HA-node to receive the replication, there’s no goal, it will go in vain. Like a water stream without a destination, or if you play alone baseball without having anyone to catch the ball. But that’s not a problem, we just need that there even is a waterstream, so that we have something that we can subscribe to.
this is basically the way figma built its custom solution LiveGraph: real-time data fetching at Figma | Figma Blog
But the question is now, how shall we handle the subscriptions? I think the best way is to have a dedicated App Engine instance with Elixir Phoenix Framework running on it (which discord and whatsapp use too) to handle the websockets. (dedicated because: this would also make things easier for Dgraph Cloud because of billing. Not everyone has high realtime usage and therefore needs no big App Engine instance and not even multiple ones. some people don’t use the websocket feature at all. Also maybe it’s better to encapsulate that whole realtime feature this way, since it is also Erlang VM and not Go anymore.)
Dgraph Labs would build the standard elixir backend with ddos protection (imagine a user asks for too much realtime stuff to ddos you up (use up your server power), and even creates multiple accounts to ddos even more, at least per IP address it would be able to limit him (but what about shared IP addresses (was it NAT?? too much time passed since I had that cyber subjects) - nevertheless this is what makes me unhappy with Firebase’s products “Realtime Database” and “Firestore” your users can ddos you a big $$$ bill, and if it wasn’t scalable your server would be done for, so we really need to be able to make some kind of protection against that and be able to tweak it, maybe team up with Cloudflare?? Theyve got a product called Cloudflare Tunnel and Load Balancer, i think dgraph needs the Load Balancer, here are more infos). we should be able to tweak a limit because everyone has a different app where more or less realtime usage is needed before it is called a ddos (well it isn’t really a ddos attack, it is more a “attack of using up your server” but I really dunno how to call it)) + token/Firebase Auth Capabilities with the custom claim capability. Oh and of course field level instead of node level authentication. When making a subscription, you get the initial field value, and then all updates (so the elixir backend basically subscribes to the RabbitMQ field, AND queries for the value in dgraph and gives you via websocket the current-actual value as the first value, and after that you receive always the newest value if it updates. This is the expected behaviour we want. E.g if you have an online shop app, for the current stock of an item,+ subscribing to it, you just make this websocket query to the elixir backend, he gives you the current-actual value, and then starts giving you the realtime newest value. What we dont want, or at least I don’t want, is that I subscribe to a value like a product-stock-value, and I get NO stock number back, but only if someone buys something and it gets updated; as some products are not popular and are bought only one time per day, that leads to that the user doesn’t see any number of stock at all because the websocket backend forgot to give you the initial stock number with querying the DB). This would solve 99% of all our needs. if someone has an extra need, he should be able to create a custom elixir code solution and replace it with the stock code.
For the communication part between the replication stream and the elixier backend, RabbitMQ or Kafka can be used.
Don’t burn me for dumb things Ive just wrote I am a noob 
this are just my ideas I wrote up
thanks and kind regards!
