🔥 0
0
Lesson 1 of 6 15 min +150 XP

REST Limitations & GraphQL Benefits

In 2012, Facebook faced a crisis. Their mobile app was slow, buggy, and draining batteries. The culprit? Their REST API.

The app needed multiple requests to render a single news feed item - one for the post, one for the user, one for comments, one for likes. Each request returned more data than needed. On slow 3G connections, the experience was terrible.

So Facebook invented GraphQL.

REST PROBLEMS

  • Over-fetching data
  • Under-fetching (N+1 requests)
  • Multiple round trips
  • Rigid endpoints
  • Versioning headaches

GRAPHQL SOLUTIONS

  • Request exactly what you need
  • Single request, multiple resources
  • One round trip
  • Flexible queries
  • Schema evolution

The Over-Fetching Problem

Imagine building a user profile card. You only need name and avatar. With REST:

// REST: GET /api/users/123
{
  "id": 123,
  "name": "Sarah Chen",
  "email": "sarah@example.com",
  "avatar": "https://...",
  "phone": "+1-555-0123",
  "address": {
    "street": "123 Main St",
    "city": "San Francisco",
    "zip": "94102"
  },
  "preferences": { ... },
  "createdAt": "2020-01-15",
  "lastLogin": "2024-01-20"
  // ... 20 more fields you don't need
}

You wanted 2 fields. You got 30. That's wasted bandwidth and slower parsing.

With GraphQL, you ask for exactly what you need:

# GraphQL Query
query {
  user(id: 123) {
    name
    avatar
  }
}

# Response - exactly what you asked for
{
  "data": {
    "user": {
      "name": "Sarah Chen",
      "avatar": "https://..."
    }
  }
}

The Under-Fetching Problem

Now imagine a blog post page. You need the post, author info, and comments. With REST:

// Request 1: Get the post
GET /api/posts/456
// Response includes author_id: 123

// Request 2: Get the author
GET /api/users/123

// Request 3: Get comments
GET /api/posts/456/comments
// Response includes commenter IDs

// Requests 4-13: Get each commenter's info
GET /api/users/201
GET /api/users/202
// ... and so on
13 HTTP requests

Each request has latency overhead. On mobile networks, this adds up fast.

With GraphQL, one request gets everything:

query {
  post(id: 456) {
    title
    content
    author {
      name
      avatar
    }
    comments {
      text
      author {
        name
        avatar
      }
    }
  }
}

How GraphQL Works

GraphQL is a query language for your API. Instead of multiple endpoints, you have one endpoint that accepts queries.

📜
Schema

Defines your data types and operations

🔍
Queries

Read data from the server

✏️
Mutations

Create, update, or delete data

Resolvers

Functions that fetch the data

Real-World Adoption

Company Why They Use GraphQL
GitHub API v4 is GraphQL - 90% less data transfer for mobile
Shopify Storefront API uses GraphQL for flexible e-commerce queries
Netflix Federation across 100+ microservices
Twitter Powers the Twitter API v2 for third-party apps
GitHub's Results

"Our public API traffic decreased by 90% because clients only request what they need."

— GitHub Engineering Blog

GraphQL vs REST: Quick Comparison

Aspect REST GraphQL
Endpoints Multiple (/users, /posts) Single (/graphql)
Data fetching Server decides response shape Client decides response shape
Versioning /v1, /v2 endpoints Schema evolution
Caching HTTP caching built-in Requires custom solutions

Key Takeaways

  • Over-fetching - REST returns fixed data structures, GraphQL returns exactly what you request
  • Under-fetching - REST often requires multiple requests, GraphQL can fetch related data in one query
  • Single endpoint - GraphQL uses one endpoint with a flexible query language
  • Schema-first - GraphQL has a strongly-typed schema that serves as documentation

Next up: Schema & Types - Learn how to define your data model in GraphQL.

🧠 Quick Quiz

Test your understanding of this lesson.

1

What is the main problem with REST APIs that GraphQL solves?

2

How does GraphQL handle versioning compared to REST?

3

Which company created GraphQL?