Delay Subscriptions

Issues GraphQL
1

Currently, when subscribing per query like:

subscription {
   queryFoo {
      name
   }
}

The client will get the whole List of Foos when there is a change or an addition.

When someone adds/updates/delete a lot of these, this will generate a lot of traffic.

Can we specify some kind of delay on the subscription such that the dgraph server waits a given period and send updates only after that delay?

E.g. this would delay the data for 1000 milliseconds:

subscription {
   queryFoo @delay(period: 1000) {
      name
   }
}

I’m also linking this here, because I feel that unnecessary traffic is currently an issue with dgraph GraphQL subscriptions:

1 Like
2

I think this would be a Websocket Graphql thing, not a dgraph issue. Right now Dgraph uses subscriptions-transport-ws, hopefully soon they will upgrade to graphql-ws :slight_smile:

You could put a timeout when the connection is open, close it, and reopen it. However, I don’t see how this could be done as you’re asking. If you don’t need your data immediately, you need to re-ask yourself, why you are using web sockets in the first place. A chat app or active notifications would want every update. You might do better refreshing the data intermittently if you expect that many changes.

J

3

Okay, here is my scenario:

I have lots of workers. Easily up to 1000 but there is no real upper limit.
These workers consume data, do stuff with it and write back to the database. They should react as fast as possible when new data is present. The data is coming in burst events (i.e. someone uploads a bunch of images).

When implemented using queries (e.g. every 1000 milliseconds), you have 1000 queries per second (1 per worker). Additionally you have all the other queries, mutations etc. from UI and other services. This is not good at all and puts huge load on dgraph, nginx and whatever else is involved in that query.

Subscriptions transport only data when - well when there is data to be transported. But the nature of my data source (burst event) make it also unfeasable (unless I have some kind of delay option).

Of course I’m more than happy if someone has an idea for a workaround to this.

1 Like