I Am Done With Graph QL After 6 Years

GraphQL’s biggest problem isn’t that it’s “bad”—it’s that exposing a query language to untrusted clients dramatically expands the security and performance burden, and the mitigations add enough complexity that many teams end up worse off than if they used a conventional, typed API. After years of championing GraphQL, the speaker says the tradeoffs become unacceptable once security, maintainability, and operational reliability matter more than developer convenience.

A central risk is attack surface. Because clients can request arbitrary shapes of data, attackers can craft queries that strain authorization logic, overwhelm CPU, or amplify resource usage. Authorization is the most widely understood threat: a fully self-documenting GraphQL endpoint requires field-by-field authorization in the context of the current user, not just coarse checks at the object level. The speaker argues that this is harder than REST’s typical model, where developers authorize endpoints rather than every field in every nested context.

Denial-of-service risk is framed as even more severe. GraphQL servers can’t assume requests are equally “expensive,” and there’s no simple, universal limit on query size or computational cost. Even with an empty schema, introspection types can be cyclic, enabling valid queries that return large JSON payloads or force the server to spend significant CPU time parsing and resolving. The speaker describes testing an attack against a popular GraphQL API explorer and seeing 500 responses after about ten seconds from a very small query, with the implication that a short curl loop can effectively “DoS yourself.”

Mitigations exist—query complexity limits, rate limiting, maximum depth, and stricter schema design—but they’re delicate to implement correctly. Complexity estimation can be wrong, especially with cyclic schemas (e.g., tags related to related tags), where errors can compound exponentially. Default maximum depth settings (the speaker cites GraphQL Ruby’s default of 13) help but don’t fully address the underlying issue: deeply nested queries are only one dimension of cost.

Performance concerns extend beyond security. The speaker highlights the N+1 problem caused by nested resolvers that trigger repeated database or HTTP calls, and argues that GraphQL often pushes data-fetching logic into the transport layer. Once authorization is integrated into resolvers, it can create a new class of N+1-like performance issues where authorization checks themselves hit the database repeatedly. Debugging also becomes harder because much of the behavior—authorization, data loading, error handling—occurs inside the GraphQL framework, leaving developers to interpret stack traces embedded in GraphQL error responses.

The conclusion is a conditional recommendation: GraphQL may still make sense when teams control all clients, use a statically typed language, and need GraphQL’s type-safe, self-documenting query experience. Otherwise, the speaker prefers OpenAPI 3.0-compliant JSON REST APIs, with tooling that generates typed clients and server handlers from specs. The broader message is that GraphQL’s flexibility can be a “hype-cycle” fit for early stages, but in sufficiently complex environments it can force teams into building and maintaining expertise—and infrastructure—to manage risks that simpler API styles avoid.