@sorenbs @nilan another topic: about data races that no one seems to be talking about. I have already presented this concern with @nilan but haven’t received any response yet. May be this is probably because of my less experienced GraphQL self as well, but looking at the Subscriptions, wouldn’t there be a possibility of subscription loss between the first REST API call to get initial data, and subscribing for more? I mean, this is a problem at the GraphQL protocol itself if I understand well, unless there is a Live Queries 100% over WebSocket. The time between these 2 calls can easily be 300 ms in my case, and a lot can happen in 300 ms.

@eliezedeck I believe I got back to you about that already. A pattern to tackle this is to first setup the subscription and then do the query. If new data arrives before your query is finished, you can merge it correctly on the client side. Would love to hear your experience wih this

@nilan ah ok... I think I missed that. Thanks.

Hah I highlighted the wrong person: https://graphcool.slack.com/archives/C0MQJ62NL/p1496568892693812?thread_ts=1496369178.372489&cid=C0MQJ62NL SLack conversations are so confusing sometimes 🙈

The RFC states: "When the client initializes a subscription, distinct from the "Subscription Active" acknowledgement, the server may also send an initial response."

@nilan Would it be possible to update just one of the examples to make use of this technique? What I see in all examples is that the Query is issues, and somewhere in the component, you start the subscription (like in

componentWillReceiveProps

)

Could that be a solution, send the initial results on activating the subscription?

@agartha that would be the coolest thing! Everybody happy 😉 I remember RethinkDB about this very thing.

Exactly