React, etc. Tech Stack

React, Flux, GraphQL, Hack, HHVM...? All of this and more!

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:

The 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

Written by Jorgé on Saturday October 15, 2016

Permalink -

« Angular 2 in production on Google AdSense admin UI - PHP 8.0 to ship with a JIT compiler »