I stumbled across this video from GraphQL Summit 2017 which talks about a new @live directive in GraphQL, which allows you to keep certain parts of your query reactive. It is particularly interesting because pretty much everything Rodrigo discusses in this talk will be very familiar to Meteor devs: benefits, tradeoffs, gotchas, etc. He further goes on to talking about the complexities in designing a backend to do this, and the different strategies available (Meteor is specifically mentioned).
Meteor figured this stuff out years ago… just with a different coat of paint. I feel like Meteor was (and perhaps still is) way ahead of its time in this area, because live queries are being presented as a new concept to many developers. This may be new to GraphQL, but Meteor has been doing it for years.
Some devs on here have been bringing up the idea of a tighter integration between Meteor and Apollo. Maybe this is an opportunity for that. Image being able to tag a certain part of your GraphQL query with
@live and have it just work, leveraging the Meteor pub/sub system behind the scenes and having data being transported efficiently over DDP.
At the end of the talk, Rodrigo mentioned that someone sent him a github project that enabled a reactive experience with GraphQL and Meteor. I think he may be talking about this one. This looks like an interesting start!
There has also been a lot of interesting work in this area that has been done in the community:
There is the Grapher project from @diaconutheodor that uses a GraphQL-like syntax for queries. Not sure how adaptable this would be to get working with a GraphQL query, but this project has already figured out how to efficiently setup a data layer with queries coming from the client. Add in a very good scaling solution with Redis Oplog and things become even more appealing.
I don’t know, maybe this is too pie in the sky. I’d be curious to hear what others think about how feasible something like this is.
Thank you for your time! Looking forward to any discussion!