I have spent a lot of years being ambivalent about GraphQL. I have watched it get oversold as a REST-killer and I have watched people pile onto it for reasons that had more to do with resume-building than with any real consumer need. So it surprises me to be writing this, but here it is: the single most underrated thing about GraphQL has nothing to do with query flexibility or over-fetching or any of the arguments people usually have. It is that you cannot do GraphQL at all without doing governance first. The governance is not a program you bolt on afterward. It is the price of admission. And that is a property REST simply does not have.
Think about what it actually takes to stand up a GraphQL API. You have to sit down and define a schema — one schema, a single typed graph that describes every type, every field, every relationship, and the exact shape of everything a consumer can ask for. You cannot ship the first query until that schema exists and is internally consistent. The type system will not let you have a User that means one thing over here and something incompatible over there. When you want to remove a field, you have to reach for the @deprecated directive and say so, in the schema, where everyone can see it. The whole thing is introspectable by default, which means the machine-readable contract that REST governance programs spend two years and a consulting budget trying to produce is just… sitting there, generated, the moment you turn the server on. You did governance. You may not have called it that. You had no choice.
Now think about what it takes to stand up a REST API. Almost nothing. You can add an endpoint this afternoon. You can add another one tomorrow that returns a slightly different shape of the same resource because a different team wrote it and nobody was looking. You can have firstName in one response and first_name in the next and fname in a third, and the framework will cheerfully serve all three. REST does not require a unified schema to function. It does not require you to declare your types up front. It does not force you to name your deprecations. Every one of those disciplines is possible in REST — I have spent years arguing that OpenAPI is the unit of governance precisely because it lets you impose that discipline — but the operative word is impose. In REST, the schema is optional, external, and always slightly out of date relative to the running code. Governance is a thing you do to REST, from the outside, against its natural grain, forever.
That difference in grain is everything. When the discipline is the price of admission, you pay it once, at the start, when the system is small and malleable and there are three types instead of three hundred. When the discipline is optional, you pay it later, in a governance program, in arrears, with interest, after the sprawl has already happened and every team has already shipped their own idea of what a customer record looks like. I have written that API governance is seventy-five percent people work, and I still believe that — but a meaningful slice of that people work is the work of getting everyone to agree on a schema that GraphQL would have forced them to agree on before a single line shipped. GraphQL front-loads the argument. REST lets you defer the argument indefinitely, which feels like speed right up until the day you try to inventory what you actually have.
I want to be careful here, because I am not making the tired claim that GraphQL is better than REST. It is not. There are whole categories of API — anything cache-heavy, anything hypermedia-shaped, anything where the resource model is the product — where REST is the right answer and GraphQL would be a self-inflicted wound. And GraphQL brings its own governance problems that REST never had, from query cost and depth limits to the operational headache of a single evolving graph. This is not a ranking. It is an observation about where the discipline lives. In GraphQL, the discipline lives in the tool, up front, unavoidable. In REST, the discipline lives in you, ongoing, optional, and easy to skip when the sprint is tight.
Which is exactly why REST governance is a discipline you have to actively choose, and GraphQL governance is a discipline you back into. The GraphQL team gets a single typed schema, explicit deprecations, and an introspectable contract as a side effect of the technology working at all. The REST team gets those same things only if someone stands up, insists on OpenAPI as the source of truth, wires up the linting, and defends the schema against every team that would rather just ship an endpoint. Most REST teams do not have that someone. That is not a technology failure. It is the natural consequence of a technology that does not require the schema in order to run.
So when people ask me whether they should adopt GraphQL, my honest answer has quietly shifted. I do not tell them GraphQL will make their API better — it might not. I tell them that if they are the kind of organization that struggles to get a handle on its own schema, GraphQL will hand them a handle whether they want one or not, and that alone might be worth more than any query-flexibility argument on the marketing page. Getting a handle on your schema is governance. GraphQL just does not let you pretend otherwise. This connects directly to what I have been saying about MCP as last-mile plumbing — the foundational work is the schema, the contract, the thing underneath. GraphQL makes you do that work first. REST politely lets you put it off until it hurts.
