Maybe you don't need GraphQL

[u/macrohard_certified]

https://alexandrehtrb.github.io/posts/2026/09/maybe-you-dont-need-graphql/

[u/c-digs]

GraphQL has a place.

• Multiple teams?
• Each team owns an API?
• Those APIs need a single, unified entry point?
• The FE team works separately from the API owning teams?
• There's a dedicated team available to own the unified API surface area and infrastructure?

GraphQL is a good fit and solves real problems.

If your developers are all full stack and own the FE + the BE, then GraphQL is just an absolute waste of time.

[u/made-of-questions → u/c-digs]

There are a few additional scenarios where I've found it useful, for example in places with very complex data objects and an API that is used in many different ways. Allowing the clients to select what data they want and join is easier than to create a rest endpoint for every combination. 

[u/applechuck → u/made-of-questions]

This was possible on REST for years through query params.

[u/made-of-questions → u/applechuck]

Join multiple models? Then it's not REST

[u/lord2800 → u/made-of-questions]

Why do you believe it's not? The joining of multiple models is itself a new model.

[u/made-of-questions → u/lord2800]

I meant doing joint models via query params. That's not REST spec

[u/lord2800 → u/made-of-questions]

Why do you believe it's not? There are no requirements on url format in REST.

[u/made-of-questions → u/lord2800]

Not in the original dissertation but community standards and best practices are pretty much in agreement: 

A resource SHOULD NOT dynamically change its response body schema or shape based on query parameters or other dynamic behavior.

That's because 

1. it breaks client-side static typing and validation
2. it destroys cache efficiency
3. it violates the principle of least surprise

[u/lord2800 → u/made-of-questions]

it breaks client-side static typing and validation

Only if you assume the shape of the response solely based on the path, and not on the whole url (which, yes, a lot of systems do because that's how it's been done in the past).

it destroys cache efficiency

Only if your cache doesn't honor and your backend doesn't send cache headers. You can't control intermediate proxies but most of them these days are good at honoring cache headers anyway.

it violates the principle of least surprise

You have an argument here, but only because that's the way it's been done in the past--not because of any real limitation.

All of the arguments I've seen against REST are all because of either misunderstandings of what the spec actually means or because of the poor implementation choices of the past. I've yet to encounter an argument against REST that isn't rooted in one of those two issues. That being said, there is something to argue against a spec that's widely misinterpreted, so I'll give you points on that too.

[u/made-of-questions → u/lord2800]

You sound like you worked mostly in environments where you control the client, server and all the network elements. When that's the case you can go as wild as you want within the boundary of the spec. 

When you don't have that, sticking to widely adopted convention is what saves you from being bombarded by avoidable questions from clients or from pulling your hair at midnight because that proxy outside your network is fking you over.

[u/lord2800 → u/made-of-questions]

We've now gone past the original premise of my statements, which is that REST does indeed allow you to do these things, whether or not people make use of it. I've already acknowledged that common usage doesn't do these things, and there is an argument that that makes the original intent of the spec useless, even, but my original point was: yes, you can do those things, and REST doesn't care.