Tom Dale on GraphQL, Relay and REST
Tom Dale is a known professional in the JavaScript community. Working on Ember.js, a JavaScript framework that is geared towards ambitious web applications, his opinions and thought have a lot of experience behind them. Lately discussed GraphQL on Twitter.
In a series of tweets Tom discusses GraphQL, Relay and REST. With regards to caching, performance and ease of use. There will be a complete article later on, but with the series of tweets are already packed with useful insight.
For now in a transient media like Twitter these thoughts are easily lost and is now here:
TweetThe ideas in Relay are fantastic. Kind of like Ember Data but with property-level fidelity and knowledge of components. Very nice.
GraphQL by itself is too flexible. Note that Relay does not work with GraphQL—it works with GraphQL + several important constraints.
Namely, those constraints are that all entities must be addressable top level by type and ID. (Very similar to JSON:API in this respect.)
People conflate Relay-flavored GraphQL and vanilla all the time. Without these constraints is not a good fit for client-side apps IMO.
There are other downsides to GraphQL. It pushes a ton of complexity to your backend, particularly if you're not talking to a graph database.
I see the hype train conductors saying stupid shit like "Why GraphQL will replace REST" and I just start sobbing.
Unless your data actually is a graph, you're throwing out well-understood HTTP performance techniques like caching and parallelization.
Because each incoming request is a unique query, you have to analyze the query. Compare to idempotent HTTP requests: easy to cache.
A GraphQL response is going to be as slow as the slowest subquery it has to execute to build the response.
Compare that to multiple parallel requests via REST, where if 1 out of 5 requests is slow, you still get those other 4 right away.
There are HTTP overhead benefits to GraphQL's query batching, but it seems like those are largely solved with HTTP2.
These issues may be tractable; but in 2016, you're throwing away a surprising amount of free HTTP perf that has to be replaced by hand.
And it's just not clear to me that GraphQL is superior to HTTP2 + something like JSON:API.
(At the end of the day, JSON:API is a spec for serializing a graph of objects in a way that's optimized for a client-side identity map.)
TL;DR Relay has amazing ideas I want to steal. GraphQL + constraints is okay but you're gonna have to do yeoman's work to make it fast.
GraphQL will replace REST in the same way MongoDB replaced PostgreSQL.
One thing I forgot to mention about GraphQL is that GraphiQL is really really really good.
If you're not familiar, GraphiQL is an interactive query editor with built-in documentation browser. Really well done.
- @tomdale