# Delay Subscriptions

**URL:** <https://discuss.dgraph.io/t/delay-subscriptions/13617>\
**Category:** GraphQL\
**Tags:** kind:enhancement\
**Created:** [April 9, 2021, 1:08pm UTC](https://discuss.dgraph.io/t/delay-subscriptions/13617 "2021-04-09T13:08:28Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![maaft](https://avatars.discourse-cdn.com/v4/letter/m/4af34b/32.png) [@maaft](https://discuss.dgraph.io/u/maaft)\
**Post date:** [April 9, 2021, 1:08pm UTC](https://discuss.dgraph.io/t/delay-subscriptions/13617/1 "2021-04-09T13:08:28Z")

</div>

Currently, when subscribing per query like:

```auto
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:

```auto
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:

> [@Subscribe only to updates](http://discuss.hypermode.com/t/subscribe-only-to-updates/11930):
>
> Ist it possible to subscribe only to new data? E.g. when subscribing via: subscription { queryFoos { id } } I get always the full list of all existing Foos. As this list can grow very large and I’m only interested in new Foos I also only want to get them and not all. Is something like this already planned? Something lilke this would probably do: subscription { queryFoos @subscribeChangesOnly { id } } Is there a current workaround?

---

<div class="post-metadata">

**Author:** ![jdgamble555](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/jdgamble555/32/7503_2.png) [@jdgamble555](https://discuss.dgraph.io/u/jdgamble555)\
**Post date:** [April 9, 2021, 2:14pm UTC](https://discuss.dgraph.io/t/delay-subscriptions/13617/2 "2021-04-09T14:14:42Z")

</div>

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** 🙂

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

---

<div class="post-metadata">

**Author:** ![maaft](https://avatars.discourse-cdn.com/v4/letter/m/4af34b/32.png) [@maaft](https://discuss.dgraph.io/u/maaft)\
**Post date:** [April 9, 2021, 3:05pm UTC](https://discuss.dgraph.io/t/delay-subscriptions/13617/3 "2021-04-09T15:05:17Z")

</div>

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.