GraphQL and Ember Data start with different assumptions, maybe that's a good thing
I've had the chance to work a little outside my comfort zone by exploring (GraphQL)[http://www.graphql.org]
while implementing an GitHub integration into an Ember.js app. GraphQL is really
cool (although I'm terrified of the authorization implementation questions). Avoiding
n+1 query bugs out of the gate is killer feature.
What has really struck me working with both GraphQL and React is how much they remind me of writing apps in the early days of working on php apps:
.phpfile that rendered the markup
Which makes sense because React comes from Facebook, which was born in this pre-mvc era and originally had very few need for lots of "pages," but has a large amount of interconnected data per-page. A single news feed post may contain 5 or 6 model types and countless instances of each model.
Ember Data is intellectually (if not technically) coupled to the idea of MVC, ActiveRecord-style design patterns: typically implementing a list view or a details view, and if you want to get really fancy, sprinkle on a few relationships.
As I've worked with non-standard data backends (GraphQL, Elastic Search, etc), I've come to the realization that Ember Data really doesn't give me much in these features.
Maybe Ember Data just doesn't work with GraphQL. Maybe it shouldn't.
Ember Data (and JSON:API) makes a few assumptions of how to build your app.
When working with GraphQL (and graph-based data) we want different things:
Some of these ideas are in direct conflict with each other. What if we didn't try to bend Ember Data into "supporting" GraphQL, but rather just came up with a GraphQL Store.
It's features could include: