0Pricing
Next.js 15 Fullstack (App Router + Server Actions) · Lekcja

Cztery pamięci podręczne: żądania, danych, pełnych tras i routera

Prześledź współdziałanie każdej warstwy pamięci podręcznej i miejsca powstawania nieaktualnych danych w aplikacjach App Router.

Cztery pamięci podręczne: żądania, danych, pełnych tras i routera to bezpłatna lekcja Next.js 15 Fullstack (App Router + Server Actions) na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Next.js 15 Fullstack (App Router + Server Actions), a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Next.js 15 Fullstack (App Router + Server Actions) zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

Four Caches, One Mental Model

Next.js 15 App Router has four distinct caching layers. Stale data almost always comes from one of them, so naming them precisely is the first step to debugging.

  • Request Memoization — dedupes identical fetch calls within a single render pass.
  • Data Cache — persists fetch results across requests and deployments (server-side, durable).
  • Full Route Cache — stores the rendered HTML + RSC payload of statically-rendered routes at build time.
  • Router Cache — an in-memory client-side cache of RSC payloads for visited routes.

They flow roughly client → server: Router Cache lives in the browser; the other three live on the server.

Layer 1: Request Memoization

Request Memoization is React's built-in deduplication of fetch during a single server render. If three components request the same URL with the same options, the network call fires once; the rest reuse the in-flight promise.

  • Scope: a single render pass (one request). It is not shared across requests.
  • Key: the fetch URL + options.
  • Benefit: you can call getUser() in the layout and the page without prop-drilling or refetching.

Only fetch is memoized automatically. For non-fetch work (DB clients, ORMs), wrap it in React's cache().

import { cache } from 'react';
import { db } from '@/lib/db';

// Without fetch, memoize manually so layout + page share one query
export const getUser = cache(async (id: string) => {
  return db.user.findUnique({ where: { id } });
});

// Both calls in the same render hit the DB only once
async function Layout({ id }: { id: string }) {
  const user = await getUser(id);
  return user.name;
}

Memoization Is Per-Render, Not Durable

A common misconception: people think Request Memoization persists data. It does not. The moment the render finishes, the memo cache is discarded.

  • It exists only to avoid duplicate work within one render tree.
  • The next incoming request starts with an empty memo cache.
  • Durability across requests is the job of the Data Cache, not memoization.

So if you see fresh data on request A but the same render reuses it, that's memoization. If data survives a server restart, that's the Data Cache.

Layer 2: The Data Cache

The Data Cache persists fetch results on the server across requests, users, and even deployments (until revalidated). In Next.js 15 the default changed: fetch is now uncached (no-store) unless you opt in.

  • cache: 'force-cache' → store and reuse the result.
  • next: { revalidate: N } → store, serve stale up to N seconds, then refresh.
  • cache: 'no-store' → never store; always hit the source.

This is the layer most responsible for “why is my data stale?” when you forgot it's cached.

// Next.js 15: opt INTO the Data Cache explicitly
async function getProducts() {
  // Revalidate at most every 60s (ISR-style)
  const res = await fetch('https://api.shop.com/products', {
    next: { revalidate: 60 },
  });
  return res.json();
}

async function getCart() {
  // Per-user, never cache
  const res = await fetch('https://api.shop.com/cart', {
    cache: 'no-store',
  });
  return res.json();
}

Tagging and Targeted Revalidation

The Data Cache supports cache tags so you can invalidate exactly the entries tied to a piece of data — ideal after a Server Action mutates the database.

  • Attach tags at fetch time: next: { tags: ['products'] }.
  • Invalidate by tag with revalidateTag('products').
  • Invalidate by path with revalidatePath('/products').

Both functions run on the server (Server Action or Route Handler) and purge the Data Cache and the affected Full Route Cache entries.

'use server';
import { revalidateTag } from 'next/cache';
import { db } from '@/lib/db';

export async function createProduct(formData: FormData) {
  await db.product.create({
    data: { name: String(formData.get('name')) },
  });
  // Purge every fetch tagged 'products' → next read is fresh
  revalidateTag('products');
}

Layer 3: The Full Route Cache

The Full Route Cache stores the fully rendered output of a route — both the HTML and the React Server Component (RSC) payload — on the server at build time. It only applies to statically rendered routes.

  • A route is static unless it uses dynamic APIs (cookies(), headers(), searchParams) or an uncached fetch.
  • Static routes are served instantly from this cache with no re-render.
  • Dynamic routes skip the Full Route Cache and render on every request.

Think of it as the rendered-output sibling of the Data Cache, which holds raw fetch data.

Static vs Dynamic: What Triggers Each

Whether a route lands in the Full Route Cache depends on what it touches during render. Reading a dynamic API opts the whole route into dynamic rendering.

  • Using cookies(), headers(), draftMode(), or searchParams → dynamic.
  • A fetch with cache: 'no-store' → dynamic.
  • Exporting export const dynamic = 'force-dynamic' → dynamic, always.

You can force the other direction with export const dynamic = 'force-static' to keep a route cached.

// This page becomes DYNAMIC because it reads cookies()
import { cookies } from 'next/headers';

export default async function Dashboard() {
  const store = await cookies(); // Next.js 15: cookies() is async
  const theme = store.get('theme')?.value ?? 'light';

  // Full Route Cache is skipped; rendered fresh per request
  return <main data-theme={theme}>Welcome back</main>;
}

Layer 4: The Router Cache (Client)

The Router Cache is an in-memory, client-side store of RSC payloads for routes the user has visited or prefetched. It makes back/forward navigation instant and avoids refetching on soft navigations.

  • It lives in the browser and is cleared on a full page reload.
  • It's why clicking a <Link> back to a page shows the previous payload, even if the server data changed.
  • In Next.js 15, the default staleTime for page segments is 0, so dynamic pages are refetched on navigation by default.

This is the layer that confuses people most: the server already revalidated, but the client still shows old UI from its Router Cache.

Clearing the Router Cache After a Mutation

Server-side revalidation alone doesn't update the client's Router Cache. After a Server Action, you must invalidate the client cache too.

  • revalidatePath / revalidateTag inside a Server Action also marks the Router Cache stale, so the next navigation refetches.
  • router.refresh() from useRouter clears the Router Cache and re-renders server components for the current route.
  • A full page reload wipes the Router Cache entirely.

Pairing a Server Action's revalidateTag with the cookie-based action response keeps both server and client fresh.

'use client';
import { useRouter } from 'next/navigation';

export function RefreshButton() {
  const router = useRouter();
  return (
    <button onClick={() => router.refresh()}>
      Reload server data
    </button>
  );
}

Tracing a Request Through All Four

Follow a single navigation to see the layers cooperate:

  • 1. Router Cache (client): if a fresh payload exists, render it instantly — stop here.
  • 2. Full Route Cache (server): static route? serve the cached HTML/RSC.
  • 3. Data Cache (server): dynamic render reads fetch results from here if cached/unexpired.
  • 4. Request Memoization: within that render, duplicate fetches collapse into one.

Stale data originates at whichever layer answered first. Debug top-down: rule out the Router Cache before blaming the server.

A Pure-TS Memoization Analogy

Request Memoization is conceptually a per-render memo keyed by arguments. Here's the same idea in plain TypeScript you can run and reason about — it dedupes concurrent calls by caching the in-flight promise.

The real Next.js version resets this map each render; this demo keeps it for the program's lifetime.

function memoize<T>(fn: (k: string) => Promise<T>) {
  const inFlight = new Map<string, Promise<T>>();
  return (key: string): Promise<T> => {
    if (!inFlight.has(key)) inFlight.set(key, fn(key));
    return inFlight.get(key)!;
  };
}

let calls = 0;
const load = memoize(async (k: string) => {
  calls++;
  return `data:${k}`;
});

async function main() {
  const [a, b] = await Promise.all([load('x'), load('x')]);
  console.log(a, b, 'network calls =', calls);
}
main();

Quick Check: Stale UI After a Server Action

You run a Server Action that creates a product and calls revalidateTag('products'). The server's Data Cache and Full Route Cache are now correct, but a user who navigates back via a <Link> still sees the old list. Which layer is serving the stale data?

Recap: The Four Caches

You can now place any stale-data bug at the right layer:

  • Request Memoization — per-render fetch dedup; discarded after the render; extend to non-fetch with cache().
  • Data Cache — durable, cross-request fetch storage; opt in with force-cache/revalidate; purge with revalidateTag/revalidatePath.
  • Full Route Cache — rendered HTML/RSC for static routes; dynamic APIs opt out.
  • Router Cache — client-side RSC payloads for visited routes; clear with revalidation or router.refresh().

Debug top-down (client → server): rule out the Router Cache first, then Full Route, Data, and finally memoization.

Często zadawane pytania

Czy lekcja „Cztery pamięci podręczne: żądania, danych, pełnych tras i routera” jest bezpłatna?

Tak — pełny tekst „Cztery pamięci podręczne: żądania, danych, pełnych tras i routera” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Next.js 15 Fullstack (App Router + Server Actions), przejdź na CoddyKit PRO. Kurs Next.js 15 Fullstack (App Router + Server Actions) zawiera 4 lekcji w sumie.

Co nauczysz się w „Cztery pamięci podręczne: żądania, danych, pełnych tras i routera”?

Prześledź współdziałanie każdej warstwy pamięci podręcznej i miejsca powstawania nieaktualnych danych w aplikacjach App Router. Ćwiczysz Next.js 15 Fullstack (App Router + Server Actions) z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Next.js 15 Fullstack (App Router + Server Actions)?

Nie wymagamy żadnego doświadczenia. Next.js 15 Fullstack (App Router + Server Actions) w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.

Ile czasu zajmuje lekcja „Cztery pamięci podręczne: żądania, danych, pełnych tras i routera”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Next.js 15 Fullstack (App Router + Server Actions)?

Tak. Każda lekcja Next.js 15 Fullstack (App Router + Server Actions) zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Cztery pamięci podręczne: żądania, danych, pełnych tras i routera
  2. Strategie rewalidacji czasowej i na żądanie
  3. Unieważnianie pamięci podręcznej według tagów
  4. Rezygnacja z pamięci podręcznej: renderowanie dynamiczne i no-store
← Powrót do Next.js 15 Fullstack (App Router + Server Actions)