[derefr]

> And what exactly is wrong with GraphQL ? It is better than REST for a number of use cases.

When a response is a representation of a single resource, that response has a definitive caching lifetime. When a response represents a synthesis of a bunch of random crap the user asked for, the response has no clear caching lifetime, and so is uncacheable.

Most of the scalability the web has achieved, rides on the back of response caching at one level or another. Even low-level business-backend vendor APIs can—and are often designed under the assumption and requirement of—being cached. GraphQL throws that property away.

[craigmcnamara]

GraphQL seems like a great idea if you're a massive social media company looking for ways to empower devs to stamp out flavor of the week social media widgets without being tied to existing APIs. I'd bet most companies doing GraphQL are just doing uncacheable things that REST APIs could do fine.

[hansworst]

Almost all graphQL clients implement a custom caching layer (for example using indexeddb in the browser) that can cache resources with different timelines, also when they’re returned in a single response.

[derefr]

Yeah, but that's client-side caching, which doesn't get you much in terms of scalability. Scalability comes from transparent backend reverse-proxy caching — Varnish and the like. You can cache the resources that go into a GraphQL response, but you still have to build the GraphQL response each time — and that can become a problem, as various should-be-trivial parts of each request's backend lifecycle start living long enough during high concurrency request loads to destroy request-queue clearance rates.