subscriptions and live queries - real time with graphql

[n1ru4l]

Work in progress :)

[Urigo]

so excited for this!

[n1ru4l]

more notes to myself:

• elaborate on drawbacks with subscription live queries and @live queries when having multiple queries that select similar data
• Somehow reflect thoughts of json patch deflate/inflate live query results adapters n1ru4l/graphql-live-query#243 (comment)
• Write about https://github.com/apollographql/real-time-federation

[Urigo]

I am soooo excited for this!
I hope this post will start a bigger conversation and find us more use cases and places to work on it in production

[n1ru4l]

One tiny thing left to do before publishing is to do some reformating with the bullet points and adjust the relay cache update examples

[n1ru4l]

@Urigo @dotansimha I think it is finally in a "ship it" stage :)

[SimonSimCity]

Well written article! I was a bit surprised, reading about Hasura and PostGraphile but not seeing Meteor mentioned in here, but this just as a personal note.

Meteors approach is also quite interesting in my opinion as even the initial state is transmitted as a "patch" if you will 😄

[n1ru4l]

Well written article! I was a bit surprised, reading about Hasura and PostGraphile but not seeing Meteor mentioned in here, but this just as a personal note.
Meteors approach is also quite interesting in my opinion as even the initial state is transmitted as a "patch" if you will 😄

TBH I don't have much experience with Meteor, maybe @Urigo could sparkle in some knowledge 🤔

[SimonSimCity]

Me trying to describe the concept about Meteor. I hope it's understandable 😊

I would quickly describe Meteor as having a client-side database. The system is locked to MongoDB and by this lock, they allow you to "publish" a subset of your data from your server-side database (MongoDB) to a client-side database (minimongo - an in-memory database with an interface almost identical to MongoDB). For the UI you can then simply write reactive queries against minimongo where you receive what they call a reactive cursor (for simplicity I'd compare it with an observable). The server sends the observed changes (it observes the database changes by listening to the MongoDB oplog - used to keep MongoDB secondaries in sync) using the DDP protocol (https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP.md#managing-data) which stores them straight in minimongo. Minimongo now triggers a recomputation of all the queries to this collection. All this works well because the transmission of data is just done by syncing single data-sets stored in collections (or tables or how you call them) - one publication per collection. Graphql would require a different approach, as you most of the time already get a composition - a joined and composed set of data - if you want.

Meteor is more, but this, I think, is the most important part in regards to this article.

[Urigo]

I've reviewed and also created did a workshop using this blog post and all the cool things from https://github.com/n1ru4l/graphql-bleeding-edge-playground

This is remarkable and makes me so happy the world of GraphQL and "real time" abilities is coming back from the dead again, and this time by amazing individuals that are just passionate about it all!

Few general points

1. After working and trying out everything in https://github.com/n1ru4l/graphql-bleeding-edge-playground, I believe it would be a missed opportunity if this post won't include examples people could actually try out. This is working and people should get their hands dirty. You could just link into the repo or to a code sandbox if that would work
2. On that note I would mention everywhere, throughout the post that this is something people could use right now. (I was just super impressed by the demos as you can see....)
3. Not directly related, but I feel we need some tutorials on this. Small ones, but also I really want to update the WhatsApp clone for a long while and with all the new things that are out, it would be a great opportunity
4. I love the tables of X and V in the post. Maybe you could add a last one that summarizes everything at the bottom?
5. In the what's next section, I would also add a link to a place people could talk about all of this, as there is no open RFC issue yet. Maybe an issue on one of your repos and maybe Discord or something
6. Any ideas for a cool image? I can ask our designer to create something if we'll give him guidelines

Unrelated update - @yaacov has been progressing on @defer support on schema stitching and noticed we need some things from graphql-subscriptions, so I've created this.
We'll see what response we would get. probably nothing and then maybe we'll just move that code into graphql-tools.

Now, about Meteor :)
I have a grand master plan about it in my head for years.
Meteor is a lot but everything in the post here is a very important piece of the puzzle.
Maybe it's time to start executing on that plan, but for that, we need a production user, preferably paying, who wishes to (very) actively go through that transformation with us.
@SimonSimCity are you up for something like that or knows someone in that position?

[SimonSimCity]

@Urigo I have to say that I personally am very passionate about seeing this in action. The product we're currently developing in-house here would benefit of it quite well, but I don't know how much time and energy I can invest into it. I'll let you know if I get to anything beyond that.

I'd be very interested though hearing the plan you have in mind. This might be worth its own issue, as I think it's rather a successor of the paper discussed here.

[yaacov]

Unrelated update - @yaacov has been progressing on @defer support on schema stitching and noticed we need some things

Thank you for your confidence in me, but I really didn't, IMHO I am not the Yaacov you are looking for.

[yaacovCR]

@yaacov I am sure you are the better yaacov