I've spent the last twelve months working with GraphQL in enterprise environments. Two projects adopted it. One was a clear success. The other was a clear mistake. The difference had nothing to do with GraphQL itself and everything to do with whether the problem matched the solution. The industry conversation around GraphQL is too binary - either it's the future of APIs or it's an unnecessary complication. The reality is more specific.
What You Need to Know
- GraphQL solves real problems: over-fetching, under-fetching, and the multiplication of REST endpoints in complex applications
- In enterprise, GraphQL introduces complexity in caching, authorisation, and performance monitoring that REST doesn't have
- GraphQL excels when multiple clients need different views of the same data. It struggles when the data model is simple or the consumers are uniform
- Don't adopt GraphQL because it's modern. Adopt it because you have the specific problems it solves.
Where GraphQL Wins
The Multiple Consumer Problem
The project where GraphQL worked was a platform serving three different frontends: a web dashboard, a mobile app, and a partner API. Each consumer needed different subsets of the same data. The dashboard needed full customer records with transaction history. The mobile app needed customer names and recent transactions. The partner API needed aggregated data without personal information.
In REST, we'd have three options: one endpoint that returns everything (over-fetching for mobile and partner), three separate endpoints (duplication), or a query parameter system that becomes its own API language. GraphQL gave each consumer exactly the data it needed from a single schema.
62%
of API developers report that REST endpoint proliferation is a top pain point in enterprise systems
Source: SmartBear State of API Report, 2020
Schema as Documentation
GraphQL's typed schema is self-documenting. Every field has a type. Every relationship is explicit. Every query is validated against the schema before execution. For enterprise systems where API documentation is perpetually outdated, the schema becomes the source of truth.
Our frontend developers could explore the API through GraphiQL without reading documentation or asking the backend team. That's a genuine productivity improvement in an environment where "check with the backend team" was adding days to development cycles.
Where GraphQL Struggles
The Project That Failed
The second project was a straightforward CRUD application. One frontend. One backend. Simple data model. We adopted GraphQL because the team wanted to learn it and I said yes.
The result: more complex than it needed to be. Setting up the resolver layer took longer than building REST endpoints would have. Caching was harder because GraphQL responses don't map cleanly to URL-based cache keys. The N+1 query problem surfaced immediately and required DataLoader to solve. For a simple application with predictable data access patterns, GraphQL added tooling and complexity without delivering proportional value.
Caching
REST APIs cache naturally. Each URL is a cache key. CDNs understand it. Browser caches understand it. HTTP headers handle invalidation.
GraphQL sends POST requests to a single endpoint. The response depends on the query body, not the URL. Caching requires either a persistence layer like Apollo Client's normalised cache, or server-side strategies like persisted queries. It works, but it's more effort and more infrastructure than REST's built-in caching model.
In REST, caching is a feature of the protocol; in GraphQL, it's a feature you build. For simple applications, that cost isn't justified.
John Li
Chief Technology Officer
Authorisation Complexity
In REST, authorisation can happen at the route level.
/admin/users requires admin rights. Simple. In GraphQL, the same endpoint serves all queries. Authorisation must happen at the field level or resolver level. "This user can see customer names but not billing details" requires field-level permission checks across the schema.This is solvable with middleware and directive-based authorisation. But it's more complex to implement and harder to audit than REST's route-based model. In regulated enterprise environments where "who can see what" needs to be clearly documented and auditable, this complexity is significant.
Performance Monitoring
With REST, you know that
GET /api/customers takes 200ms. You can monitor it, alert on it, trace it. With GraphQL, a slow response might be caused by one expensive field in a large query. Identifying which field is the bottleneck requires query-level tracing that most monitoring tools don't provide out of the box.Apollo Studio and similar tools address this. But they're additional infrastructure. If your team doesn't invest in GraphQL-specific monitoring, performance issues will be harder to diagnose than with REST.
The Decision Framework
Choose GraphQL when:
- Multiple clients need different views of the same data
- The data model has deep relationships that clients traverse differently
- The team has experience with GraphQL or time to invest in learning
- The API will evolve frequently and clients need to adopt changes gradually
Choose REST when:
- One or two consumers with predictable data needs
- Simple CRUD operations
- Caching is critical and should be simple
- The team is most productive with REST
Choose neither blindly. The worst outcome is adopting GraphQL because it's fashionable and then fighting its complexity for years. The second worst outcome is sticking with REST when your endpoint count is spiralling and your mobile team is over-fetching megabytes of data they don't need.
The right API strategy is the one that matches the problem you actually have.
GraphQL vs REST: Enterprise Suitability by Use Case
Source: RIVER Group Assessment, 2021