Default to REST. GraphQL earns its place only when you have multiple clients pulling different shapes of the same data, and you’ve actually felt the pain of REST endpoints multiplying to serve them. If you’re building a single web app talking to your own API, GraphQL is complexity you’re choosing for no return.

Where REST just works

One backend, one or two clients, predictable data shapes. You write GET /orders/:id, it returns an order, done. Caching is free — HTTP caching, CDNs, and browser caches all understand REST out of the box because a GET request is a GET request. Debugging is a URL and a status code in your browser’s network tab, not a 200 OK wrapping a errors array you have to inspect to find out something actually failed.

The pain shows up when a mobile client wants a trimmed-down payload and a web dashboard wants the same resource with five nested relations. You either over-fetch on mobile or you write GET /orders/:id?include=customer,items,shipping and now you’re halfway to reinventing a query language badly.

Where GraphQL earns it

You have three or more clients with genuinely different data needs — web, iOS, a partner API — and REST has already forced you into either bloated responses or a combinatorial explosion of endpoints and query params. GraphQL lets each client ask for exactly the fields it needs in one request, which matters a lot on mobile where every extra field is bytes over a slow connection and every extra round-trip is latency.

It also earns its place when you’re aggregating several backend services into one API layer. A GraphQL gateway can resolve fields from different sources in a single client request instead of the client making three REST calls and stitching the result together itself.

What it costs you

• N+1 queries. A naive resolver that fetches a list, then fetches related data per item, turns one client request into hundreds of database queries. You fix this with a dataloader that batches and caches within a request — but that’s a library you now depend on and a pattern every resolver author needs to know.
• Caching gets hard. Every request is a POST to /graphql with a query in the body. CDN and browser caching, which just work with REST, need custom persisted-query setups to claw back.
• Auth moves to the field level. “Can this user see this order” is easy to check in a REST handler. “Can this user see this field on this nested object three levels deep” needs authorization logic in every resolver, or a schema-level directive system you have to build.
• Rate limiting by complexity, not by request count. A single GraphQL query can be arbitrarily expensive depending on what’s requested. You need query cost analysis or depth limiting, which REST never asks of you.

The comparison

	REST	GraphQL
Caching	Free (HTTP)	Needs custom setup
Client flexibility	Low	High
Over/under-fetching	Common	Solved by design
Debugging	curl and a status code	Needs tooling
Ops complexity	Low	Higher (N+1, cost limiting)

The call

If you’re a small team shipping one product with one or two clients, build REST. You’ll ship faster and debug faster. Revisit GraphQL only when you can point at a real symptom — a mobile app burning data on bloated responses, or a public API where third parties keep asking for endpoints that don’t exist yet. Adopting GraphQL because it’s what larger companies use is how a two-person team ends up maintaining a dataloader cache instead of shipping features.

---