Living APIs, and the Case for GraphQL: Redux?

[StevenACoffman]

It seems the last time you've mused about GraphQL was in 2018, and it's now 2025. I've enjoyed following your blog as your thoughts have evolved on PostgreSQL and sqlc (which has indeed been awesome) but I've been curious what your current views are of GraphQL as it has been a few years. HTTP/2, HTTP/3, webtransport and a few other things have come on the scene.

https://github.com/brandur/sorg/blob/ed7cecfc8a1e892d2b8a9b8bad6b7fe9973aef1b/content/articles/graphql.md

[brandur]

Hey @StevenACoffman, yeah I should update this one. We did a few years of GraphQL at Stripe (internally), but by the end of it the implementation turned out to be so difficult for everyone that it never felt like a really clear win over the REST-ish API to me (although it did plug into some of the Frontend data management frameworks pretty well).

So I wouldn't say I'm strongly in favor of GraphQL the way I was for a moment but there, but that said I'm not sure I'm strongly in favor of REST these days either, even if it may be still the all around best compromise. I should at least update the article to sand down the strength of the recommendation.

Do you have any thoughts on the matter?

[StevenACoffman]

For the last ~5 years I've been the maintainer of one of the most popular GraphQL Go libraries, gqlgen ( +10K ⭐ ). At work, we went all-in on GraphQL, and also used GraphQL (and Apollo Federation) for backend-to-backend IPC. A few years ago, I did a talk that convinced several bigger places (Uber, Reddit, Ebay, etc.) to try that out, and their engineers have since reached out to me to privately compare notes. I find so much about graphs really exciting!

So I have a complicated relationship to GraphQL, which comes with a lot of thoughts and mixed emotions. I was asking you because I like to check my own biases and perceptions.

Based on Postman’s collected anonymized usage data in the past few years, GraphQL requests comprised:

• 2024 - 27%
• 2023 - 29%
• 2022 - 28%
  So, it's not going anywhere, but it's also not going anywhere.

Meanwhile, while it may seem like Apples-to-Oranges, Cloudflare Radar 2024 Year in Review says that only about 30% of traffic still uses HTTP 1.1, while 50% uses HTTP/2, and 21% uses HTTP/3.

Another source has it:

• HTTP/3 is used by 30.1% of all the websites.
• HTTP/2 is used by 34.7% of all the websites.
  Some methodologies put these higher, but we can safely say:

A large chunk of current Internet traffic already uses HTTP/3 today.

GraphQL's decision not to use HTTP's semantics meant it could not benefit from the existing HTTP ecosystem's caching (queries are POST, and are batched), and also means GraphQL can't take advantage of any other HTTP advancements like streaming. GraphQL's Batching was a great HTTP 1.1 performance hack, but becomes a performance and logistical liability in HTTP/2 and HTTP/3. (I wrote more about why in HTTP/2 streaming and you, HTTP/3 streaming and wheee!).

This leaves "client-driven" as a notable GraphQL differentiator even in the HTTP/2 and HTTP/3 world.

However, I was up late chatting with a developer on a forum one night, and he shared what seemed like a brilliant ephiphany to me. For context, connect-rpc is some libraries that provide a thin translation to make gRPC work in the browser, or fallback to HTTP/2 streaming, or fallback to websockets, or fallback to HTTP 1.1.:

I spent many years working on a frontend team building a single-page React app. We maintained our own GraphQL service in order to knit together the many REST services we needed to interact with. We needed it because, due to the nature of the data, some views could take up to a minute to completely load the needed data. It was a worst-case under-fetch/over-fetch scenario. We wasted time waiting for fetch A, so we could load fetch B, so we could load fetch C (under-fetch). And we wasted both time and bandwidth because our APIs gave us heavy payloads where we only needed a subset of the fields (over-fetch).
Now, I’m working on a team building a React app which needs to knit together many gRPC services. While the nature of the data means that the over-fetch/under-fetch problem is not so critical, it’s still a significant factor. When we started the platform 2+ years ago, I assumed that we would inevitably need a GraphQL layer, or some other form of backend-for-fronted (like @bufbuild/knit, for example). But, a different solution appeared at just the right moment: React Server Components and Server Functions.
We make almost all our gRPC calls via @connectrpc/connect-node from server components and server functions. We don’t need a backend-for-frontend, because Next.js/React is our backend-for-frontend. Every time we mark a component with "use client" or a function with "use server", we’re making an implicit API. As our server layer runs co-located with our backend services, it’s lightning fast and low-latency. We hit all the APIs we need to before sending data to the client (solving under-fetch) and we only send the client exactly what it needs to render (solving over-fetch).
This saves us a tonne of effort in maintaining a large, complicated GraphQL schema. Knit seems like a much better solution — but it’s hard to beat querying services directly!

☝️ It's kind of hard to get more client-driven than React Server Components and Server Functions.

On top of all that, the GraphQL spec maintainers (Meta) haven't been the best stewards. Their spec tends to lag behind their JavaScript reference implementation, and they don't much consider programming languages besides JavaScript. They have reduced their investment

There was and still is a ton of potential around graphs in technology, but the reality of GraphQL has not been able to make good on this potential.

[brandur]

Great answer here Steven. Thank you.

So, it's [GraphQL] not going anywhere, but it's also not going anywhere.

Hah! Yes, that's exactly right.

A large chunk of current Internet traffic already uses HTTP/3 today.

Wild. I hadn't bothered to look up these numbers lately at all, but I wouldn't have guessed that HTTP/3 was so pervasive. Maybe 30% of all web traffic (because the giants tend to produce a disproportionate amount of all of that), but not all of all websites. Although I do wonder if this is partly due to some huge proxy like Cloudflare supporting HTTP/3, and thereby giving everyone else HTTP/3 support by virtue of that. Either way though, that's impressive penetration given its age.

HTTP/3 does indeed resolve a lot, although when I think about any REST API, my mind always goes to lack of automatic SDKs to make raw HTTP usage easy and safe. Having an OpenAPI spec takes you a long way there though as we've been using openapi-generator to very good effect. (GraphQL doesn't really solve the SDK problem either, but I'm just saying that I'd have a bit of a hard time strongly recommending anything as all the paths tend to be missing at least some pieces.)

gqlgen looks great. I'll have to give it a shot at some point (on a dev API to start).

Anyway, you've inspired me to add an update to that GraphQL article that encourages some caution. I'd like to do a bit of a follow up including some of what we talked about here, but I'll have to think about it a little more to make sure I even have enough material to do that.

[StevenACoffman]

Another pitfall that is worth mentioning is that it is effectively impossible to have a public GraphQL API without investing a lot in bespoke tooling. It is really easy to design a malicious query that can have exploding computational resource costs. As a result, most GraphQL APIs safelist known good queries and deny everything else. The few public GraphQL APIs are more equivalent to the few public SQL APIs.

[brandur]

As a result, most GraphQL APIs safelist known good queries and deny everything else.

That's really interesting. I always knew that the potential for arbitrary complexity on a GraphQL query was a problem, but it sounds like things have evolved a long way since I looked at it last in that a theoretical problem became concrete which was reacted to and now production GraphQL is locked down just like most other production things are.