GraphQL exists to solve a specific, real problem: a backend serving several different clients (a web app, a native app, a partner integration) each needing a slightly different shape of the same underlying data, without over-fetching unused fields or forcing multiple round-trips to assemble one screen. For a product with that shape, GraphQL is usually the right answer.
A lot of products don't have that shape yet. A single web frontend, built alongside the same API it talks to, with endpoints designed specifically for the screens that call them, isn't the over-fetching, multi-client problem GraphQL was built for. A well-designed REST API, shaped around actual UI needs, gets most of GraphQL's efficiency without its added complexity.
That complexity is real, not theoretical. Naively resolved GraphQL fields can reintroduce the same N+1 query problem a badly written REST endpoint has, just one layer further from where it would normally be noticed. Avoiding it takes deliberate batching, which is its own thing to build and maintain. HTTP-level caching, which works for free on REST's GET endpoints, doesn't apply the same way to GraphQL's single POST endpoint. And the client tooling, including schema management, codegen, and query complexity limits so a client can't request something that overloads the database, is a real, ongoing cost to carry.
GraphQL earns its cost when there's an actual multi-client, multi-shape problem to solve: a public API with third-party consumers, or clients with genuinely divergent data needs. For a single-client product with an API team controls end to end, REST tends to get built faster, debugged faster with nothing more than a browser or curl, and cached for free at the HTTP layer. The right choice depends on which of those two situations a product is actually in.
