Rethinking Another Best Practice

Posted on 2015-07-30

Just over two years ago, Facebook released React. At the time, I joined an
apparent majority of commenters in declaring that it looked weird and clunky.
Inline XML, onclick handlers, markup and logic together… yuck! To say React
has taken off and captured developer mindshare since then is a huge understatement.
Today it feels like every second company is migrating their existing MVC codebase
to React and/or Flux.

Web developers are a fickle bunch, and the massive churn in the world of web
frameworks is well documented. So what’s far more interesting than React’s popularity
is the way it’s changed how we think about front-end web applications. React’s key
features are great encapsulation through components, and declarative UI, rather than
directly manipulating global state (ie. the DOM). React’s virtual DOM is generally
considered to be its key feature, but in reality it’s an implementation detail
that powers these two breakthroughs.

A few weeks ago, Facebook released the initial spec
and reference implementation
for GraphQL, a new way to do data transfer between servers and app/web clients. Just as
React and Flux challenged our assumptions that MVC was the preferred (only?) way
to write clean frontend applications, GraphQL now puts REST in the crosshairs.

REST has turned into a bit of a sacred cow among web developers.
It’s generally considered “the right way” to do data exchange between servers and
web UIs, and what we’ve lost with this uncritical attitude is a more nuanced understanding
of REST’s tradeoffs for the systems we’re building. Furthermore, most of us are
pretty low on the Richardson Maturity
Model,
so you can argue that often we’re not even doing REST correctly. How many REST
APIs have you written that actually use hypermedia to link and expose affordances
between your resources?

I highly recommend reading Facebook’s GraphQL
introduction,
as it does a fantastic job of enumerating the problems with REST for the increasingly
complex and performance-sensitive systems we’re building today. It also lists
issues with the “Ad Hoc Endpoints” that many of us build and erroneously call
“REST APIs”.

One of the promising things about GraphQL is that it’s not tied to HTTP at all–
this is great for two reasons. First, it means you should also be able to use it
with other transports like Websockets or TCP. Secondly, HTTP has always been
pretty awkward for representing application semantics. If you’ve ever agonized
over the correct response code for an error condition in a REST API,
you’ve experienced this first-hand. It shouldn’t be surprising that a protocol
designed for document delivery is not an ideal fit for the wide variety of things
we do with APIs and web applications today.

GraphQL is still extremely young as a public project, so it’s hard to tell if
it will live up to its promise. Like any technology, it will have its pain
points, but at the moment only people inside of Facebook are intimately aware
of them. It’s also clearly still at the “technical preview” stage, and some critical
things like mutations (ie. writes to your data) are still not fully fleshed out
in the documentation. Things should really ramp up when Facebook releases
Relay, a client-side JavaScript
framework they’ve been teasing that’s designed to integrate tightly with GraphQL.
It’s projected to drop some time in the next month and I’m really looking forward
to digging in, so we can get a wider look into GraphQL’s potential.