Fetch API & Caching

🔍 What Is It?

Next.js extends the native fetch API with additional options in the next namespace:

fetch(url, {
  cache: 'force-cache' | 'no-store',
  next: {
    revalidate: number,  // ISR: seconds until revalidation
    tags: string[],      // Tags for on-demand revalidation
  }
})

Caching behaviour by version:

• →Next.js 14: fetch is cached by default (force-cache). Use cache: 'no-store' to opt out.
• →Next.js 15: fetch is NOT cached by default. Use cache: 'force-cache' or next: { revalidate } to opt in.

Deduplication: Multiple fetch calls to the same URL within the same render pass are automatically deduplicated — the network request is made only once.

🎯 Why Do We Need It?

Without Next.js's fetch extensions, you would need to:

• →Manually implement caching with Redis or in-memory stores
• →Manually deduplicate requests (prevent the same API being called 3 times in one render)
• →Manually implement ISR-style revalidation logic
• →Manually tag cache entries for on-demand invalidation

Next.js bakes all of this into the fetch API you already know, making caching a declarative concern rather than an imperative one.

🏗️ What Happens in Real Projects?

Fetch patterns in a real CMS-driven site:

// Cached indefinitely (static)
const config = await fetch('/api/config', { cache: 'force-cache' });

// ISR: revalidate every hour
const products = await fetch('/api/products', { next: { revalidate: 3600 } });

// Always fresh (SSR)
const cart = await fetch('/api/cart', { cache: 'no-store' });

// Tagged for on-demand revalidation
const post = await fetch('/api/posts/slug', {
  next: { revalidate: 3600, tags: ['posts', 'post-slug'] }
});

⚙️ How It Works

Next.js fetch caching layers:

1. Request deduplication — same URL + options in one render = one network request
2. Data cache — persists across requests (ISR/SSG behaviour)
3. Full route cache — caches the rendered HTML/RSC payload
4. Router cache — client-side cache for navigation

These four caches work together. Understanding which cache you're controlling with each option is the key to avoiding stale data bugs.

💻 Example

Fetch Patterns for Every Scenario — The four fetch patterns you will use in every Next.js project.

// lib/api.ts — centralise your fetch patterns

// 1. STATIC — cached forever, only updates on rebuild
export async function getConfig() {
  const res = await fetch('https://api.example.com/config', {
    cache: 'force-cache',
  });
  return res.json();
}

// 2. ISR — cached, revalidated every hour
export async function getProducts() {
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 3600, tags: ['products'] },
  });
  return res.json();
}

// 3. DYNAMIC — never cached, always fresh
export async function getCartItems(sessionId: string) {
  const res = await fetch(
    `https://api.example.com/cart/${sessionId}`,
    { cache: 'no-store' }
  );
  return res.json();
}

// 4. ON-DEMAND — ISR + tagged for webhook revalidation
export async function getPost(slug: string) {
  const res = await fetch(
    `https://api.example.com/posts/${slug}`,
    { next: { revalidate: 86400, tags: ['posts', `post-${slug}`] } }
  );
  return res.json();
}

🤔 Common Confusions

🚨 Common Production Issues

✅ Best Practices

🏛️ Architect's Note

💬 Frequently Asked Questions

🎯 Key Takeaways

🔗 Related Topics

🎯 Practice this topic in interviews

↗ Where this topic fits