By ByteBot
A blog post published this morning declares “GraphQL: the enterprise honeymoon is over“—and the Hacker News debate (123 points, 94 comments) reveals this isn’t just one developer’s complaint. Ten years after GraphQL’s 2015 release, early adopters are hitting a disillusionment phase. John James’ viral critique joins a growing 2025 trend: articles titled “GraphQL Was a Mistake” and “After 6 years, I’m over GraphQL” are multiplying. The pattern is familiar—NoSQL hype gave way to SQL’s comeback, microservices everywhere yielded to renewed monolith appreciation. Now it’s GraphQL’s turn to face reality.
The Overfetching “Solution” That Just Moves the Problem
GraphQL’s number one promise is eliminating overfetching. But here’s the reality most enterprises discover too late: if your downstream services are REST—and they usually are—you’re just moving the problem down a layer, not solving it.
James puts it bluntly: “You didn’t eliminate overfetching. You just moved it down a layer.” Most enterprise architectures already use Backend-for-Frontend (BFF) patterns that scope responses to client needs. Your GraphQL layer still has to overfetching from those REST endpoints, then reshape the response. The net result? Same overfetching, now with GraphQL’s added complexity.
Consequently, if you already have BFFs solving the overfetching problem, GraphQL becomes a redundant complexity layer. You get all the downsides—learning curve, security burden, caching nightmares—without proportional benefit. GraphQL’s flagship selling point evaporates the moment you acknowledge your microservices architecture isn’t changing.
GraphQL vs REST: Caching Nightmares REST Solves Out-of-Box
Fifty-six percent of teams report caching challenges with GraphQL. The root cause is fundamental: traditional HTTP caching doesn’t work because GraphQL uses POST requests to a single endpoint, and HTTP caches won’t cache POST.
REST gives you browser and CDN caching automatically with standard cache headers. In contrast, GraphQL forces you to engineer custom solutions: Apollo Client with its normalized cache, persisted queries, or GET request workarounds that hit URL length limits on complex queries. Apollo’s caching is “theoretically impressive but fragile in practice,” as James notes—queries differing by a single field need manual configuration to avoid redundant roundtrips.
This is the recurring theme: GraphQL “optimizes consumption at the cost of production speed,” and in enterprise environments, production speed matters more than theoretical elegance. Therefore, what REST hands you for free becomes a specialized engineering problem GraphQL demands you solve.
Security Vulnerabilities Most Teams Aren’t Ready For
Eighty percent of GraphQL APIs are vulnerable to DoS attacks, according to 2025 security audits. The attack surface is non-obvious: a single nested query can generate thousands of database queries, and traditional endpoint-based rate limiting doesn’t help when all queries flow through one endpoint.
A simple query costs 1 unit. However, a deeply nested query might cost 1,000 units. Both count as “1 request” in traditional rate limiting. In January 2025, a major e-commerce platform suffered a 3-hour outage when attackers exploited exactly this—nested queries overwhelming the backend.
The fix isn’t built-in. You need query complexity analysis (assign weights to fields, calculate costs, reject expensive queries), depth limiting (prevent nested queries—requires custom implementation), and resource-based rate limiting tracking complexity over time. OWASP’s GraphQL security guide runs to 13 vulnerabilities requiring specialized mitigation. Moreover, REST’s attack surface is well-understood; traditional security works. GraphQL security is complex, non-obvious, and demands expert knowledge most teams don’t have. As James notes: “This matters when you’re on call.”
The N+1 Performance Trap
Thirty-four percent of poorly optimized GraphQL implementations hit N+1 query problems. Fetch 100 users, trigger 100 separate queries for each user’s posts—101 total queries instead of 2. When n grows large, performance collapses. Slow responses, spinning loaders, frustrated users.
The solution GraphQL requires is DataLoader, Facebook’s batching tool that must be implemented in “nearly every resolver” according to Apollo’s documentation. Additionally, you need eager loading strategies, performance monitoring with OpenTelemetry, and query complexity analysis. None of this is out-of-the-box. It demands specialized GraphQL knowledge that most teams lack. REST developers already know how to avoid N+1 with proper SQL joins. What looks elegant in GraphQL demos becomes a performance trap in production.
When GraphQL Actually Makes Sense
GraphQL isn’t bad—it’s niche. It works brilliantly for platform companies serving diverse, unpredictable external users. GitHub’s public API serves millions of developers with vastly different data needs. Shopify reduced query costs by 75% and announced “going all-in on GraphQL” in October 2024. Netflix unified their iOS, Android, and TV APIs into a single federated GraphQL layer after their separate-API-per-platform approach “couldn’t scale with the business anymore.”
The pattern is clear: platform companies serving external users, where client needs are genuinely unpredictable, and teams willing to invest heavily in GraphQL infrastructure and expertise. These are not typical enterprise scenarios.
Most enterprises serve internal APIs to known clients—a web app, a mobile app. Client needs are controlled and predictable. Furthermore, the BFF pattern already addresses overfetching. GraphQL adds complexity without solving problems you actually have. The honest question becomes: Do you have GraphQL’s problem, or do you just have GraphQL?
The Disillusionment Phase Arrives
The enterprise GraphQL journey follows a predictable arc. From 2015 to 2020: hype (“GraphQL is the future!”). From 2020 to 2023: adoption (Fortune 500 companies saw 340% growth, over 60% of enterprises now use GraphQL). From 2024 to 2025: disillusionment (“This is harder than we thought”). Hacker News threads titled “GraphQL kinda sucks” and “After 6 years, I’m over GraphQL” multiply. James’ honeymoon article goes viral today. Nevertheless, REST still powers 83% of web services.
The technology itself isn’t the villain—it’s the mismatch between marketing and reality. GraphQL was oversold as a universal API solution when it solves a specific, narrow problem that most enterprises don’t have. If you’re not GitHub, Shopify, or Netflix, GraphQL likely introduces complexity disproportionate to the value it delivers. The honeymoon is over. Time for a pragmatic reassessment of whether GraphQL actually fits your use case—or whether REST plus BFFs already gave you everything you needed.
