REST vs GraphQL: Which One Does Your Project Need?

GraphQL is often presented as the modern replacement for REST. It is not a replacement; it is a different set of trade-offs that solves specific problems very well and adds cost everywhere else.

The problems GraphQL was built to solve

Over-fetching

A REST endpoint returns a fixed shape. If you need a user name and the endpoint returns a 40-field object, you download 39 fields you discard. On mobile networks at scale this is real.

Under-fetching and waterfalls

To render one screen you call /user, then /user/posts, then /posts/comments — each waiting on the last. GraphQL asks for all of it in one round trip.

Many different clients

When a web app, an iOS app and a smart TV app each need different slices of the same data, REST tends to grow either bloated endpoints or a proliferation of near-duplicate ones. GraphQL lets each client ask for what it needs.

What GraphQL costs

The tutorials skip this part.

• Caching gets hard. REST gets HTTP caching almost for free — CDNs, browsers and proxies all understand it. GraphQL usually posts to a single endpoint, so you build caching yourself.
• The N+1 problem. A nested query can quietly fire hundreds of database calls. Solving it means DataLoader and careful batching.
• Rate limiting and abuse. A single malicious query can be arbitrarily expensive. You need query depth limits and cost analysis.
• File uploads are awkward and need a separate convention.
• Error handling is unusual — GraphQL returns HTTP 200 with an errors array, which breaks a lot of standard tooling assumptions.
• More moving parts: schema, resolvers, a client library, and often codegen.

What REST still does better

• HTTP caching, CDN caching and conditional requests work out of the box
• Every developer already understands it — no onboarding cost
• Debugging is trivial: paste the URL in a browser
• File uploads and downloads are native
• Status codes carry meaning that monitoring tools already understand
• Simpler to secure, because each endpoint has a bounded cost

The rule I use

Choose GraphQL when at least two of these are true:

1. Three or more distinct clients consume the same data with genuinely different shapes
2. Your data is deeply relational and screens routinely need three or more levels of nesting
3. You have measured over-fetching as an actual problem, not assumed it
4. Your team has run GraphQL in production before

Otherwise choose REST. For a single web app with a Next.js frontend, REST is almost always the right answer, and the projects I have seen regret their API choice went the other way far more often.

A REST API worth having

Most complaints about REST are complaints about badly designed REST. A good one:

• Uses nouns and plurals: /users, /users/42/orders
• Uses the right method and the right status code — 201 for created, 422 for validation failure, 404 for genuinely missing
• Supports field selection where it matters: /users?fields=id,name
• Paginates consistently, with a documented cursor or page parameter
• Returns errors in a stable shape the client can rely on
• Is versioned before you need to break something, not after

Field selection alone removes most of the over-fetching argument for a two-client system.

The middle ground people forget

You can also just build endpoints shaped like your screens. A /dashboard endpoint that returns exactly what the dashboard needs, assembled server-side, is unfashionable and extremely effective. One round trip, cacheable, no schema layer.

This is what many teams end up doing after adopting GraphQL and discovering the caching problem.

And if you already picked wrong

Both can coexist. Adding a GraphQL layer over an existing REST API is a normal migration path, and exposing a few REST endpoints alongside GraphQL for uploads and webhooks is standard practice. This is not a decision you have to get right forever — just right enough to ship.