Goodbye GraphQL: Why After 6 Years I'm Over It

Remember when GraphQL was touted as the silver bullet for APIs? One endpoint, no over-fetching, the client decides what it needs. But after 6 years in the trenches, some developers are starting to notice that the bullet isn't so silver after all.

What went wrong?

The author, after half a decade with GraphQL, highlights several key issues:

• Caching complexity. In REST, HTTP-level caching is straightforward. In GraphQL, every query is unique, and caching must be implemented manually on the client. It's a pain.
• Performance. The N+1 problem is a classic. DataLoader helps, but not always. When you have dozens of nested queries, your database starts to cry.
• Tooling overhead. GraphQL requires type generation, schemas, resolvers. The bigger the team, the bigger the mess. And try explaining __typename to a newbie.
• Overkill for simple projects. If you have a CRUD with three entities, GraphQL is like using a cannon to kill a mosquito. REST handles it faster and simpler.

REST — not perfect, but predictable

The author doesn't call for an immediate migration back to REST. But notes that for most internal services and small projects, REST remains the more pragmatic choice. GraphQL shines for complex, client-oriented apps with diverse clients (mobile, web, IoT). But if you have just one web client — why overengineer?

METABYTE studio comment: Choosing between REST and GraphQL isn't a religious war — it's an engineering decision. If your project is like a Lego set (lots of small pieces), GraphQL might fit. But if you just want to quickly build an API for a typical app, REST with OpenAPI is often the hammer that doesn't look for nails where there aren't any.