Facebook Relay: An Evil And/Or Incompetent Attack on REST

Jafar Husain does an excellent job of explaining some of the problems netflix has had with REST APIs and why you might want to take a different approach in his introduction to Falcor video. Falcor is tackling some of the same problems as graphql / relay but making trade offs at different points.

https://netflix.github.io/falcor/starter/why-falcor.html

A REST API may be the best decision for a lot of projects but GraphQL and Falcor are solving interesting problems that come up more and more in single page apps of increasing complexity.

There are very key points about GraphQL/Relay that the author of this post is missing.

For a Facebook user, all client-side cached data is stale. All of it. Posts are edited, profile pictures are changed (and those changes are referenced in other posts that must appear to be consistent with the image shown to the user). This is key to their value proposition - Facebook gives a new experience each time the user comes back to the site, thus the user will check the site multiple times a day. Now, you could cache if you could invalidate the caches... and this is fine to do on the server side, but it's downright impossible to push a client side cache invalidation at Facebook scale.

Another key insight is that "HTTP can fire network requests in parallel" is insufficient if your requests are dependent on each other's results. Let's say you want to crawl a graph of nodes. Are you going to do a BFS with a full HTTP round trip at each level, collecting touched nodes and transmitting the border each time? When the latency of that round-trip is at 2G speeds? How would you handle this in REST, under the assumption (as above) that it's fine to let the server handle caching?

Well, you might use the whole "HTTP's content types are a type system" concept that the author loves, and annotate your REST request with the structure of data you want back. UserWithPostsWithCommentsWithLikes is a type, after all, just as UserWithProfileInformation is a type. And at that point you don't want to name each of those separately; your Content-Type header would have some structure; it would almost read like a programming language. Oh, and you happen to have a server that can interpret that Content-Type piece by piece. You would eventually realize it's just more sane to break that out into the body of a POST request rather than holding on to REST just for REST's sake. And then, boom, you have GraphQL.

The post devolves even further towards the end, making a dubious link between Facebook's developer tooling and its grander ambitions. Making realtime graph search, and realtime insights from the graph of entities, effortless to the developer and the user... that's one way in which the web is evolving. Every company needs to be able to think outside the box. If everyone took "don't reinvent the wheel" completely literally, we wouldn't have airplanes.

Do I have gripes about the GraphQL syntax? Sure. Do I wish it was more like JSON Schema? Does grokking Relay migrations feel like reading a James Joyce novel? (With apologies.) Absolutely. But... are GraphQL/Relay a needed proposal to push innovation on the web forward? Yes.

I deal with REST zealots like this everyday :( just the fact that people spend so much time debating what is and what isn't REST should be a red flag that maybe it isn't the answer to everything.

All the simple REST examples make it look like it is the perfect solution for CRUD tasks. But in reality API endpoints are not a straight pass through to the database. An endpoint may do any combination of CRUD tasks, it can't be type casted as a single one with a HTTP verb.

Overloading HTTP error codes is another interesting problem. If the server returns 404 for a resource, what actually happened? Did the web server or my application return the 404. Conflating HTTP and application error codes leads to confusion.

HATEOAS is just superfluous. I've met zealots who will defend it to the death. I just haven't found a practical use for it.

Surface area and complexity are a big deal. REST encourages creating a CRUD interface for every single resource. I've met people who have created literally 100 endpoints upfront for a small application - how is that maintainable?

I like that Facebook is standing up to the zealots. I get attacked at work when I try to create simple API endpoints and they aren't 100% REST (if anyone could agree what that even is.)

It's a shame that this article spends most of its time ranting and throwing around irrelevant attacks at Facebook (we get it, you don't like their product). If I buy the author's premise that REST does everything graphQL does and that everyone is just using REST wrong, please show us how to properly do it. Now I have to take the article's word for it, without any practical explanation how to correctly design a REST API.

A query on a graph or a tree can both be RESTful. You can describe traversals of the graph or tree in a query embedded in an HTTP endpoint. You don't need to make repeated round trip queries to do the traversal unless you are unwilling to use a suitable query description.

Metaphorically this is all pretty funny becuase the web is already a graph at a fundamental level.