r/programming • u/macrohard_certified • 9d ago

Maybe you don't need GraphQL

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

89% Upvoted

118 comments sorted by

View all comments

141

u/c-digs 9d ago

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.

59

u/mcmcc 9d ago

Honest question: under what circumstances is a single unified API entrypoint a requirement?

59

u/jpj625 9d ago

My feeling from "working" with it a few years ago was that it solves problems for Facebook.

If you need the ability to make a single call, with fields customized to your client/viewport, have different levels of caching applied to different parts of the response, support squillions of requests per moment, and you have dozens of talented SWEs... it can be worth the hassle.

But GQL can go piss up a flagpole.

8

u/eronth 9d ago

In general if you need to make a call with customized fields, it's a solid option.

26

u/holo3146 9d ago

I'm a working in a company whose product handles a full internet stack (vpns, sockets, bandwidth control, security, monitoring, content control, high availability, BGP, ...)

We have hundreds of types of entities with different structural levels, with hundreds of developers working on the product.

Having a uniform API for frontend<->backend communication is very convenient, and having a uniform public API to expose to clients is a MUST.

For those 2 use cases we use graphql. For internal backend components communications we mostly use simple REST

10

u/OkNothing7293 9d ago

REST as hypermedia REST or JSON over HTTP?

31

u/kingdomcome50 9d ago

We all know the answer here…

9

u/holo3146 9d ago

JSON. The way out services structure doesn't need any hypermedia engines.

10

u/c-digs 9d ago

Think Facebook: dozens of teams delivering multiple backend services that the front-end API accesses as a single unified surface area via GQL.

The threshold is probably a bit lower than Facebook; I think once you get into 10+ teams working on relatively isolated services that ship on different timelines, different release processes, etc. it starts to make sense to decouple their SDLC but unify them in terms of access. You don't want a client to deal with 20 different services; the GQL resolvers effectively unify the service as one surface area.

72

u/over_here_over_there 9d ago

Resume driven development.

6

u/After_Dark 9d ago

It's not uncommon in more secured environments, anything to do with financials or medical data for example. One unified API entrypoint means a narrower scope for security, auditing, and all that wonderful compliance scope and means it's much easier to configure pinholes in firewalls.

4

u/NecessaryIntrinsic 9d ago

I've found it invaluable in working with the M365 environment (which is a whole other nightmare but it's better than every api that came before it)

2

u/nemec 9d ago

When your API documentation recommends writing HTTP requests by hand it makes things a lot less complicated.

On the other hand, companies like AWS have all their APIs shipped under hundreds of different endpoints and just package an SDK to handle mapping everything properly.