What is the common wisdom on how to received real-time data with an initial data payload? Say I want to query the current state of some data and then get subsequent updates with a websocket-backed subscription.
Using subscribeToMore(), the method is called sometime after the query is fired; so there is a possibility for data loss in the window between the query resolving and establishing the websocket connection. There’s also possibly data duplication if they resolve in opposite order, but de-duplication is more easily solved.
The same issue arises when calling query() and subscribe() imperatively on the client object because the subscribe() method is not awaitable. So while the connection is being established (I assume asynchronously even though it doesn’t return a Promise), the query can resolve quickly leading to the missing data window again. There doesn’t seem to be callbacks for the websocket connection’s lifecycle either (except, maybe, for middleware when setting up the Link). And even if there was, the spec has an ack for the connection, but there is no server response when initiating a subscription (which is a separate client → server message).
To me it seems like the only viable option left is to have the server return the initial data when initializing the subscription instead of a separate query. Essentially yielding this data first, and then manually iterating over the AsyncIterator. However this feels like an anti-pattern as subscriptions are supposed to just be for real-time events.
Is there a better option that I’m not thinking of, or a proper way to reconcile the network race condition between a query and a subscription?