[Matthias247]

Is Reactive GraphQL even specified? I thought that in the current state GraphQL only defines single queries (snapshots) of data, and not continuos update notifications. Forgive me if I have missed it - I have not followed GraphQL/Relay apart from a very basic look at it.

Without having an open specification Meteors implementation might end up completly different or incompatible to other (Reactive) GraphQL implementations.

Despite that, I think that implementing a reactive GraphQL backend will be very hard, and it would only work good if all of the sub-data-sources that you use in your backend support reactivity (subscriptions) as well. If they do, then you have to subscribe to all possible data sources that are mentioned in the query, and update the current state when one of these changes. If the update requires you to fetch an additional data source (e.g. you must fetch other indexes of data which are provided by another source), you must even dynamically subscribe/unsubscribe on updates of other sources.

And how can you provide traditional REST APIs (or even query-based GraphQL endpoints) as reactive endpoints? The best you can do is probably implement polling (rerunning) the query on the backend over and over.

[rapind]

The idea of changefeeds / subscription cursors has been around for a while now, especially in Meteor. I doubt it'll be that crazy to add reactivity to graphql queries when compared to what Meteor is already doing w/ subscriptions and DDP.

RethinkDB for example has changefeeds built in and is tackling this problem as well. See: https://github.com/rethinkdb/rethinkdb/issues/3711

Data as a stream is pretty interesting too: https://www.youtube.com/watch?v=fU9hR3kiOK0

[Matthias247]

That doesn't really contradict my statement. I agree that the feature is already there in Meteor (only with another query language), and that it's also supportable by RethinkDB, Firebase or any other backend/db which supports subscriptions. By what I meant is that it requires support for subscriptions all along the chain, and this is not supported by legacy REST/GraphQL/etc. APIs. The lack of alternate DDP backends besides the MongoDB one (and of course the creation of custom subscriptions) seems to confirm this.

I am sure they could now update their query language to GraphQL instead of MongoDB queries by adapting and extending the existing system, but I don't know if thats currently the biggest problem for meteor adoption or only something that is nice to have for some GraphQl/Relay fans (which still might be using these directly anyway).