Here’s the question that article ends with:
@sashko @justinsb can we build “Reactive GraphQL” from the start as a generic NPM package? Thoughts?
Do we simply intercept all mutations before they hit the DB as our own sort of log tailing trigger?
And what about db changes performed “out-of-band”?
I think it should also replace the need for a Router since a Router is just a custom way to specify a sub-set of state
Please. Let’s not bind core data kept on the client (cached on minimongo or whatever) with local state. They are separate things.
From my research on this, it appears the only solution is a “reset” switch on all cached subscriptions, and a way to reset them individually. If there was an API to select subscriptions (i.e. by what GraphQL types they are related to), you could reset subscriptions by type after “out of band” data transfers to and from your database.
And how would you know when an out-of-band change to the db happens? It can be another app, a batch process, even a db triggered process as when failing over… the concept of an app layer intercepting changes to db is flawed imho.
i wrote my initial answer in the other thread (use triggers where available or manually do after transfers), but I’d also add this: realtime features are generally the sort of features where the data it’s made up of is regular application-generated data. E.g. collaboratively editing the same document, liking a post, etc. In addition, it’s often just a bonus. So if it breaks for a little, 99% of the time nobody will even notice; just as long as it catches up eventually.
I mean that’s the sorta stuff you’re dealing with. The problem kinda solves itself by its very nature. I think if you can manually refresh subscriptions based on an intelligent selector, at least 80% of all use cases will be solved, and that will just have to be good enough.
Also, who’s to say that out of band transfers can’t just start using GraphQL. Let’s just say half can. Now we are at 90% of all use cases solved. It will just have to be a tradeoff people seeking reactive subscriptions will have to make.
Well, if you think that would be good enough, come down to the Enterprise world and repeat that. For small apps that “own” the whole of the DB, that may look like a way to go, but not for any other case, and primarily in the enterprise world “out-of-band” data interfaces is bread-and-butter.
A lot of them are also using databases that support triggers rather than Mongo. If they want the reactive features bad enough on other DBs, they will use the aforementioned APIs to make sure the corresponding subscriptions are refreshed. Otherwise, it’s no different than what they already have: webpages that don’t stay up to date 
Reactive subscriptions even in the enterprise world (or perhaps especially there) is likely to be a new feature that they are gonna implement. And as a new feature, you either are talking about new DB tables that aren’t used in many other places (certainly not for the reactive aspects, but maybe for aggregating some sort of stats); OR, you’re talking about a new feature that the company is willing to take seriously enough to set policies that it must be interfaced with over the GraphQL API (at least for the fields that are reactive on the client).
I think enterprises serious about full stack reactivity have opportunities to seriously navigate these waters.
If only all of that was true, the world would be simple. And no fun 
But I for once have a few applications in production for more than one year (thanks to Meteor) that depend on fully reactive data subscriptions from mongodb, and are fully integrated (including via the data-layer) with other enterprise applications and data stores, I’m not looking forward to loose that.
well, there is a possibility: we could build something like triggers based on oplog that then triggers the GraphQL API. That in fact was originally how I conceived of everything: basically we define an interface on our webserver subscription appliance which receives updates from the bottom of the stack (aka the database) instead of from the top as it passes through it from graphql mutations.
So oplog and triggers would notify it of any changes. Hey, perhaps @sashko n co are smarter than me and have thought about this. Perhaps everything is so nascent that this is still an opportunity even if it hasn’t been tested out. Perhaps it’s the same damn thing! It’s receiving mutations without knowledge of the associated types/fields. Perhaps they can be inferred simply based on the GraphQL types.
This is fresh on my mind, so I’m gonna marinate on it, but the question is: if the Reactive GraphQL Appliance receives raw database mutation logs, can it re-create corresponding GraphQL mutations (and therefore know which subscriptions to refresh)?
If the answer is yes, you may very well have your wish. In which case, it doesn’t matter what “band” the data transfers go through.
I can also speak to this. The Enterprise is made up of multiple systems, each using a different type of database, whether it’s Mongo, Oracle, Microsoft, MySQL, PostgreSQL, etc. These systems usually have to interact with each other on some level at some point. When you’re building an app who’s target audience is consumers/end-users, sure that 99% figure might hold up, but for Enterprise, out-of-band data is very common. One app I’m working on right now has 70% of its data is being provided by a REST API from another system. Without that data feed, my app would be unusable because it’s time-sensitive.