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. Po

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.