Feature Request: Event-based subscriptions

Reopen of #1355 .

To inspect whether it is good to use event-based subscriptions or live queries, I’ve gone through many articles and found this comment best describes the current state of live queries and event-based subscriptions.

There are still use cases of event-based subscriptions, especially when performance count more than reliability (take an example of twitter like subscription)

Another thing is that, most subscriptions in the current graphql ecosystem use event-based ones. It will be hacky to convert an existing project with subscriptions to hasura.

The hacky part of using live query for event-based subscriptions is that

1. It will be difficult or at least not straight-forward to detect row deletion. #1201
2. It will yield unnecessary initial results.
3. Tracking update or create events need extra effort (adding updated_at columns to sort with, etc.)

cc: @coco98

[barbalex]

@heyrict One of the biggest challenges/decisions with event based subscriptions is how does the client recover from loss of events? Does the server store what events are delivered to clients? This involves maintaining state at the server (using something like a message queue maybe?) and becomes even more complicated when you bring in horizontal scalability of the subscriptions server.

We support live queries because they are easy to reason about, very expressive, extremely performant and the server need not store any state (in our implementation).

@0x777

The problem with live queries is that they always deliver all the information.

Say I have a table with 10’000 records. One of them changes. So the live query fires. Now my application needs to find out which record changed in order to update it client side. So it has to compare all 10’000 records!

If event based subscriptions existed, the client could:

• at startup: do the expensive comparison only once to ensure all data is up to date (actually the client only needs to query data changed since the last startup)
• start the event based subscription
• cheaply update only the changed records when events happen

This seems so obvious I am sure I must have missed something essential. What have I missed?

[bkniffler]

One thing I’ve found is, it is very hard to write a mutation that would optimistically update a subscription with apollo, or maybe even impossible, since apollo doesn’t seem to have build in mechanisms to automatically update subscriptions (using optimisticResponse) and there is no possibility to read/write subscriptions from/to cache. This must be due to the fact that, as @heyrict states, most implementations and even apollo docs use event based subscriptions instead of live queries.

Would love to see some workaround for live-queries + optimistic response, I couldn’t manage to get this combination to work with apollo.