When Not to Use GraphQL

GraphQL gives clients something REST APIs often do not: the ability to ask for the exact shape of data they need.

That is extremely useful when several frontends consume a rich domain model.

It can also be unnecessary infrastructure for an API that has twelve straightforward endpoints.

GraphQL is a query language and runtime built around a typed graph of data. The official documentation also makes an important point: many practical concerns such as transport, authorization, pagination and caching require conventions beyond the core GraphQL specification.

1. Your API is already simple

Imagine an internal service exposing:

GET /health
GET /users/:id
POST /users
GET /invoices/:id
POST /invoices/:id/pay

One frontend consumes it.

Every response is small.

The requirements barely change.

What exactly does GraphQL improve?

Instead of five obvious routes, you may now introduce:

schema
types
queries
mutations
resolvers
GraphQL server
client library
generated types
query documents

Those things can be useful.

But they are not free.

GraphQL’s flexibility becomes much more valuable when clients need different views over interconnected data.

If everybody asks for the same resources in the same shapes, ordinary HTTP endpoints can be pleasantly boring.

2. Your HTTP caching strategy is already excellent

REST-style APIs naturally map resources to URLs:

/products/123
/articles/456
/categories/technology

That can make HTTP caching, CDN caching and invalidation conceptually straightforward.

GraphQL commonly routes operations through one endpoint.

That does not mean GraphQL cannot be cached.

Official GraphQL performance guidance notes that query operations can use HTTP GET, hashed documents and other techniques to support CDN and HTTP caching.

But if simple resource-oriented caching is one of your architecture’s biggest strengths, GraphQL may require more design and tooling than simply continuing to use those resource URLs.

The question is:

Does GraphQL’s query flexibility buy enough to justify changing the caching model?

Sometimes yes.

Sometimes definitely not.

3. Your API is primarily for file transfer

Suppose your service mostly does:

upload video
download PDF
upload medical scan
download archive
upload images

GraphQL is not particularly natural here.

The GraphQL Foundation’s documentation says GraphQL was not designed with file uploads in mind and recommends approaches such as signed upload URLs rather than pushing large binary data directly through GraphQL.

A practical architecture may be:

GraphQL
   ->
request signed upload URL

Client
   ->
Object Storage

That can work beautifully.

But if binary transfer is the product, straightforward HTTP endpoints or direct object-storage APIs may be the simpler core interface.

4. Flexible queries are a liability, not a feature

Consider an endpoint:

GET /dashboard

You control exactly what it does.

Now consider a GraphQL client capable of requesting deeply nested relationships.

That flexibility is powerful.

It also means server cost can depend heavily on the query.

A poorly controlled operation might request:

companies
  employees
    projects
      tasks
        comments
          authors

and suddenly one HTTP request translates into a large amount of backend work.

Production GraphQL systems therefore often need:

pagination
query depth limits
query breadth limits
batching
caching
rate limiting
cost analysis
observability

Official GraphQL performance guidance recommends pagination, controlling operation depth/breadth and rate limiting, and discusses batching/caching to address N+1-style execution issues.

If your API must expose only a tiny set of tightly controlled operations, REST/RPC may be easier to reason about.

5. You have one client and the backend owns the UI contract

GraphQL becomes particularly compelling when different consumers need different fields.

For example:

Web app
Mobile app
Admin app
Partner app
TV app

The mobile screen might need five fields while the administration console needs fifty.

GraphQL lets each client describe what it wants.

But if you have exactly one client and the backend team already publishes purpose-built endpoints for each screen, you may be solving a problem you do not have.

A purpose-built endpoint like:

GET /dashboard-summary

can be completely acceptable.

Not every API needs to become a general-purpose query surface.

6. Your organization is not ready to govern a shared schema

A GraphQL schema can become an extremely useful contract.

It can also become a junk drawer.

At first:

type User
type Product
type Order

Two years later:

duplicated fields
deprecated fields
inconsistent naming
unclear ownership
business logic in resolvers
multiple ways to fetch the same thing

Once many teams depend on one schema, changing it requires discipline.

Schema reviews, ownership, deprecation policies, observability and conventions become organizational concerns.

This is not an argument against GraphQL.

It is an argument against thinking GraphQL eliminates API design.

GraphQL makes API design more visible.

7. You are choosing GraphQL just to avoid over-fetching

Over-fetching is real.

Suppose:

GET /user/123

returns 40 fields when your mobile screen needs 4.

GraphQL solves that elegantly.

But before introducing an entirely new API paradigm, consider whether simpler approaches solve the actual problem:

smaller response DTO
?fields=
dedicated endpoint
server-side aggregation endpoint

If over-fetching is causing meaningful performance or product problems across many clients, GraphQL becomes more attractive.

If you are saving 800 bytes on an internal dashboard request, maybe not.

When GraphQL IS a Great Choice

GraphQL tends to shine when:

several clients need different representations of the same underlying data
the domain contains rich relationships
frontend teams need to evolve independently
aggregating multiple backend sources behind one graph provides real value
reducing multiple client round trips materially improves the experience
a strongly typed shared API schema helps development

Its ability to let fields accept arguments and traverse related objects means one operation can express data requirements that might otherwise require several separate resource requests.

GraphQL vs REST

Requirement	GraphQL	REST
Client-selected fields	Excellent	Usually fixed
Multiple frontend needs	Excellent	Good
Simple CRUD API	Good	Excellent
Standard resource URLs	Different model	Excellent
Straightforward HTTP caching	Possible with design	Excellent
File transfer	Poor as direct transport	Excellent
Deep interconnected data	Excellent	Can require several requests
Server query-cost predictability	Requires controls	Usually simpler

Should You Use GraphQL?

GraphQL is worth serious consideration if:

clients genuinely need different data shapes
the data is naturally graph-like
frontend developers are blocked by rigid backend endpoints
several services can benefit from a unified API layer
your team is willing to own schema governance and query performance

Think twice if:

your API is already small and understandable
every client requests nearly identical responses
direct file transfer dominates the workload
predictable fixed endpoint cost matters more than query flexibility
your main reason is that GraphQL feels newer than REST

The strongest reason to introduce GraphQL is not:

REST is old.

It is:

Our consumers need a flexible data graph, and maintaining purpose-built endpoints for every data shape has become the harder architecture.