awesome piece Josh. ..my only issue with GraphQL is basically if we had a Relay style ORM using Mongo instead of GraphQL, the component code would be like a quarter of what Relay/GraphQL has you typing. Just like React, GraphQL is an over-engineered interface that could be simpler.

That said, it’s not really an issue — because I imagine that abstractions will be built on top of GraphQL not just on the server to interface with your Database query language, but also in your Components. GraphQL supports so much (i.e. different databases that must be able to interface with it, etc), which inevitably causes its interface to be more complicated. So I don’t think those of us married to, say, Mongo will want to use it directly, when a mongo-specific abstraction on top of GraphQL could be even better. GraphQL will become the underlying protocol that makes it so Mongo can operate with a whole ecosystem of other packages — that will be its true end goal; not forcing us to write what can be expressed a lot simpler if you’re needs aren’t so expansive.

I think we are gonna find ways to use abstractions on top of it (like always) that make our workflow way easier. As it is I can’t imagine, writing all those GraphQL queries in my components.Maybe it’s cuz I’m already using a Relay-style Mongo ORM with Meteor ;)…

We should build a mongo specific adapter on top of it before GraphQL ever finds its way into Meteor on its own. And keep in mind, I’m talkin an adapter on top of the GraphQL adapter that interfaces with Mongo on the bottom of the stack. Mongo on the bottom and the top, and GraphQL in between. If you want the option to switch out DBs, then use plain GraphQL.