There is no mention of the word “NPM” in the article. There’s a lot of language there, but none make that clear. The closest thing I can find is an example of how it can be used:
“If you have an existing Rails/PHP/Spring/Node app with REST endpoints, you can put a Meteor Data GraphQL server in front of it, so that you can use a GraphQL client to access the same endpoints but through a nicer, more performant API.”
But still, the framing isn’t clear — am I within a standard Meteor app as an appliance in front of a separate REST server (just as you can make requests to any 3rd party API)? There’s a lot of general language describing its interoperability, but my takeaway was you meant it will work with Blaze vs. Angular vs React, and on the server (within a Meteor app) you can supercharge REST endpoints in addition to SQL, Mongo, or any DB. I didn’t at all get that “Reactive GraphQL” will be a major contribution toward the greater NPM/Node/React community.
This path will very much show its face in code too. The way you will need to structure its APIs will be different. It can’t be coupled to Meteor. Rather, after it’s built (or significant headway has been made on it), you then build bridges to Meteor, just as you would any 3rd party library from NPM.
It’s this mindset that I’m talking about that I’m not sure you’ve thought about, or if you have thought about it, possibly have decided against. Either way, I think it’s an important conversation to be had with the Meteor community, rather than just a secretive decision MDG runs away with. Certainly having this conversation will do wonders to establish trust with the Meteor community regarding MDG’s open future. My hope is that when you get around to thinking of this aspect, you choose the “open” route.