GraphQL vs REST in 2026: A Decision Framework, Not a Religious War

GraphQL is a query language. Its core feature is that the client decides the shape of the response. This trades a huge amount of client-side flexibility (fetch exactly the fields I need, join across resources in one request) for server-side complexity (resolvers, N+1 avoidance, query cost analysis, caching by response shape).

REST is a resource-oriented convention. Its core feature is that every URL is a noun with a predictable set of verbs. This trades some client flexibility (over-fetching, multiple round trips) for radical simplicity: HTTP caching, standard tooling, and a mental model every developer already has.

• You have a rich domain graph (10+ interlinked entities) and clients regularly need custom slices.
• You have many client types (web, iOS, Android, embedded) with different data needs.
• Backend teams are being blocked constantly by 'can you add this field to the endpoint'.
• You're building an internal API where clients and server are in the same organization.

The Facebook origin story is the archetype: dozens of mobile clients, deeply interlinked social graph, product teams that couldn't wait for backend releases. If that shape matches yours, GraphQL is the right answer even with its costs.

• Public API for third parties — REST is what they expect and their tools support it.
• APIs consumed by LLMs — OpenAPI schemas map directly to tool-calling, GraphQL doesn't.
• Simple CRUD on well-defined resources; no client-driven joins.
• You want HTTP-level caching (CDN, browser, proxy) to just work.
• You have one primary client (a single web app) and no operational reason to add a layer.

A well-designed REST API with a strict OpenAPI spec, versioning, and consistent error shapes is a joy to consume. Most teams don't need more than that.

A GraphQL query like { posts { author { name } } } looks innocent. Without DataLoader, it runs one query for posts, then one query per post to fetch each author. On a page of 50 posts that's 51 queries. This is not a beginner mistake — I've seen it in mature codebases.

const authorLoader = new DataLoader<string, User>(async (ids) => {
  const users = await db.user.findMany({ where: { id: { in: [...ids] } } });
  const byId = new Map(users.map(u => [u.id, u]));
  return ids.map(id => byId.get(id)!);
});

// resolver
author: (post) => authorLoader.load(post.authorId)

Every GraphQL resolver that fetches related data needs a DataLoader. Every one. Enforce it in code review or you will ship 50-query pages.

Apollo Federation lets multiple services expose one unified GraphQL schema. It's the natural evolution when you have many teams and many domains. It also introduces a query planner as a critical path component, cross-service tracing complexity, and a class of bugs that only appear across service boundaries.

If you don't already have five+ services that each expose GraphQL, don't start with federation. Start with a schema-stitched or single-service GraphQL and adopt federation when a concrete team-boundary problem forces it.

If your API is going to be called by LLM agents (yours or third-party), REST wins decisively. OpenAPI schemas map cleanly to OpenAI function calling, Anthropic tools, and every agent framework. GraphQL requires the model to construct valid queries against a schema it barely understands — it fails.

This is not a minor point. In 2026, being LLM-consumable is a first-class API concern. If you're greenfield and expect AI clients, ship REST with an accurate OpenAPI spec and skip the GraphQL debate.

The setup I've shipped most often at healthy mid-size companies: GraphQL for the internal web/mobile app (client-driven, tight iteration), REST for the public API (stable contract, LLM-friendly, third-party). Same domain models underneath, two façades on top. Both stay lean because neither pretends to serve the other's use case.