Next.js — App Router, SSR & caches
Core details
App Router primitives:
app/layouts & pages: nested boundaries;loading.tsxanderror.tsxmodel suspense/error UI per segment.- Server Components (default) vs
"use client"islands—client components importable from server modules, but server-only modules cannot leak into client bundles incorrectly (packaging catches many cases).
Data & caching vocabulary (conceptual—not every flag memorized verbatim):
- Dynamic vs static segments affect what can be prerendered. Revalidation tags (
revalidateTag) and route segment config steer ISR-style behavior. - Fetch caching semantics changed across Next versions—interviews reward knowing fetch can be memoized across the tree for a layout vs opting into
cache: 'no-store'when freshness dominates.
Rendering modes: SSR (request-time HTML), SSG-ish builds where allowed, streaming with Suspense—in practice fallback UI matters for skeleton quality and CLS.
Metadata & images: built-in optimizations (next/image, font loading) imply CDN and layout stability commitments—articulate breakage when migrating off defaults.
Understanding
Next’s App Router merges routing, data fetching, and component graph tightly. Staff-level clarity separates three cache layers mentally: CDN/full-route output, fetch/data cache policies, and client router cache intuition (soft vs hard navigation freshness). Bugs often arrive as stale personalization (“Why did middleware see auth but my RSC still showed guest?”)—usually mismatch between cookies/headers propagation and what was treated as static.
Senior understanding
| Lens | Speak to |
|---|---|
| Security | Server actions surface area—authenticate and authorize server-side always; validate serialized inputs like any RPC. |
| Ops | Self-host vs Vercel: Node adapter, ISR storage, middleware edge runtime limits; instrumentation for SSR errors vs client hydration. |
| Perf | Minimize "use client" roots; defer heavy deps; intentional parallel routes/@slots sparingly—they’re powerful but complex for teams. |
Trap answers: “RSC solves all data loading” without discussing serialization and latency to TTFB; ignoring cold start / pool realities on serverless; treating client cache as magically consistent with server caches.
Diagram
See also
Last updated on
Spotted something unclear or wrong on this page?