So this is a problem that’s come up in both large projects I’ve used Absinthe/GraphQL with, and it’s a little bit surprising to me that I can’t find more people who strike it. But perhaps I’m just bad at googling or I’m missing some obvious angle.
The issue comes down to using GraphQL subscriptions for state updates. Take a simple example: user presence on simple IM server. When a client connects, they want:
a) The initial state (all of their friends and whether they’re online or offline), and
b) Notification of all changes to that state (when a friend comes online or goes offline).
Obviously a) can be achieved with a simple query.
The oblivious way (indeed, the only real-time GraphQL way) to do b) is with a subscription. Simple enough - fire an event when a user’s state changes.
So what’s the problem? It’s the intersection of the two. If the client issues the query first, then the subscription, they might miss an update during that gap and their view of the state will be wrong. Conversely, if you do things the other way around, they might get an update that was sent before their query ran, but with the multiple processes involved in Absinthe’s subscriptions there’s no way to guarantee that that will arrive before the query result (which might allow the client to trivially discard it), even if the authoritative data all comes from a single process. And that’s assuming the query is even sent over the same websocket as the query.
One way to solve this would be to include some kind of ordinal field (e.g. a timestamp) to the query and subscription data so that the client could discard subscription updates with an older ordinal than is attached to the query, and apply newer ones. And indeed that works fine and is what I’ve done to this point. But I really don’t like it - it shifts the burden of data consistency to the client when the server has all the data it needs to do it itself (self-evidently, since it’s the one generating the ordinal values).
The problem is, I’ve struggled for a long time to come up with a better system within the constraints of Absinthe and I haven’t been able to. Some of the approaches I’ve looked at:
-
Add a catchup function to subscriptions (see over in https://elixirforum.com/t/adding-a-subscription-catchup-function-to-absinthe/16363). In spite of being implemented, that never really went anywhere and in retrospect that’s probably a good thing because it doesn’t actually solve the problem above - it only removes the need for an extra query without avoiding the race condition.
-
Add some callback configuration to the subscription definitions which generate and compare ordinals from within the subscription execution. That ends up not working too because the subscription resolution is batched and as a result there’s no good place to shove the last ordinal value for each connection to that subscription which is accessible when it needs to be.
-
Do something similar with middleware and/or plugins - that ends up having the same issue as above: middleware and plugins aren’t executed for each connection.
As such I’ve kind of come to the realisation that the current Absinthe architecture probably can’t support what I want and at a bare minimum I’m going to have to start digging into absinthe_phoenix’s pubsub stuff if I want any chance of making this work.
So I guess my questions are: Am I missing something? Is this whole thing a fool’s errand and I should just let the client deal with it and get on with my life? Does anyone have any really clever insights I’ve missed?
Thanks!
I am still a bit new to GraphQL, but one approach to model this might be to construct a subscription for the union of the ‘InitialState’ and ‘DeltaOfChanges’ types.
