subscriptions - optimistic updates

[jdgamble555]

Is it possible to do subscriptions with optimistic updates?

This is necessary as the DOM does not get updated until the subscription returns data back. Updating the DOM first, optimistically, would result in a fast, immediate, responsive app.

[JoviDeCroock]

Hey,

This sound a bit counter-intuitive, a subscription isn't meant to have a predictable result, it's more that you are subscribed to a certain entity like a chat that can have updates at any given time, this way you can stay up-to-date with you updating stuff in other tabs or another user sending a message.

What is your use case specifically for "optimistic responses" in subscriptions.

I understand the case for mutations where we know what we are changing, for instance we change a todo.title to be value y and we can change that in the cache before the server responds.

[kitten]

You're jumping the gun here a little. So I assume I've guessed correctly as to how you're using subscriptions. However, subscriptions are a terrible way to represent server data and can't be optimistically changed because they're meant to describe updates.

Queries always represent the data tree of an application and subscriptions are limited by the spec to not take on this responsibility. This is why you can only use a single field for subscriptions for instance; that makes it very clear that they're events and not requests. Also, that's why live queries are standardised.

The typical flow of applications in Graphcache, Relay, and Apollo is to send queries and subscriptions and mutations to update this data as the application is represented by a single "state tree" from the Query root type.

We've recently updated the docs on Normalised Caching and for large parts the same principles apply to all GraphQL normalised caches. It also lays out why these patterns are the way they are https://formidable.com/open-source/urql/docs/graphcache/normalized-caching/

However, what I think is more important here is that you're trying to force a conclusion onto us while we're trying to point out a problem with one of your premises. The premise that subscriptions may be used to represent server data state is simply incompatible with how the spec has been designed: http://spec.graphql.org/June2018/#sec-Source-Stream

If you take that on contrast to live queries, those are designed deliver updates to a query, which is a distinct difference.

Behind the scenes a normalised cache must be able to operate on a single state. If you start a subscription then there's no guarantee that a result will be available. Basically, can a cache deliver a result for a newMessage field? It cannot since the definition of subscriptions are event streams which are distinct from results.

The limitation here is inherent and purposeful. A subscription is defined to not have a single outcome but a stream of outcomes. If you choose to implement subscriptions by interpreting their events as a single updated outcome (which coincidentally is exactly what live queries are being defined to do) then you're subject to that limitation. For a normalised cache this could also mean that the source of truth is split. But this all would depend on the client interpreting every subscription as a single updated state, which isn't the case. This becomes more evident when considering that this limitation is also directly applied to documents for subscription operations as they're limited to a single field at a time.

Even these things considered, an optimistic result in Graphcache that's defined for a given mutation will actually update the cached data. Hence, it will update subscriptions or shared data that a subscription may also have updated. But there's no part in the specification that would allow us to synthetically create a subscription event. Instead, that's why it's common to combine a single query with one or more subscriptions. To keep the query updated via the normalised cache.

But as long as this premise isn't taken into account it would seem like your question could be solved; but rather it instead pretty much illustrates why live queries exist / are being standardised.

[jdgamble555]

Thanks @kitten for the detailed response.

So basically it is not part of the specification. I understand that.

subscriptions are a terrible way to represent server data and can't be optimistically changed because they're meant to describe updates.

While I do understand why you can't change the specification, I fundamentally disagree with this statement. I do not know the ends and outs of how the cache is intended to work, but your definition seems pretty clear.

I am perhaps suggesting a new use outside of its specification. If you think about the user on the front end, and don't get bogged down with the specification for the cache, you can see a real use to have the DOM update before the subscription returns the results... speed.

I believe this is why firebase chose to write their code that way. While they don't use graphql (as far as I know), they do use subscriptions to keep the data up to date at all times and update the DOM first before the database gets updated on the backend and returns the data. I believe this was a smart decision and shows why it is so fast and user friendly.

Ultimately it seems like a problem with the specification to me, as it limits the potential speed and usage of subscriptions (besides just notifications like messages etc.).

Thanks,
J

[tom2strobl]

@jdgamble555 Why you are comparing GraphQL subscriptions with Firebase over and over again is something I don't really understand if I'm afraid. Firebase has nothing to do with any GraphQL spec and we're in GraphQL userland here.
Also, Firebase is proprietary and thus in control of one hand, GraphQL isn't and therefore specs are very important to allow things like urql to even exist. Maybe also to add, @kitten is not talking about the the programming pattern of subscriptions but what the idiomatic term of "GraphQL subscriptions" means. 🙂

[jdgamble555]

Hi @tom2strobl - Basically because Firebase uses Web Sockets and optimistic subscription updates. I was not aware that the specification for GraphQL Subscriptions does not allow for updating the cache / DOM first for mutations before the subscription query gets the triggered results back. URQL and Apollo go by those specs, and I understand that now.

This whole post is to highlight the usefulness of updating the DOM (by means of the cache) for mutations before the subscription pulls the results back, which I believe is very valuable and makes apps more efficient and faster.

Again, not part of the specs, so I get that. My argument should probably be to change those specs...

[kitten]

I really don't want to revive this because as I pointed out before, there are some misunderstandings here re. the spec, since GraphQL live queries are around to actively push updates from the server to the client and subscriptions push "orphan" updates from the server to the clients for entities that aren't on the Query schema tree outwards. There's also nothing stopping anyone from implementing mutations over Websockets which we actually support