Next.js Cheatsheet - Next.js Framework Reference

Under the App Router, app/page.tsx is a Server Component by default; add "use client" only when the component needs browser APIs, event handlers or state, and understand that it converts that file plus its whole import tree into client code. The heuristic: if the component uses onClick, useState or useEffect, mark the smallest possible layer — usually a leaf component — and work upward, rather than slapping the directive on the top-level page. Server Components should not fetch inside useEffect; just async/await fetch directly in the component. The opposite tool is server-only, which guarantees a module never leaks into the client bundle, keeping secrets safe.

Three routes for three kinds of data. fetch(url, { cache: "force-cache" }) is the default static path — HTML is produced at build time, right for content that rarely changes. fetch(url, { next: { revalidate: 60 } }) is ISR: the page is revalidated in the background after 60 seconds, balancing speed against freshness. fetch(url, { cache: "no-store" }) is dynamic, refetching on every request for personalised or live data. At the page level you can pin the policy with export const dynamic = "force-static" or "force-dynamic", or set an ISR interval for the whole page with export const revalidate = 3600. Dynamic routes additionally need generateStaticParams() to enumerate the paths to pre-render.

Because a Server Action is a first-class capability inside your component tree: putting "use server" at the top of the function marks it as a server action, and you can pass it straight to a client form's action prop, skipping hand-written fetch calls and state bookkeeping. A Route Handler — an async function GET(request) exported from app/api/route.ts — is for external consumers: other programs calling you over defined HTTP semantics, or endpoints needing custom methods and response shapes. On the security side, server-only keeps secrets server-side, and sessions should be read with cookies().get("token") on the server rather than round-tripping a token through the client.

middleware.ts runs before a request reaches any route, which makes it the right home for cross-cutting rules applied uniformly: auth checks, redirects, header rewrites. NextResponse.redirect(new URL("/login", request.url)) sends unauthenticated users away, and NextResponse.next() lets the request continue. Doing the same check page by page is what invites bugs — every new route is a chance to forget, and the logic ends up scattered. Middleware has the request object, so path and cookie decisions are easy; keep it cheap, though, since it runs on every request. Anything expensive belongs in a page or a Route Handler, not here.

Pick based on the deployment target. output: "export" emits pure HTML/CSS/JS that any static host can serve, but the cost is that server-side capabilities — Route Handlers, Server Actions, ISR revalidation — stop working, so pages must be resolvable at build time. When you need a Node runtime and want a self-contained artifact, use output: "standalone", which bundles the required node_modules slice and fits Docker images neatly. Validate production behaviour locally with next build followed by next start serving the .next directory, never next dev. For environment-specific URLs use process.env.NEXT_PUBLIC_API_URL, remembering that NEXT_PUBLIC_-prefixed values get inlined into the client bundle.