Next.js App Router In 2026: Server Components, Caching, And Route Boundaries

The **Next.js App Router** (introduced in Next.js 13, mature through 14 and 15, and the default for new projects in 2026) models routes as a tree of **React Server Components** by default. Files named `page.tsx` and `layout.tsx` in the `app/` directory are Server Components unless marked with `"use client"`. Client Components handle interactivity; Server Components can read data and render HTML without shipping that logic to the browser.

Data fetching in Server Components uses standard `async`/`await`. Next.js documents **caching semantics** through `fetch` options (`cache`, `next.revalidate`), `unstable_cache`, and route segment config such as `export const dynamic = 'force-dynamic'`. Treat the official `nextjs.org/docs/app` guides as authoritative: caching behavior changed across minors, and release notes matter more than year-old tutorials.

Common pitfalls: marking an entire page `"use client"` when only a button needs hooks; passing non-serializable props (functions, class instances) from server to client children; and assuming `fetch` deduplication covers every data source (it applies to the built-in `fetch` cache, not arbitrary database clients).

For production: colocate loading and error UI with `loading.tsx` and `error.tsx`, keep secrets on the server, and align your deployment platform's Node/runtime version with Next's supported matrix on `nextjs.org`.