GraphQL is the API technology I’ve had the most complicated relationship with, and I think working through that complication is more honest and more useful than either the breathless hype or the reflexive dismissal. GraphQL is a query language and runtime for APIs, originally developed at Facebook, that lets a consumer ask for exactly the data they want in a single request — solving the over-fetching and under-fetching problems that plague REST APIs where you get fixed responses from fixed endpoints. The consumer specifies the shape of the response, the server returns precisely that, and for certain use cases — particularly data-rich frontends that need to assemble many related resources — it’s genuinely powerful. I’ve come around to GraphQL as a valuable tool while remaining skeptical of the framing that it’s a replacement for REST.
My initial reaction, I’ll admit, was skeptical, and I wrote about it candidly. In 2016 I wrote that GraphQL seemed like we didn’t want to do the hard work of API design — because GraphQL can shift the burden of figuring out what data matters from the API designer onto the consumer, who now has to know the schema and construct queries. My worry was that GraphQL was, in part, a way to avoid the discipline of thoughtful resource design by just exposing a queryable graph and letting consumers sort it out. But I also wrote, almost immediately, that I was keeping my mind open and looking forward to learning more — because I’ve been wrong about technologies before by judging them too early, and I wanted to understand GraphQL on its merits rather than dismiss it on first impression. That tension — genuine skepticism paired with genuine openness — characterized my whole engagement with GraphQL.
The GitHub GraphQL API was what made me take it seriously, and understanding the why behind it was clarifying. When GitHub built a GraphQL API alongside its REST API in 2016, I wrote about the reasoning, and it was genuinely instructive: GitHub’s data is a deeply interconnected graph — repositories, users, issues, commits, organizations, all related — and for consumers who needed to traverse those relationships, REST required many round-trips while GraphQL let them get exactly what they needed in one query. This was the case for GraphQL at its strongest: when your data is genuinely a graph, and consumers have diverse and unpredictable data needs, GraphQL’s flexibility is a real advantage. GitHub didn’t replace REST with GraphQL; they offered both, letting consumers choose the right tool for their use case. That dual approach struck me as exactly right.
The hype was the part I pushed back on hardest, and I stand by that pushback. There was a period — around 2017 — when GraphQL was marketed aggressively as the successor to REST, the thing that would make REST obsolete, and I wrote about just waiting the GraphQL assault out. The “GraphQL versus REST” framing, which I tried to deflate with everything from burger analogies to direct argument, was the wrong framing. It’s not GraphQL versus REST; it’s GraphQL and REST, each suited to different needs. I revisited GraphQL repeatedly as part of my API toolbox, and the consistent conclusion was that GraphQL is one tool among several — REST, hypermedia, GraphQL, gRPC, event-driven — and the mature approach is to understand what each is good for rather than declaring a single winner. The hype did GraphQL a disservice by setting it up as a REST-killer when its actual value is as a complementary tool for specific use cases.
The honest critiques of GraphQL are real and worth stating, because over-enthusiasm obscures them. I wrote in 2019 asking what makes you think your GraphQL consumers will want to do the work — because GraphQL shifts effort onto consumers, who have to learn your schema and construct queries, which isn’t always what they want. GraphQL also complicates the things REST made simple: caching, rate limiting, observability, and security are all harder when every consumer sends a different query to a single endpoint. The governance challenges are significant — how do you lint, version, and govern a GraphQL schema the way you govern an OpenAPI definition? After almost two years of watching it, I reflected that GraphQL had found real adoption and real value but hadn’t displaced REST and wasn’t going to. It solved real problems and created new ones, which is true of every technology and is exactly why the toolbox framing matters.
Where I’ve landed is that GraphQL is a legitimate, valuable member of the diverse API toolbox, neither the revolution its boosters claimed nor the dead end its critics feared. I’ve consistently placed it alongside REST, hypermedia, gRPC, and event-driven as one of the patterns a mature API practitioner should understand and reach for when appropriate. The specification and tooling matured, the open-source ecosystem grew substantial, and the work of aligning the specification governance processes across OpenAPI, AsyncAPI, and GraphQL reflects that GraphQL has earned its place as a first-class API technology worth governing properly. By 2025, when I mapped HTTP APIs, GraphQL, event-driven, and Model Context Protocol together, GraphQL was simply one established option in a multi-protocol world. That’s the right resting place for it: a powerful tool for graph-shaped data and flexible consumer-driven fetching, valuable when its strengths match your use case, not a replacement for anything, and best understood as one good answer among several rather than the answer. My early skepticism was about the hype, not the technology, and the technology earned a real place once the hype subsided.
References
- GraphQL Seems Like We Do Not Want To Do The Hard Work Of API Design
- The Why Behind The GitHub GraphQL API
- Revisiting GraphQL As Part Of My API Toolbox
- API Design Industry Guide: GraphQL, A Query Language For APIs
- GraphQL Thoughts After Almost Two Years
- GraphQL And REST Differences Explained With Burgers
- What Makes You Think Your GraphQL Consumers Will Want To Do The Work
- REST And Hypermedia And GraphQL And gRPC And Event-Driven
- The Open Source Community Tooling Built On GraphQL
- Aligning The API Specification Contribution Process Across OpenAPI, AsyncAPI, And GraphQL
- HTTP APIs And GraphQL, Event-Driven, And Model Control Protocol
