REST API vs GraphQL Data Fetching

REST and GraphQL answer the same question — how does a client retrieve structured data from a server — with fundamentally different tradeoffs. REST exposes fixed resource endpoints where each URL returns a predefined shape. GraphQL lets the client declare exactly the nested fields it needs in a single query document, returning a tailored response at the cost of server-side parsing and resolver coordination.

Mental Model & Real-World Concurrency

In the visualizer, the REST lane demonstrates a deliberately naïve serial waterfall to clearly highlight dependency hops:

1. GET /users/42 (fetches user profile: name, avatar, plus 22 unused fields)
2. GET /users/42/posts (fetches 3 posts: title, body)
3. GET /posts/101/comments, GET /posts/102/comments, GET /posts/103/comments (fetches comments with author names)

Request Count vs. Critical Path

In production REST systems, request count does not equal critical path latency:

• Serial Waterfall (Naïve): 5 requests across 5 sequential roundtrip turns.
• Concurrent Parallelization (HTTP/2 / Promise.all): Once post IDs are known, the 3 comment calls dispatch concurrently over multiplexed HTTP/2 connections, reducing the critical path from 5 turns to 3 critical roundtrips (/users → /posts → parallel /comments).
• Bulk Endpoints: A single bulk query (GET /comments?post_ids=101,102,103) reduces the critical path to 3 requests in 3 turns.
• Backend-For-Frontend (BFF): A dedicated screen endpoint (GET /api/v1/users/42/feed) can return the exact composite payload in 1 roundtrip.

GraphQL achieves this single-roundtrip aggregation declaratively without requiring custom backend BFF endpoint authoring for every UI screen variation.

query GetFeed {
  user(id: 42) {
    name
    avatar
    posts {
      title
      body
      comments {
        text
        author {
          name
        }
      }
    }
  }
}

Components and Architectural Roles

REST Client App

The client application managing API requests. In basic REST architectures, the client must orchestrate cascading requests and stitch separate JSON payloads in memory.

REST Resource Endpoints (/users/:id, /posts, /comments)

Stateless HTTP handlers that map URLs to domain entities. Endpoints return fixed schema representations, which enables transparent CDN caching but can cause over-fetching (returning unneeded fields) or under-fetching (requiring subsequent calls).

REST Database Tier

Backing relational or document stores. Processes discrete queries per endpoint invocation.

GraphQL Client App

Constructs structured query documents declaring required fields and variables, dispatching them over HTTP POST to /graphql.

GraphQL Gateway & Execution Engine

Parses the query document into an Abstract Syntax Tree (AST), validates field selections against the schema type definition, and invokes field resolvers.

Resolvers & DataLoaders

Field-level resolution functions. Sibling resolvers execute concurrently in memory. To prevent backend N+1 query loops, DataLoaders batch lookups within the same tick into a single SQL IN query or bulk RPC.

Architectural Decision Matrix

Constraint / Requirement	REST API	GraphQL
Edge CDN Caching	Native HTTP GET / Cache-Control / ETags	Complex (POST bypasses standard CDNs; requires APQ or client caches)
Payload Precision	Fixed shapes (over-fetching unless custom query params added)	Exact field matching (client declared)
Screen Aggregation	Client orchestration, Bulk APIs, or custom BFF endpoints	Declarative single-operation nesting
Server Complexity	Low (pre-routed controller actions)	Moderate-High (AST parse, type validation, resolver security)
Network Efficiency	HTTP/2 multiplexing mitigates connection overhead	1 WAN roundtrip minimizes mobile cellular latency
Best Used For	Simple CRUD, public APIs, static media, high-cache throughput	Multi-platform apps, rapid frontend iteration, nested aggregator BFFs