The Four Conditions That Make It Pay
The Four Conditions That Make It Pay
GraphQL is not a default; it earns its place when a specific set of conditions holds. The honest way to decide is to check them one at a time.
Condition 1: several client shapes over one dataset. Mobile cards, an admin table, and a marketing page all read the same products but want different subsets. Without GraphQL you either ship one bloated payload to everyone or build a backend-for-each-client, where the same business logic gets reimplemented three times and drifts apart.
Condition 2: screens that compose many resources. A dashboard needs users, their orders, order totals, and stock levels in one view. Resource endpoints answer "give me this entity"; a composed screen needs a traversal across entities in a single round trip.
Condition 3: frontend iteration outpaces backend releases. When design ships weekly and the API team ships monthly, every new field becomes a cross-team negotiation. Moving field selection to the client converts that negotiation into one additive schema change.
Condition 4: bandwidth or latency is a first-class constraint. Phones on weak networks, devices with metered data, or users far from the region. Collapsing four round trips and most unused bytes shows up directly in load and scroll metrics.
How the four interact. No single condition is decisive alone. One client with deeply composed screens still benefits from a graph, and four clients over one data set behind a slow release train is the classic case where GraphQL pays twice. Score each condition honestly and look for at least two before committing; a single hit usually means a targeted fix inside the existing API solves it cheaper.
If none of the four hold, you are buying complexity for fashion. In a design review, ask which condition the project satisfies and listen for a specific screen, client, or metric rather than an aspiration. "We might need flexibility later" is not one of the four.
Where REST Still Wins
Where REST Still Wins
The cases where REST is the better engineering choice are narrower than "REST is simpler," and they deserve precise statement.
- Cache-by-URL matters. A public, read-heavy API served through third-party proxies gets HTTP caching for free on GET and has to rebuild it for GraphQL. If the product promise is "responses are cacheable at the CDN," that is a REST-shaped requirement.
- The resource model is clean. CRUD over well-defined nouns with standard status codes (201 Created, 204 No Content) communicates intent that a JSON envelope cannot. Webhooks, callbacks, and file transfer fit the same mold: bytes in, bytes out, no selection set.
- One client, one team. A single internal tool with two endpoints gains nothing from a type system exposed over the wire; the same types can live in shared code between frontend and backend.
- Consumers want boring. Some API partners prefer predictable endpoints and a static description over a graph they must explore through introspection.
GraphQL also loses on non-functional axes that never appear in feature checklists:
| Axis | REST | GraphQL |
|---|---|---|
| Authorization | enforced per route | enforced per field, per type |
| Worst-case query cost | bounded by the route | bounded only if you add limits |
| Caching | existing HTTP caches | persisted queries and entity caches |
| Skill floor | familiar to most teams | schema design, resolver patterns, tooling |
That last row is the real price of admission. A team can ship competent REST on day one; a team ships competent GraphQL only after it owns schema governance and query safety.
The Complexity You Take On
The Complexity You Take On
Adopting GraphQL moves complexity rather than deleting it. Before committing, name each item and decide who owns it.
Resolver composition. One query fans out into many resolvers across databases, caches, and third-party APIs, and the fan-out is where performance bugs live: an unbatched nested list becomes one database query per row, the classic N+1 pattern. See the N+1 problem and DataLoader configuration.
Query cost control. Clients can request deeper nesting than you anticipated. Without depth limits and cost budgets, one curious request can walk the entire graph.
Field-level authorization. REST checks a route; GraphQL must check every field on every type, which means directives or wrapper logic rather than a middleware stack, see role-based field access.
Caching redesign. Both server-side caches and the client's normalized cache need identity rules: a stable id per type plus a plan for invalidation, see response caching strategy.
Schema governance. Someone must review each schema change for breakage, run schema checks in CI, and decide deprecation windows. Budget this before the number of clients multiplies; the fifth client arriving at an ungoverned schema is how teams end up afraid to change anything.
Tooling. Typed clients generated from the schema, a query linter, an exploration workbench. Code generation is cheap once the schema stabilizes and painful while it churns.
A path that avoids a rewrite
Run GraphQL beside REST rather than instead of it. Expose the read paths suffering most from waterfalls first, keep writes on the existing API until the graph proves itself, and migrate screen by screen. It is the strangler pattern applied to endpoints: measurable wins each sprint and a clean off-ramp if the bet fails.
Interview angle: expect "when would you choose GraphQL over REST?" to be followed by "and when would you not?" Answer the second half with three costs you have actually paid or would.
Practice Problems
Choose GraphQL, REST, or a hybrid for each scenario and justify the choice with one of the four adoption conditions or one concrete REST advantage. (1) A public weather API whose responses must be cached by third-party proxies and documented with a static spec. (2) A shopping app where the mobile home screen, checkout screen, and admin dashboard each read products, inventory, and users in different subsets, and design ships weekly. (3) A company with an existing REST API, an invoice screen that triggers five sequential calls, and a backend team of two.
Example:
Input: Scenario 1: public weather API, cache-by-URL requirement, static documentation
Output: REST
URL-keyed caching and a fixed, documentable surface are REST strengths; GraphQL would require persisted queries and entity caches to match what any proxy already does.
Optimal Solution — O(1) per scenario time, O(1) space
Score each scenario against the four adoption conditions (multiple shapes, composed screens, iteration speed, bandwidth) and against the REST advantages (cache-by-URL, clean CRUD, single client), then choose the smallest model that satisfies the requirement.
function chooseApiModel(scenario) {
const conditions = [
scenario.multipleClientShapes,
scenario.composedScreens,
scenario.frontendOutpacesBackend,
scenario.bandwidthConstrained,
];
const restAdvantages = [
scenario.needsUrlCaching,
scenario.cleanResourceCrud,
scenario.singleClientAndTeam,
scenario.fileOrWebhookTraffic,
];
const graphqlScore = conditions.filter(Boolean).length;
const restScore = restAdvantages.filter(Boolean).length;
if (graphqlScore >= 2 && restScore === 0) return 'GraphQL';
if (restScore >= 2 && graphqlScore === 0) return 'REST';
if (graphqlScore > 0 && restScore > 0) return 'Hybrid: GraphQL for the hot read paths, REST elsewhere';
return 'REST';
}Edge Cases:
- Scores tie: prefer REST, because it is reversible and GraphQL is not cheap to unwind
- A team with no schema governance owner should not adopt GraphQL regardless of scores
Quiz
1. A team has one web app, stable endpoints, and no plans for a mobile client. Which argument for GraphQL is strongest?
2. Which requirement pushes you back toward REST?
3. What is the biggest operational risk of exposing a GraphQL endpoint without cost controls?
4. Which adoption plan carries the least risk?
Flashcards
Question
The four conditions for adopting GraphQL
Click to reveal answer
Answer
Multiple client shapes over one data set; composed screens joining many resources; frontend iteration faster than backend releases; hard bandwidth or latency constraints.
Question
Top reasons to keep REST
Click to reveal answer
Answer
Cache-by-URL requirements, clean resource CRUD with standard status codes, file transfer and webhooks, single-client teams with no schema governance capacity.
Question
Complexity GraphQL adds on the server
Click to reveal answer
Answer
Resolver composition and N+1 risk, query depth and cost limits, field-level authorization, caching redesign, schema governance in CI, codegen and lint tooling.
Question
Low-risk adoption path
Click to reveal answer
Answer
Run GraphQL beside REST: start with read paths that suffer waterfalls, keep mutations on REST, migrate screen by screen, add governance before client count grows.
Revision Notes
Key Takeaways
- 1. GraphQL pays off only under specific conditions: many shapes, composed screens, fast frontend iteration, or tight bandwidth
- 2. REST wins when URL-keyed caching, file transfer, or a single client dominate the requirements
- 3. Adoption moves complexity to the server: resolvers, cost limits, field-level auth, caching, and schema governance
- 4. An incremental rollout beside REST proves the bet and keeps an off-ramp
Interview Tips
- • Answer both halves of "GraphQL or REST?" with conditions and costs, not brand preference
- • Name the governance work explicitly: schema review, CI checks, deprecation windows, and who performs them
Cheat Sheet
GraphQL adoption checklist
Adopt GraphQL when
- several clients need different subsets of one data set
- screens join many entities in one round trip
- frontend ships faster than the backend
- bandwidth or latency is measurable in product metrics
Keep REST when
- responses must cache by URL at public CDNs
- clean CRUD with 201/204 semantics, uploads, webhooks
- one client, one team, no schema governance owner
Budget for: resolver fan-out and N+1, depth and cost limits, per-field authz, cache identity, schema checks in CI, codegen
Rollout: read paths first, writes stay on REST, migrate per screen, govern before scaling clients.