Next.js Data Fetching Patterns

⏱️ ~5-minute bite · solve the sandbox to master

0%lesson

🧒

5-Year-Old Metaphor

— The physical, real-world picture. No jargon.

🍽️ How you stock the kitchen determines how fresh the meal is.

🥫

force-cache

Pantry staples — buy once, use forever

Cached at build time, served from CDN instantly. Perfect for public data that rarely changes: blog posts, marketing pages, product catalogs. Zero runtime cost.

🥛

revalidate: 60

Milk with an expiry date

Fresh for 60s, then auto-restocked in the background. Users always get something instantly — at worst it's 60s old. ISR: static performance with eventual freshness.

🚚

no-store

Fresh delivery every time you cook

Every request hits the API fresh. No caching at any layer. Use for user-specific, personalized, or highly volatile data: carts, dashboards, live feeds.

🏷️

tags + revalidateTag

Labeled shelves — restock only what changed

Cache with tags; invalidate only the tagged entries. CMS publishes an article → webhook calls revalidateTag('posts') → only posts cache is purged. Surgical precision.

⚡

Promise.all

Order all dishes simultaneously, not one at a time

3 sequential fetches = 300ms. Promise.all = 100ms. Always parallelize independent data fetches. Next.js deduplicates identical fetch() calls within a render automatically.

Build output signals

○ StaticPre-rendered at build. CDN cached.

◐ ISRStatic + background revalidation.

λ DynamicServer-rendered every request.

🎛️

Interactive Sandbox

— Move something, see it react instantly.

Fetch pattern

○ Static

Cached forever — only refreshed on next build/deploy.

1	// Server Component — cached forever (until next deploy)
2	async function Page() {
3	const res = await fetch("https://api.example.com/posts", {
4	cache: "force-cache", // default in Next.js 13/14 App Router
5	});
6	const posts = await res.json();
7
8	return <PostList posts={posts} />;
9	}
10
11	// Equivalent shorthand (force-cache is the default):
12	const res = await fetch("https://api.example.com/posts");
13
14	// Build output:
15	// ○ /posts (Static) — generated once, served from CDN forever

Staleness clock

∞ freshNever expires. Data frozen at build time.

Gotcha: If your API returns different data per user (auth tokens, personalized content), force-cache will cache one user's data and serve it to everyone. Always use no-store for user-specific endpoints.

Insight: force-cache = pantry staples. You bought them once, they last years. Perfect for public, rarely-changing data: product catalog, blog posts, marketing content. Zero runtime cost — CDN serves pre-built HTML.

Explored:🥫🥛🚚🏷️⚡

🎯

Challenge

Which fetch option makes a route dynamically rendered on every request?

Try it

🎯

Why Should I Care?

— The exact interview question + the bug it kills.

Interview questions

Q: What is ISR (Incremental Static Regeneration)?

Pages are statically generated at build time but re-generated in the background after the revalidate window expires. Users always get cached HTML — zero server render cost. The first visitor after the window expires still gets the stale page; the next visitor after thatgets the freshly regenerated one. This "stale-while-revalidate" pattern gives static performance with eventual freshness.

1	// next: { revalidate: 60 } on the fetch, OR:
2	export const revalidate = 60; // route segment config
3
4	// Build output:
5	// ◐ /blog (ISR) revalidate: 60
6	//
7	// Timeline:
8	// t=0s : build → generate HTML
9	// t=30s : user A → cached HTML (instant)
10	// t=61s : user B → STILL cached (stale, but instant)
11	// + background regeneration fires
12	// t=62s : regeneration done → cache updated
13	// t=63s : user C → fresh HTML (instant)

Q: When should you use on-demand revalidation with tags?

When you know exactly when data changes — e.g., a CMS webhook fires when an article is published. Instead of polling every N seconds, you call revalidateTag('posts') from a Route Handler the moment new content is available. This gives you always-fresh data without constant unnecessary regeneration — the cache stays warm until you explicitly bust it.

1	// 1. Tag the fetch in your Server Component:
2	const res = await fetch("https://cms.example.com/posts", {
3	next: { tags: ["posts", "homepage"] },
4	});
5
6	// 2. Revalidation endpoint (Route Handler):
7	// app/api/revalidate/route.ts
8	import { revalidateTag } from "next/cache";
9	export async function POST(req: Request) {
10	const { tag } = await req.json();
11	revalidateTag(tag); // only purges "posts" cache entries
12	return Response.json({ ok: true });
13	}
14
15	// 3. CMS calls your webhook on publish:
16	// POST /api/revalidate { "tag": "posts" }
17	// → only /blog and pages tagged "posts" regenerate
18	// → /products (tagged "products") stays cached

Q: Why does parallel fetch matter?

Sequential awaits add latency linearly: 3 fetches × 100ms = 300ms minimum before the page can render. Promise.all fires all fetches concurrently — total time equals the slowest single fetch (~100ms). On a page with 5 independent data sources averaging 80ms each, the difference is 400ms vs 80ms. Always parallelize when there are no data dependencies between fetches.

1	// ✗ Sequential: 80 + 100 + 90 + 110 + 70 = 450ms
2	const user = await fetchUser();
3	const orders = await fetchOrders();
4	const prefs = await fetchPreferences();
5	const notifs = await fetchNotifications();
6	const friends = await fetchFriends();
7
8	// ✓ Parallel: max(80, 100, 90, 110, 70) = 110ms
9	const [user, orders, prefs, notifs, friends] = await Promise.all([
10	fetchUser(),
11	fetchOrders(),
12	fetchPreferences(),
13	fetchNotifications(),
14	fetchFriends(),
15	]);
16
17	// Next.js deduplication bonus: identical fetch() URLs
18	// called by two different Server Components are
19	// automatically coalesced into one HTTP request.

🔬

The Deep Dive

— Spec refs, engine internals, the minutiae.

Fetch deduplication — automatic memoization

Next.js extends the native fetch API with automatic request deduplication. If two Server Components in the same render tree call fetch('/api/user') with the same URL and options, only one HTTP request is sent. Both components receive the same response. This means you can write data-fetching logic in each component without worrying about duplicate API calls — colocate data needs with the component that uses them.

1	// Layout.tsx — fetches user
2	async function Layout({ children }: { children: React.ReactNode }) {
3	const user = await fetch("/api/user").then(r => r.json());
4	return <><Header user={user} />{children}</>;
5	}
6
7	// Page.tsx — also fetches user (same URL)
8	async function Page() {
9	const user = await fetch("/api/user").then(r => r.json());
10	return <Profile user={user} />;
11	}
12
13	// Result: only ONE HTTP GET /api/user is made.
14	// Next.js deduplicates per render pass using a Request cache.
15	// The cache is cleared between requests — not persistent.

React.cache — deduplication for non-fetch data sources

fetch()deduplication is automatic, but what about database queries, filesystem reads, or any async function that isn't fetch? React.cache wraps any function and memoizes its result per render pass — same arguments, same result, one execution.

1	import { cache } from "react";
2	import { db } from "@/lib/db";
3
4	// Wrapped in cache() — deduplicates across the render tree
5	export const getUser = cache(async (id: string) => {
6	return db.user.findUnique({ where: { id } });
7	});
8
9	// Now safe to call from multiple Server Components:
10	// Layout: await getUser(params.id) → DB query
11	// Page: await getUser(params.id) → same result, no second query
12	// Card: await getUser(params.id) → same result, no second query
13	// All three get the same object. One DB round-trip total.
14
15	// Unlike fetch(), React.cache() does NOT persist across requests.
16	// It is scoped to a single server render.

Route segment config — route-level overrides

Instead of setting cache options on each individual fetch(), you can configure the entire route segment with a single export. These override per-fetch options.

1	// app/blog/page.tsx
2
3	// Revalidate ALL fetches in this route every 60s:
4	export const revalidate = 60;
5
6	// Force dynamic rendering for the entire route:
7	export const dynamic = "force-dynamic";
8
9	// Force static generation (error if dynamic functions used):
10	export const dynamic = "force-static";
11
12	// Control behaviour for unknown path params:
13	export const dynamicParams = true; // (default) generate on-demand
14	export const dynamicParams = false; // 404 for unknown params
15
16	// Specify the runtime:
17	export const runtime = "edge"; // Edge Runtime (V8, global)
18	export const runtime = "nodejs"; // Node.js (default)
19
20	// Preferred region for edge deployment:
21	export const preferredRegion = "iad1"; // Washington DC

revalidateTag vs revalidatePath

revalidateTag(tag)

Invalidates all cache entries that were fetched with this tag — regardless of which URL or route they appear on.

Use when: data is shared across multiple routes. A "products" tag might appear on /shop, /product/[id], and /homepage simultaneously.

revalidatePath(path)

Invalidates the cached response for a specific route path and all its fetches.

Use when: you know the exact page to update — e.g., after a user updates their profile, call revalidatePath('/profile') to purge just that route.

1	import { revalidateTag, revalidatePath } from "next/cache";
2
3	// After CMS publishes → purge all "posts" across all routes:
4	revalidateTag("posts");
5
6	// After user profile update → purge only their profile page:
7	revalidatePath(`/users/${userId}`);
8
9	// revalidatePath also accepts a "page" or "layout" type:
10	revalidatePath("/blog", "layout"); // purge /blog and all children
11	revalidatePath("/blog/[slug]", "page"); // purge just page, not layout

🎤

Interview Questions

— Real questions from real interviews — with answers.

force-cache — responses are cached indefinitely and served statically until revalidation.

The stale cached page — and their request triggers background regeneration for the next visitor.

revalidateTag when data appears on multiple routes; revalidatePath when you know the exact URL.

searchParams is request-time data — unknown at build time, so the page cannot be pre-rendered.

fetch() URLs are deduplicated per render pass automatically. Prisma requires React.cache() for the same effect.

🎮

Memory Game

— Quick quiz — lock the concept in long-term memory.

1/4

What is the 'data cache' in Next.js App Router and how is it different from the 'full route cache'?