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
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.
Defines your data types and operations
Read data from the server
Create, update, or delete data
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 |
| Powers the Twitter API v2 for third-party apps |
"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.