Whatever happened to GraphQL?
The ascendant, next-gen API that never quite took over
For those who remember, there was a period of time roughly between 2018-2021 when GraphQL was all the rage, so to speak.
It was a hot item in the technology world at a time when all the market gaps SaaS could theoretically fill were being plugged as rapidly as possible which in turn incentivized heavy investment into simplified, standardized tooling to reduce that time-to-market metric as far as possible.
While some technology strategies veered off into no-code solutions, others pushed forward in the evolution of software engineering toward reusable patterns and frameworks that reduced the need for every startup to re-invent the wheel on common technology implementation questions.
React offered a relatively small but powerful abstraction that would reduce the learning curve for newcomers and rookies to be able to build web apps all on their own.
Coding bootcamps became a supposed one-way ticket into the lavish payscale of technology jobs with many touting their credentials as MERN or PERN full-stack engineers after a month or two of training.
Next.js would build off React to offer even further abstraction to make rapid prototyping even more effortless. Few acknowledge that the mixed to relative success of LLMs to “vibe code” web applications is due in large to how simple this has become through platforms like Vercel and Next.js.
It is easy to tie together the strands of success in the train of evolution.
But GraphQL is something else.
During the peak of its hype train, GraphQL was going to displace RESTful API development as the universal solution. REST APIs were going to become obsolete. GraphQL would revolutionize the whole philosophy of middleware. At least by some accounts.
But this did not happen.
It has been adopted at a large scale as a solution for some of the time, but certainly not all of the time.
There was not a decisive push to integrate it universally in the same way that generative AI has since the GraphQL craze.
Why is that?
Let us find out. We are barely going to even touch the nuts and bolts of GraphQL here, but rather look at its history and reception.
What is GraphQL?
No proper post-mortem can begin without an account of the history and origins of its subject.
Like React, GraphQL is a baby of Facebook/Meta. Also like React, it was born to solve the same penumbra of problems around standardization and consistency.
In 2011 and 2012, smart phone adoption was close to solidified, and the world of mobile apps was about to explode.
Facebook was consolidating its leadership over the social media market on desktop and needed a firm way to entrench itself in the mobile app experience as well.
How does one build an application that can interface with Facebook’s vast troves of data from the limited power and performance of an early smartphone?
What React was on the software side, GraphQL was on the query language side.
As described in GraphQL’s 2015 prospectus when it became open source, the Facebook teams needed to find a consolidated, centralized interface for delivering feature like News Feed without the complexity of data shape transformation required between the client and server.
This document details several advantages toward the GraphQL way:
Data shape: The query response mirrors the shape of the request
Hierarchy: Embedded objects in one single query without multiple queries
Strongly typed: Each level of the GraphQL query has strong typing to validate query structure and types before execution.
Protocol: It is a stateless middleware, not a storage backend to manage
Introspective: It can be queried about itself rather than needing to go review a spec elsewhere
Version-light: The returned data’s shape is determined by the client not the server
Given these points, those with enough REST API heartburn could see the appeal of such a revolutionary approach, especially when it brands itself as “product-centric”, highly suitable for the rise of rapid SaaS development.
But Why GraphQL?
The developers and maintainers had their own reasons for suggesting that GraphQL was “better”, but let us dive into some points from the broader online discourse about this new technology, particularly its apologists.
1. RESTful Is Not Modern
This is a subjective claim to be sure, but it is one that has been asserted by those who would rather see GraphQL displace REST API.
There are several common areas of complaint here.
REST produces a sprawl of endpoints at scale. Each new capability requires a new endpoint. Every new resource requires a whole new set of endpoints for all its associated verbs. The growing surface area introduces overhead, risk of inconsistencies, and dependencies between endpoints.
REST couples resources with teams which does not align with modern enterprise domain-driven design. To maintain a comprehensive Enterprise REST API requires complete and total coordination between teams on resources, including cross-domain calls and versioning. At least so critics claim.
RESTful routes mirror the page-based implementation of early web applications, not modern single page applications which are component-driven. This leads REST to consistent over and under fetching of data with the client jumping through hoops to get what it needs from the server.
REST does not offer type safety for API queries. If we have TypeScript for JavaScripts and ORMs for database transactions, the lack of type safety is a significant weakness.
More could be said here on the nature of these issues, including a defense of REST and it has evolved in recent years, but our main focus here is the sentiments which drove GraphQL proselytization.
At the very least, many of these are certainly understandable complaints for those trying to build with REST in a modern world and more than sufficient justification to seek to build something better.
2. Strong Contracts
If there is one positive thing which GraphQL advocates unanimously praise about this framework, it is the type safety.
In the world of client-server calls, strong contracts and type safety offer guarantees that eliminate a whole range of errors around what can be quite simply labeled “miscommunication” between two different systems.
The contract guarantees that a server will receive an object of a valid shape and type (enforced from the client side), while the client will receive a valid response object from the server (enforced before the response is sent).
Additionally, GraphQL offers resolvers with the intelligence to filter and pare down fields just to what is needed, a far cry from the data dumps one could easily find in a REST JSON response body. Where REST is verbose, GraphQL is clean and minimal.
Furthermore, GraphQL decouples the API contract from a backend implementation without exposing an entire DB implementation or schema to a client, a common antipattern that can emerge when DB schemas are treated as an API interface.
Critics would of course counter that OpenAPI offers the same kind of contract guarantees or one could opt for less over-engineered solutions for this kind of type safety, but this is still one broadly defended point around the advantage of GraphQL.
3. Decentralized Ownership
As noted above, scaling RESTful APIs is not necessarily easy, considering how resources and routes are coupled in awkward ways with their backend teams.
GraphQL offers far more flexibility and clarity for the delegation of subgraphs or namespacing of the graph to backend teams so that different departments or teams can still expose their data in a shared enterprise GraphQL endpoint but without the clumsiness involved with such schema maintenace.
Put simple, the subgraph is far more suited to microservices, as teams seek to evolve away from monolithic implementations.
4. Cloud Infrastructure
While decoupling subgraphs from a single maintainer, GraphQL’s philosophy of encapsulation behind one single API surface blends very well with modern cloud infrastructure as well.
And because it is decoupled from backend implementation, it can simultaneously route requests to various microservice backends, including serverless functions such as AWS Lambda with far more sophistication and flexibility than other traditional API implementations.
This in addition to managed CSP offerings for GraphQL such as AWS AppSync or simply throwing together a containerized Apollo server is cited as a reason many prefer GraphQL.
On the flip side, this advantage is somewhat neutralized by the fact that many serverless or cloud-native frameworks exist around the RESTful model. Serverless and AWS SAM, for example. It is not clear when GraphQL developers cite this advantage what these other frameworks lack on the cloud infrastructure front.
5. General Developer Experience
A few other miscellaneous points to be put under DevEx, in favor of GraphQL.
The schema evolution is much more flexible and clean, particularly in that GraphQL avoids versioning as much as possible. Versioning of course is required to account for the limited controls around API endpoints particularly when there are weak contracts.
The implementation philosophy behind GraphQL focuses on only returning the data that is explicitly requested. Fields will always resolve the way they need to by the client, without needing to jump through the hoops of server-side requirements in the way that REST implementations demand.
Additionally, data can be composed with considerable ease through the graph approach which makes data population in UI flows much cleaner and easier to develop. These can be whipped together in a single query rather than needing to juggle a set of queries and/or transforms based on the server-side logic.
Colocation of data is a developer experience positive that is hard to overlook when one has experienced it “done right”.
This all ties into a modern web-app style approach which is component-level driven, at its very root. It integrates natively with much of the UI web app ecosystem, for example in its helpers for pagination, suspense/defer fragments, and even an eslint plugin to offer guardrails.
Much of the “it just works” which drives modern software development, finds a well-matched companion in the world of GraphQL.
But then… Why Not GraphQL?
We could go much deeper into the terminology and protocols and patterns of GraphQL. It was difficult enough to avoid this in speaking of its advantages, but that is not the drive of this piece, and there are better places to consider its technical underpinnings and internal technical dialogue more in depth.
Again, we are considering the broad sentiments which led to its rise and normalization, rather than its anticipated universalization.
So while we have seen many of the reasons put forth in favor of GraphQL adoption, particularly in that hype phase, I would like to present some of the arguments presented against GraphQL adoption in the years since then.
1. Overengineering
The risk of any new technology that purports to be a solution is the possibility that the cognitive load or overhead it takes for (1) humans to learn as practitioners, (2) it to be integrated within a larger technical ecosystem, or (3) LLMs to interface with it relatively intelligently can outweight the benefits it ostensibly brings.
The risk of overengineering, more or less.
And this seems to be one of the most common complaints more or less in the developer community around GraphQL.
The advantages that GraphQL offers in terms of type safety and strong contracts, many REST developers claim they can easily solve through the allegedly more minimal implementation of OpenAPI and/or TypeScript.
These previous downsides are purportedly solved through minor alterations or layering without needing the full paradigm shift of GraphQL.
Of course, many GraphQL are equally convinced that OpenAPI is hardly a less verbose and simpler alternative.
Whether one goes implementation first or specification first, it seems REST offers its own modern suite of solutions that does not require the GraphQL jump.
These criticisms extend also to AuthZ overhead, schema evolution, and more. But this is the fundamental principle.
2. Security Considerations
Aside from what are arguably more subjective contentions around GraphQL as an overengineered solution, there are more objective concerns about it from a security perspective.
By minimizing client overhead and shifting the logic to server-side orchestration, by allowing a single logical endpoint to fetch any number of permutations of data and data shapes from various backends, the question becomes how one can properly AuthZ (i.e. that you are authorized to receive the data you are asking about).
REST APIs have generally solved for this through integration with OAuth, identity tokens, access tokens, scopes, claims, etc. These are applied at the endpoint level though.
If GraphQL boasts a single endpoint per environment, how can AuthZ be engineered or implemented within a single endpoint?
Additionally, the hyper-flexible nature of GraphQL queries lead to a variety of security vulnerabilities, not least of all disclosing broad swathes of one’s schema to potential bad actors if they simply invoke the Introspection Query.
This could further be exacerbated by malicious actors who could easily execute a DoS attack by hitting the GraphQL server with expensive queries, including cyclical or recursive queries depending on the complexity and internal relationships of the data shape.
Which leads us into the next issue.
3. Performance and Rate Limiting
Depending on how deeply nested the data shape is, overly broad GraphQL queries can not only be computationally expensive to perform but also have high latency as they solve both horizontally for various data backend providers (hitting each of them individually or even redundantly perhaps) or vertically with increasingly deeply nested layers of data.
This is further compounded by trying to layer AuthZ on top of deeply nested queries.
The computational lift to not only resolve all data fields but determine AuthZ for each and individual fields introduces another N+1 problem on the performance side.
So ironically while many argue GraphQL is overengineered for simple use cases and small developer teams, it actually struggles to scale elegantly in enterprise data environments.
By offsetting so much of the logic to the GraphQL resolver server, what should in theory just be a minimal, centralized controller becomes a monolithic bottleneck even in microservice-driven architectures.
Of course, a counter argument would be that one could mitigate this through proper federation and gateway implementation and that this is simply the result of GraphQL antipatterns rather than the GraphQL philosophy.
4. Maintenance Complexity
But in any case, Any experienced owner-operator can begin to imagine the onslaught of complexity that these considerations bring into view.
Beyond what has been mentioned above, other GraphQL maintainers are rather critical of schema evolution and management as well.
Since GraphQL’s philosophy is that there should never be a breaking change and thus versioning is not needed, many are compelled to go through inordinate level of effort or gymnastics to fulfill such a contractual promise.
Versioning is a critical tool in a world of finite operational resources to meet one's contractual agreements as a service provider within a specific window while accepting the iterative nature of software or API development.
To commit a service provider to support any and all iterations of not only a middleware to meet the needs of both clients and server backends can prove quite a miserable vow to live through in the long run.
This in addition to the fact that modern enterprise teams are not quite coupled in the ways that GraphQL presumes can add to the disconnect and enteprise acrobatics that it was originally supposed to mitigate.
It is understandable in this way how many could be burnt out on the GraphQL option if this is their primary experience with it.
Conclusion
What are we to make of us all this?
Although such criticisms are rather serious, this does not mean that GraphQL is dead. It remains quite popular as one solution among many, but it is not the universal displacer that many heralded it to be even as recently as a few years ago.
It will remain a popular, well-supported technology for some time, barring any paradigm-shifting developments which may either render it obsolete or reinvigorate it, such as the purported third wave of GraphQL in light of agentic AI.
It seems that GraphQL is one of those overly celebrated even if at least somewhat ingenious technologies that succeeded on some level but not without some degree of failure.
A failure (if it can be called so) to have the luck or foresight to identify developments in the cloud and IT world as well as its own logic at scale. Both of which are divergences from the original intent of GraphQL’s design in the early 2010s that substantially undermined its universal adoption and made REST API a framework that faded as definitively as SOAP.
In its defense, one could argue that it was not meant to be applied or implemented universally, this was merely the zeitgeist of the hype train which overplayed its use cases. Even so, it remains a curious case study.
That is why we explore new technologies and ideas, and why things fail. Whether through failure of design or implementation.
So that we ourselves can iterate upon the past and build better, build smarter.
Sources
Acjay. “GraphQL Was Not the Future.” August 14, 2024. acjay.com/2024/08/14/graphql-was-not-the-future/.
Bessey, Matt. “Why, after 6 Years, I’m Over GraphQL.” May 24, 2024. bessey.dev/blog/2024/05/24/why-im-over-graphql/.
Giroux, Marc-Andre. “Why, after 8 Years, I Still Like GraphQL Sometimes in the Right Context.” May 31, 2024. magiroux.com/eight-years-of-graphql.
Hygraph. “Why the Future of AI Is GraphQL.” Hygraph Blog, November 24, 2025. hygraph.com/blog/why-the-future-of-ai-is-graphql.
“Eight Years of GraphQL.” Discussion on Hacker News, July 17, 2024. news.ycombinator.com/item?id=46264704.
Grafbase, Inc. “Why GraphQL Is Eating the API World.” May 29, 2025. grafbase.com/blog/why-graphql-is-eating-the-api-world.
GraphQL Steering Group. GraphQL: A query language for your API. graphql.org.
GraphQL Project. “GraphQL: A data query language.” graphql.org/blog/2015-09-14-graphql. Published September 14, 2015. https://graphql.org/blog/2015-09-14-graphql.
WunderGraph. “Six-Year GraphQL Recap.” Wundergraph Blog, December 3, 2025. wundergraph.com/blog/six-year-graphql-recap.
WunderGraph. “GraphQL, REST, and OpenAPI Trend Analysis 2023.” Wundergraph Blog. wundergraph.com/blog/graphql_rest_openapi_trend_analysis_2023.
OWASP Foundation. “Testing GraphQL.” In Web Security Testing Guide (WSTG) v4.2, API Testing. OWASP.org. owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL.