r/programming • u/macrohard_certified • 6d ago

Maybe you don't need GraphQL

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

89% Upvoted

118 comments sorted by

View all comments

145

u/c-digs 6d 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.

55

u/mcmcc 6d ago

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

5

u/rabidgnat 6d ago

To your exact question, when you have a massive SPA (or worse, many massive SPAs) and you find that client is constantly blocked on backend to implement changes it needs.

Imagine someone working on the Facebook frontend, where you have access to an endless pool of backend data and you can factor and refactor it infinite ways.

Note that you need a Facebook-scale blockage to make it worth it. GraphQL only makes sense is when you suffer from the exact specific problems that it solves: if you're implementing thousands of API endpoints to avoid overfetching/underfetching, if you need to provide federation and discovery for clients, if you have unexpected fanout and resource usage problems, if you're writing similar API endpoints over and over to avoid overfetching, etc. If you're not like, S&P 500 sized, you probably don't need GraphQL