GraphQL solves a specific, real problem: over-fetching and under-fetching. With fixed REST endpoints you get fixed responses, and a rich frontend often needs three calls to assemble one screen. GraphQL lets the consumer specify the shape of the response and get exactly that in a single request. For data-rich clients pulling many related resources, it is genuinely powerful, and the tooling ecosystem around it is substantial.
I was skeptical early, and I want to be precise about why. My worry was not the technology; it was the framing. GraphQL was often adopted as a way to avoid doing the hard work of API design — rather than deciding what the useful resources and operations are, you expose the graph and make the consumer figure it out. That is a transfer of labor, not a removal of it. Somebody still has to understand your domain; you have just decided it will be your consumers.
So the questions to ask before adopting it: is your data actually graph-shaped with many traversable relationships? Are your consumers sophisticated enough, and motivated enough, to write good queries? Do you have an answer for query cost, depth limiting, and abuse? Can you monitor and rate-limit a surface where every request is different?
If those answers are good, GraphQL earns its place. It sits alongside REST, gRPC, event-driven and now MCP as one established option in a multi-protocol world — which is exactly the right resting place for it. My early skepticism was about the hype, and the technology outlived the hype fine.
