Follow AiTechWorlds on LinkedIn for professional AI content!Follow Now →

AiTechWorlds

⚡

Web Dev

REST vs GraphQL: Complete Comparison

REST endpoints vs GraphQL queries, N+1 problem, DataLoader, when to choose each — with Node.js code examples.

#rest #graphql #api #backend #web-dev

Back to Notes Library

REST vs GraphQL: Complete Comparison

Core Philosophy

Aspect	REST	GraphQL
Invented	2000 (Roy Fielding)	2015 (Facebook/Meta)
Data shape	Server-defined per endpoint	Client-defined per query
Transport	HTTP (GET, POST, PUT, DELETE)	HTTP POST (usually)
Type system	None (OpenAPI is optional)	Built-in, required
Versioning	URL (`/v1/`, `/v2/`)	Schema evolution (no versions)
Caching	HTTP cache (GET requests)	Manual (POST isn't cached by default)

REST API

Design Principles

text

GET    /users          → list all users
POST   /users          → create user
GET    /users/42       → get user 42
PUT    /users/42       → replace user 42
PATCH  /users/42       → partial update user 42
DELETE /users/42       → delete user 42

GET    /users/42/posts → user's posts (nested resource)

REST Response Example

json

GET /users/42

{
  "id": 42,
  "name": "Alice",
  "email": "alice@example.com",
  "role": "admin",
  "created_at": "2024-01-15",
  "preferences": { ... },
  "billing": { ... }
}

Over-fetching: client receives role, preferences, billing even if it only needed name and email.

Under-fetching: to get a user's posts, you need a second request to /users/42/posts.

REST with Node/Express

javascript

const express = require('express');
const router = express.Router();

router.get('/users/:id', async (req, res) => {
  const user = await db.users.findById(req.params.id);
  if (!user) return res.status(404).json({ error: 'User not found' });
  res.json(user);
});

router.post('/users', async (req, res) => {
  const user = await db.users.create(req.body);
  res.status(201).json(user);
});

GraphQL

Core Concepts

Concept	Description
Schema	Typed definition of all data and operations
Query	Read data (like GET)
Mutation	Write data (like POST/PUT/DELETE)
Subscription	Real-time updates (WebSocket)
Resolver	Function that fetches data for a field

Schema Definition

graphql

type User {
  id: ID!
  name: String!
  email: String!
  posts: [Post!]!
}

type Post {
  id: ID!
  title: String!
  content: String
  author: User!
}

type Query {
  user(id: ID!): User
  users: [User!]!
  posts(authorId: ID): [Post!]!
}

type Mutation {
  createUser(name: String!, email: String!): User!
  updateUser(id: ID!, name: String): User!
  deleteUser(id: ID!): Boolean!
}

GraphQL Query (Client Requests Exactly What It Needs)

graphql

# Only fetch name and email — nothing else
query GetUser {
  user(id: "42") {
    name
    email
  }
}

# Fetch user AND their posts in one request (no under-fetching)
query UserWithPosts {
  user(id: "42") {
    name
    posts {
      title
      content
    }
  }
}

Mutation

graphql

mutation CreateUser {
  createUser(name: "Bob", email: "bob@example.com") {
    id
    name
  }
}

GraphQL with Apollo Server (Node.js)

javascript

const { ApolloServer, gql } = require('@apollo/server');

const typeDefs = gql`
  type User { id: ID!, name: String! }
  type Query { user(id: ID!): User }
`;

const resolvers = {
  Query: {
    user: async (_, { id }) => db.users.findById(id),
  },
};

const server = new ApolloServer({ typeDefs, resolvers });

Side-by-Side Comparison

Scenario	REST	GraphQL
Simple CRUD	Excellent	Overkill
Mobile apps (bandwidth-sensitive)	Over-fetches	Ideal
Multiple data sources in one request	Multiple round trips	Single query
Public API for third parties	Better documented	Harder to explore
Real-time (subscriptions)	SSE or WebSocket required	Built-in subscriptions
File uploads	Native multipart	Requires workaround
Browser caching	HTTP cache works natively	Needs Apollo Client cache
Type safety	Optional (OpenAPI)	Built-in
Learning curve	Low	Medium

When to Choose Each

Choose REST when:

Simple CRUD API with clear resource structure
Public API consumed by unknown third parties
Heavy browser caching needed
Team unfamiliar with GraphQL
Microservices communicating internally

Choose GraphQL when:

Mobile/bandwidth-constrained clients
Multiple clients with different data needs (web, mobile, TV)
Aggregating data from multiple services
Rapid product iteration (schema evolves, no versioning needed)
Real-time subscriptions needed alongside queries

N+1 Problem in GraphQL

graphql

query {
  posts {        # 1 query
    title
    author {     # N queries (one per post!)
      name
    }
  }
}

Fix: DataLoader (batching)

javascript

const DataLoader = require('dataloader');

const userLoader = new DataLoader(async (ids) => {
  const users = await db.users.findByIds(ids);
  return ids.map(id => users.find(u => u.id === id));
});

// Now all author fetches batch into one query
const resolvers = {
  Post: {
    author: (post) => userLoader.load(post.authorId)
  }
};

Common Mistakes

Using GraphQL for simple internal APIs — REST is simpler and easier to cache
Not implementing DataLoader — the N+1 problem will destroy performance on relational data
Exposing the entire schema without authorization — always check permissions in resolvers
REST: using only GET and POST for everything — verbs (PUT, PATCH, DELETE) carry semantic meaning
REST: deep nesting /users/42/posts/7/comments/3/likes — flatten with query params instead

Download REST vs GraphQL: Complete Comparison

Get this note + 100s more free on Telegram

Join Free →

📱

Get more notes like this daily on Telegram!

Free study notes, cheat sheets & AI tips

Join Free →

10K+ Members Growing Daily

Get Free AI Notes Daily

Join AiTechWorlds on Telegram and get daily AI tips, prompt engineering templates, coding resources, and exclusive content — 100% free!

📚 Free Study Notes🤖 AI Tips Daily⚡ Prompt Templates💻 Coding Resources

Join Free Channel

No spam. Leave anytime.

⚡

Web Dev

REST vs GraphQL: Complete Comparison

REST endpoints vs GraphQL queries, N+1 problem, DataLoader, when to choose each — with Node.js code examples.

#rest #graphql #api #backend #web-dev

Back to Notes Library

REST vs GraphQL: Complete Comparison

Core Philosophy

Aspect	REST	GraphQL
Invented	2000 (Roy Fielding)	2015 (Facebook/Meta)
Data shape	Server-defined per endpoint	Client-defined per query
Transport	HTTP (GET, POST, PUT, DELETE)	HTTP POST (usually)
Type system	None (OpenAPI is optional)	Built-in, required
Versioning	URL (`/v1/`, `/v2/`)	Schema evolution (no versions)
Caching	HTTP cache (GET requests)	Manual (POST isn't cached by default)

REST API

Design Principles

text

GET    /users          → list all users
POST   /users          → create user
GET    /users/42       → get user 42
PUT    /users/42       → replace user 42
PATCH  /users/42       → partial update user 42
DELETE /users/42       → delete user 42

GET    /users/42/posts → user's posts (nested resource)

REST Response Example

json

GET /users/42

{
  "id": 42,
  "name": "Alice",
  "email": "alice@example.com",
  "role": "admin",
  "created_at": "2024-01-15",
  "preferences": { ... },
  "billing": { ... }
}

Over-fetching: client receives role, preferences, billing even if it only needed name and email.

Under-fetching: to get a user's posts, you need a second request to /users/42/posts.

REST with Node/Express

javascript

const express = require('express');
const router = express.Router();

router.get('/users/:id', async (req, res) => {
  const user = await db.users.findById(req.params.id);
  if (!user) return res.status(404).json({ error: 'User not found' });
  res.json(user);
});

router.post('/users', async (req, res) => {
  const user = await db.users.create(req.body);
  res.status(201).json(user);
});

GraphQL

Core Concepts

Concept	Description
Schema	Typed definition of all data and operations
Query	Read data (like GET)
Mutation	Write data (like POST/PUT/DELETE)
Subscription	Real-time updates (WebSocket)
Resolver	Function that fetches data for a field

Schema Definition

graphql

type User {
  id: ID!
  name: String!
  email: String!
  posts: [Post!]!
}

type Post {
  id: ID!
  title: String!
  content: String
  author: User!
}

type Query {
  user(id: ID!): User
  users: [User!]!
  posts(authorId: ID): [Post!]!
}

type Mutation {
  createUser(name: String!, email: String!): User!
  updateUser(id: ID!, name: String): User!
  deleteUser(id: ID!): Boolean!
}

GraphQL Query (Client Requests Exactly What It Needs)

graphql

# Only fetch name and email — nothing else
query GetUser {
  user(id: "42") {
    name
    email
  }
}

# Fetch user AND their posts in one request (no under-fetching)
query UserWithPosts {
  user(id: "42") {
    name
    posts {
      title
      content
    }
  }
}

Mutation

graphql

mutation CreateUser {
  createUser(name: "Bob", email: "bob@example.com") {
    id
    name
  }
}

GraphQL with Apollo Server (Node.js)

javascript

const { ApolloServer, gql } = require('@apollo/server');

const typeDefs = gql`
  type User { id: ID!, name: String! }
  type Query { user(id: ID!): User }
`;

const resolvers = {
  Query: {
    user: async (_, { id }) => db.users.findById(id),
  },
};

const server = new ApolloServer({ typeDefs, resolvers });

Side-by-Side Comparison

Scenario	REST	GraphQL
Simple CRUD	Excellent	Overkill
Mobile apps (bandwidth-sensitive)	Over-fetches	Ideal
Multiple data sources in one request	Multiple round trips	Single query
Public API for third parties	Better documented	Harder to explore
Real-time (subscriptions)	SSE or WebSocket required	Built-in subscriptions
File uploads	Native multipart	Requires workaround
Browser caching	HTTP cache works natively	Needs Apollo Client cache
Type safety	Optional (OpenAPI)	Built-in
Learning curve	Low	Medium

When to Choose Each

Choose REST when:

Simple CRUD API with clear resource structure
Public API consumed by unknown third parties
Heavy browser caching needed
Team unfamiliar with GraphQL
Microservices communicating internally

Choose GraphQL when:

Mobile/bandwidth-constrained clients
Multiple clients with different data needs (web, mobile, TV)
Aggregating data from multiple services
Rapid product iteration (schema evolves, no versioning needed)
Real-time subscriptions needed alongside queries

N+1 Problem in GraphQL

graphql

query {
  posts {        # 1 query
    title
    author {     # N queries (one per post!)
      name
    }
  }
}

Fix: DataLoader (batching)

javascript

const DataLoader = require('dataloader');

const userLoader = new DataLoader(async (ids) => {
  const users = await db.users.findByIds(ids);
  return ids.map(id => users.find(u => u.id === id));
});

// Now all author fetches batch into one query
const resolvers = {
  Post: {
    author: (post) => userLoader.load(post.authorId)
  }
};

Common Mistakes

Using GraphQL for simple internal APIs — REST is simpler and easier to cache
Not implementing DataLoader — the N+1 problem will destroy performance on relational data
Exposing the entire schema without authorization — always check permissions in resolvers
REST: using only GET and POST for everything — verbs (PUT, PATCH, DELETE) carry semantic meaning
REST: deep nesting /users/42/posts/7/comments/3/likes — flatten with query params instead

Download REST vs GraphQL: Complete Comparison

Get this note + 100s more free on Telegram

Join Free →

📱

Get more notes like this daily on Telegram!

Free study notes, cheat sheets & AI tips

Join Free →

10K+ Members Growing Daily

Get Free AI Notes Daily

Join AiTechWorlds on Telegram and get daily AI tips, prompt engineering templates, coding resources, and exclusive content — 100% free!

📚 Free Study Notes🤖 AI Tips Daily⚡ Prompt Templates💻 Coding Resources

Join Free Channel

No spam. Leave anytime.