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:

• Limited number of routes
• Making SQL queries in the .php file that rendered the markup
• Heavy reliance on local styling

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.

1. You want/need the whole model at one time
2. Ideally, we may only ever need to request a record once
3. Your models relationship's should also be in the store, or there should be an interface for fetching them

When working with GraphQL (and graph-based data) we want different things:

1. Different data in different views
2. We expect to refetch data as needed
3. Each query can result in totally different data

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:

• Tracking/caching queries
• Dynamically building models
• Automatically create queries and mutations on your behalf