GraphQL

Under-fetching: the chatty waterfall

The seven requests above are under-fetching in action: one endpoint does not give you enough, so you chain more, and on a high-RTT (round-trip time) mobile network each link in the chain is paid in full before the UI can render.

// You need: user name + their posts + follower count
// REST gives you:

GET /users/123
→ { id, name, email, bio, phone, address, ... }
// ✅ Got name, but no posts or followers

GET /users/123/posts
→ [{ id, title, body, tags, ... }, ...]
// ✅ Got posts, but still no followers

GET /users/123/followers/count
→ { count: 1420 }
// ✅ Finally got everything!

// 3 round trips. 3× latency on slow networks.

The cost: on a 100ms RTT mobile connection, three sequential requests mean 300ms minimum before the UI can render anything.

Over-fetching: wasted bytes

The other half of the pain is that each of those fixed REST responses returns every field of the resource. A comment card only wanted the author's name, but got the entire user object.

// You only need: user's name for a comment card
GET /users/123
→ {
    id: 123,
    name: "Alice",           // ✅ needed
    email: "a@b.com",        // ❌ wasted
    phone: "+1-555-0123",    // ❌ wasted
    address: { ... },        // ❌ wasted (500 bytes)
    preferences: { ... },    // ❌ wasted (1KB)
    paymentMethods: [ ... ], // ❌ wasted (2KB)
    loginHistory: [ ... ],   // ❌ wasted (5KB)
  }
// You needed 20 bytes, got 8KB. 400× waste.
// ×1000 users on news feed = 8MB wasted data.

The cost: wasted bandwidth, slower parsing, and higher memory on the device, especially painful on metered 3G/4G connections.

How GraphQL solves both problems at once

Complete example: a user profile page

Putting both halves together on a second screen, here is the full REST versus GraphQL comparison for a profile page.

// Request 1
GET /users/123     → 8KB (all fields)
// Request 2
GET /users/123/posts?limit=5  → 3KB
// Request 3
GET /users/123/followers/count → 50B
// Request 4
GET /users/123/following/count → 50B

// Total: 4 RTTs, ~12KB transferred

query UserProfile {
  user(id: "123") {
    name
    avatarUrl
    bio
    posts(first: 5) {
      title
      createdAt
    }
    followerCount
    followingCount
  }
}
// Total: 1 RTT, ~800B transferred

93% less data transferred and 75% fewer round trips. On mobile, that is the difference between instant and a spinner.

Signals to look for

📰 Real pattern: GraphQL as the news feed aggregation layer

Not always, but for news feed type applications, GraphQL is often the single aggregation endpoint that stitches data from multiple backend services:

# News feed query: one request aggregates from 4 services
query NewsFeed($userId: ID!, $limit: Int!) {
  feed(userId: $userId, first: $limit) {
    posts {
      id
      text                          # → Post Service
      author {
        name, avatarUrl             # → User Service
      }
      likeCount                     # → Like Service
      topComments(first: 3) {
        text                        # → Comment Service
        author { name }             # → User Service (batched)
      }
    }
    pageInfo { hasNextPage, endCursor }
  }
}

Why this works: the gateway orchestrates the fan-out to backend services server-side, over a fast internal network, instead of the mobile client making four or more requests over slow cellular. DataLoader batches the user lookups across comments, and the client gets one shaped response matching its UI.

The N+1 problem and DataLoader

That server-side fan-out is also the biggest performance pitfall in GraphQL. Nested fields trigger one database query per child row unless something batches them: without mitigation, a query for 100 users with their posts makes 1 query for users plus 100 queries for posts, 101 database queries in total.

SELECT * FROM users LIMIT 100;  -- 1 query
SELECT * FROM posts WHERE user_id=1;  -- query 2
SELECT * FROM posts WHERE user_id=2;  -- query 3
... (98 more)
-- Total: 101 queries!

SELECT * FROM users LIMIT 100;  -- 1 query
SELECT * FROM posts WHERE user_id IN (1, 2, 3, ..., 100);  -- 1 query
-- Total: 2 queries!

The DataLoader pattern

• Collect every ID requested during one event-loop tick instead of querying immediately.
• Batch those IDs into a single database query using WHERE id IN (...).
• Cache results for the lifetime of the request, so a repeated author loads once.
• Keep that cache per request, not global, so stale data never leaks between users.

A large social app invented DataLoader for this exact problem.

Federation for microservices

Federation lets multiple subgraphs (one per team or service) compose into one graph while each team owns its slice independently.

Cursor pagination and query batching

Whether the graph is federated or not, huge lists need stable cursors and repeated small queries need batching to stay performant and predictable.

query {
  user(id: "123") {
    posts(first: 10, after: "cursor_abc") {
      edges {
        cursor
        node { id, title }
      }
      pageInfo { hasNextPage, endCursor }
    }
  }
}

POST /graphql
[
  { "query": "{ user(id: 1) { name } }" },
  { "query": "{ user(id: 2) { name } }" },
  { "query": "{ product(id: 99) { price } }" }
]
// Server processes all 3 in one HTTP request.

How to explain this in a design review

GraphQL is impressive only when you also explain how you control query cost, cache results, and keep field-level security correct. Lead with the client divergence that justifies it, then walk the cost guards and caching escapes above, and authorize at the resolver or field boundary rather than only at the top-level query. Keep these constraints in view while you do:

• One client request can still fan out to many slow downstream services.
• POST-to-one-URL makes CDN caching harder unless persisted GET queries are used.
• Mobile clients benefit from smaller payloads but can be hurt by very large nested responses.
• Partial errors mean clients must handle data and errors together in every response.
• Debug slow queries with resolver timings and query plans, not only HTTP latency.

Exercises

1. Cost points. Merchants get 1000 cost points per second. Assign costs so a simple product query is ≤5 and a nested catalog browse is ≤200. What happens at the limit: an error or partial data?
2. CDN-cached feed. You need CDN caching for a mobile home feed. Design persisted queries as GET. What do you key on, and how do you invalidate after a follow?
3. Field-level authorization. A field resolver returns email. Who may see it: self, admin, or friend? Write down where the authz check lives, and a counterexample if you only gate the root query.

Topic-specific references

• GraphQL Specification : schema, execution, and error model.
• facebook/dataloader : per-tick batching to collapse N+1 lookups.
• Apollo: Automatic Persisted Queries : GET-friendly hashes for CDN caching and allow-lists.