XDEFiANCE'e Quality Internet Shop

I’ve used GraphQL, specifically Apollo Client and Server, for a couple of years in a real enterprise-grade application.

Not a toy app. Not a greenfield startup. A proper production setup with multiple teams, BFFs, downstream services, observability requirements, and real users.

GraphQL solves a real problem, but that problem is far more niche than people admit. In most enterprise setups, it’s already solved elsewhere, and when you add up the tradeoffs, GraphQL often ends up being a net negative.

So now your GraphQL layer still has to overfetch from downstream REST APIs, then reshape the response. You didn’t eliminate overfetching. You just moved it down a layer.

There is a case where GraphQL wins here. If multiple pages hit the same endpoint but need slightly different fields, GraphQL lets you scope those differences per query.

Yes, Apollo lets you customize this behavior. But that’s kind of the point. You’re constantly paying a tax in extra configuration, extra conventions, and extra mental overhead just to get back to something REST gives you out of the box.

If you have two queries where only one field differs, Apollo treats them as separate queries. You then have to manually wire things so:

Apollo expects every object to have an id or _id field by default, or you need to configure a custom identifier.

Embedding large payloads like PDFs directly in GraphQL responses leads to bloated responses and worse performance.

When you add everything up, GraphQL often ends up solving a narrow problem while introducing a broader set of new ones.

And after all that time, I’ve come to a pretty boring conclusion:

This isn’t a “GraphQL bad” post. It’s a “GraphQL after the honeymoon” post.

The main problem GraphQL tries to solve is overfetching.

Most enterprise frontend architectures already have a BFF (Backend for Frontend).

That alone significantly diminishes GraphQL’s main selling point.

That’s a very expensive trade for a few extra kilobytes.

GraphQL takes significantly longer to implement than a REST BFF.

GraphQL optimizes consumption at the cost of production speed.

In an enterprise environment, production speed matters more than theoretical elegance.

If you filter dashboards by 2XX, you know those requests succeeded.

With GraphQL, a 200 can still mean partial or full failure.

This matters when you’re on call, not when you’re reading blog posts.

Apollo’s normalized caching is genuinely impressive.

Meanwhile, REST happily overfetches a few extra fields, caches the whole response, and moves on.

That assumption does not hold in many enterprise APIs.

So now the BFF has to generate IDs locally just to satisfy the GraphQL client.

Which is ironic, considering the original goal was to reduce overfetching.

REST clients don’t impose this kind of constraint.

Most frontend and full-stack developers are far more experienced with REST than GraphQL.

That learning curve creates friction, especially when teams need to move fast.

That’s why, after using it in production for years, I’d say this:

Especially if your architecture already solved the problem it was designed for.

GraphQL isn’t bad.It’s just niche.And you probably don’t need it.