## Introduction: Next.js Under the Hood If you've read the [Next.js 101 guide](/posts/2026/nextjs/nextjs-101-the-ultimate-beginners-guide), you know how to build pages, fetch data, and deploy. This guide goes deeper. We'll look at **why** Next.js makes the decisions it does, what happens behind the scenes when a page renders, and how to use advanced features to build production-grade applications. The App Router represents a fundamental shift in web architecture. Server Components, streaming, and the multi-layered caching system aren't just features — they're a new mental model for how data flows from the server to the browser. Understanding this model is the difference between using Next.js and mastering it. By the end of this guide you will: - Understand how React Server Components work at a protocol level - Know the four caching layers and how to control each one - Use streaming and Suspense for progressive rendering - Build complex layouts with parallel and intercepting routes - Implement server actions with optimistic updates and form validation - Write middleware for auth, redirects, and rate limiting - Choose between Edge Runtime and Node.js Runtime - Integrate authentication and database access patterns - Optimize bundle size, performance, and error handling for production Examples use **TypeScript** throughout. Let's start with the internals. --- ## React Server Components: The Full Picture ### What Happens When a Server Component Renders When the server renders a page, it doesn't produce HTML directly. It produces an **RSC payload** — a serialized description of the component tree. This payload is a compact, streaming-friendly format that describes: 1. Which components are Server Components (already rendered to their final output) 2. Which components are Client Components (placeholders that the browser will hydrate) 3. The props passed between them (serialized data) The flow looks like this: 1. **Server executes** all Server Components — database queries run, async operations resolve, JSX is produced 2. Server Components are **resolved to their output** (strings, HTML elements, primitive values) 3. Client Component positions are replaced with **placeholder references** — "put `` here with these serialized props" 4. The RSC payload is **streamed** to the browser 5. The browser **reconstructs the tree** — Server Component output is placed directly, Client Components are hydrated with their JavaScript ### The Serialization Boundary The boundary between Server and Client Components is a **serialization boundary**. Everything that crosses it must be serializable: ✅ **Can cross the boundary:** strings, numbers, booleans, `null`, `undefined`, arrays, plain objects, `Date`, `Map`, `Set`, `BigInt`, typed arrays, `FormData`, `ReadableStream` ❌ **Cannot cross:** functions (callbacks, event handlers), class instances, Symbols, DOM nodes, closures This is why you can't pass `onClick` from a Server Component to a Client Component. The function can't be serialized and sent over the network. ### The Children Pattern (Composition) The most important RSC pattern is passing Server Components as `children` to Client Components: ```tsx // app/page.tsx — Server Component import ClientShell from './client-shell'; import ServerContent from './server-content'; export default function Page() { return ( {/* Client Component */} {/* Server Component rendered as children */} ); } ``` ```tsx // app/client-shell.tsx 'use client'; import { useState } from 'react'; export default function ClientShell({ children }: { children: React.ReactNode }) { const [isOpen, setIsOpen] = useState(true); return (

{isOpen && children} {/* Server Component output is already resolved */}

); } ``` How this works: `ServerContent` is rendered on the server and its output (HTML) is serialized into the RSC payload. The Client Component receives it as `children` — it's already resolved, so no server code runs on the client. The Client Component just decides whether to display it. ### 'use client' Is a Boundary Declaration `'use client'` doesn't mean "this entire file runs on the client." It means "this is where the server-to-client boundary starts." Everything imported by this file (and its children) becomes part of the client bundle. ```tsx // ❌ Bad — importing a heavy server-only library in a client component 'use client'; import { analyzeData } from 'heavy-analysis-lib'; // This gets bundled into the client // ✅ Good — keep the analysis on the server, pass results as props // server-component.tsx (Server Component) import { analyzeData } from 'heavy-analysis-lib'; const result = await analyzeData(rawData); return ; ``` ### server-only and client-only Guards Ensure modules aren't accidentally imported in the wrong environment: ```bash npm install server-only client-only ``` ```tsx // lib/db.ts — should never be imported in a client component import 'server-only'; import { drizzle } from 'drizzle-orm/postgres-js'; export const db = drizzle(/* ... */); ``` If a Client Component imports this file (directly or transitively), the build fails with a clear error instead of leaking server code to the client. --- ## The Caching Architecture Next.js has **four layers of caching**, each serving a different purpose. Understanding them is critical for controlling data freshness and performance. ### Layer 1: Request Memoization When multiple components in the same render request fetch the same URL, Next.js **deduplicates** them: ```tsx // Both of these components are in the same page async function Header() { const user = await fetch('/api/user'); // Request #1 return

{user.name}

; } async function Sidebar() { const user = await fetch('/api/user'); // Same URL — reuses Request #1 return

{user.email}

; } ``` Only one network request is made. This memoization is **per-render** — it doesn't persist between different page loads. **Scope:** Single server render. Cleared after the response is sent. ### Layer 2: Data Cache The **Data Cache** stores the results of `fetch` requests on the server. It persists across requests and deployments (until explicitly invalidated): ```tsx // Cached indefinitely (default) await fetch('https://api.example.com/data'); // Cached for 60 seconds await fetch('https://api.example.com/data', { next: { revalidate: 60 }, }); // Not cached await fetch('https://api.example.com/data', { cache: 'no-store', }); // Tagged for on-demand revalidation await fetch('https://api.example.com/data', { next: { tags: ['products'] }, }); ``` **Scope:** Persistent. Survives across requests. Shared between users. ### Layer 3: Full Route Cache For static routes, Next.js caches the **entire rendered output** (HTML + RSC payload) at build time. Subsequent requests serve the cached version without re-rendering: ```tsx // This page is fully cached at build time export default async function AboutPage() { return

About us

; } ``` Dynamic routes (those using `cookies()`, `headers()`, `searchParams`, or `cache: 'no-store'`) are **not** stored in the Full Route Cache. **Scope:** Persistent. Generated at build time or on first request. Invalidated by revalidation. ### Layer 4: Router Cache (Client-Side) The browser caches visited route segments in memory. When you navigate back to a page you've already seen, it loads instantly from the client cache: ```tsx // User visits /dashboard → cached in browser // User navigates to /settings // User clicks "Back" → /dashboard loads instantly from Router Cache ``` **Scope:** Browser session. Cleared on hard refresh or after a timeout (30 seconds for dynamic, 5 minutes for static routes). ### Controlling the Caches | Need | Solution | |------|----------| | Revalidate after a mutation | `revalidatePath('/products')` or `revalidateTag('products')` in a Server Action | | Force dynamic rendering | `export const dynamic = 'force-dynamic'` or `cache: 'no-store'` on fetch | | Time-based revalidation | `export const revalidate = 60` or `next: { revalidate: 60 }` on fetch | | Skip Router Cache | `router.refresh()` in a Client Component | | Opt out of all caching | `export const dynamic = 'force-dynamic'` + `export const fetchCache = 'force-no-store'` | ### Cache Invalidation with Tags Tags let you invalidate specific data across your app: ```tsx // Fetching with a tag const products = await fetch('https://api.example.com/products', { next: { tags: ['products'] }, }); // In a Server Action, invalidate by tag 'use server'; import { revalidateTag } from 'next/cache'; export async function updateProduct(id: string, data: ProductInput) { await db.update(products).set(data).where(eq(products.id, id)); revalidateTag('products'); // All fetches tagged 'products' are re-fetched } ``` --- ## Streaming and Suspense ### How Streaming Works Traditional server rendering waits for **all data** before sending any HTML. Streaming sends HTML **progressively** — the shell first, then individual sections as they resolve: 1. The server sends the layout, navigation, and any static content immediately 2. Async sections (data-dependent components) are wrapped in `` boundaries 3. As each section's data resolves, the server streams the HTML for that section 4. The browser progressively fills in the page The user sees a meaningful page almost instantly, with loading indicators for sections still being fetched. ### loading.tsx as Suspense Boundary When you create `loading.tsx`, Next.js automatically wraps the corresponding `page.tsx` in a Suspense boundary: ```tsx // app/dashboard/loading.tsx export default function DashboardLoading() { return ; } ``` This is equivalent to: ```tsx }> ``` ### Manual Suspense Boundaries For more granular control, use `` directly: ```tsx import { Suspense } from 'react'; export default function DashboardPage() { return (

}> {/* Loads independently */} }> {/* Loads independently */} }> {/* Loads independently */}

); } ``` Each section streams in as its data resolves. If `RecentOrders` takes 2 seconds but `RevenueChart` takes 500ms, the chart appears first. The user doesn't wait for the slowest query. ### Streaming with Nested Layouts Layouts are streamed before their children. This means the navigation bar and sidebar appear instantly, even if the page content takes time to load: ``` Timeline: 0ms → Layout (nav, sidebar) rendered 50ms → Static page content streamed 500ms → RevenueChart data resolves → streamed 1200ms → RecentOrders data resolves → streamed 2000ms → UserStats data resolves → streamed ``` --- ## Parallel Routes and Intercepting Routes ### Parallel Routes Parallel routes let you render **multiple pages simultaneously** in the same layout, each with its own loading and error states. They're defined using named "slots" with the `@` prefix: ``` app/ ├── layout.tsx ├── page.tsx ├── @analytics/ │ ├── page.tsx │ └── loading.tsx ├── @team/ │ ├── page.tsx │ └── loading.tsx ``` ```tsx // app/layout.tsx export default function Layout({ children, analytics, team, }: { children: React.ReactNode; analytics: React.ReactNode; team: React.ReactNode; }) { return (

{children}

{analytics} {team}

); } ``` Each slot loads independently. If `@analytics` is slow, `@team` still renders. Each slot can have its own `loading.tsx` and `error.tsx`. ### Intercepting Routes Intercepting routes let you load a route **within the context of the current layout** — the classic example is opening a photo in a modal while the gallery stays visible: ``` app/ ├── feed/ │ ├── page.tsx → /feed (gallery) │ ├── @modal/ │ │ ├── default.tsx │ │ └── (.)photo/[id]/ │ │ └── page.tsx → Intercepts /photo/[id] → shows in modal │ └── layout.tsx ├── photo/ │ └── [id]/ │ └── page.tsx → /photo/[id] (full page — direct navigation) ``` The `(.)` prefix means "intercept at the same level." When the user clicks a photo link from `/feed`, the photo opens in a modal. When they navigate directly to `/photo/123`, they get the full-page view. Intercept prefixes: - `(.)` — same level - `(..)` — one level up - `(..)(..)` — two levels up - `(...)` — from root --- ## Server Actions Deep Dive ### Progressive Enhancement Server Actions work without JavaScript. This means forms degrade gracefully: ```tsx // This form works even if JS fails to load export default function ContactForm() { async function submitForm(formData: FormData) { 'use server'; const name = formData.get('name') as string; const email = formData.get('email') as string; await db.insert(contacts).values({ name, email }); redirect('/thank-you'); } return ( ); } ``` With JS enabled: the form submits via fetch, no page reload. Without JS: the form submits as a traditional POST request with a full page reload. ### Optimistic Updates Show the expected result immediately while the server processes the mutation: ```tsx 'use client'; import { useOptimistic } from 'react'; import { addTodo } from '@/app/actions/todo-actions'; interface Todo { id: string; title: string; pending?: boolean; } export default function TodoList({ todos }: { todos: Todo[] }) { const [optimisticTodos, addOptimisticTodo] = useOptimistic( todos, (state: Todo[], newTodo: Todo) => [...state, { ...newTodo, pending: true }] ); async function handleSubmit(formData: FormData) { const title = formData.get('title') as string; addOptimisticTodo({ id: crypto.randomUUID(), title }); await addTodo(formData); } return (

{todo.title}

); } ``` The new todo appears immediately (at 50% opacity) while the server inserts it. Once the server responds, the page revalidates and the real data replaces the optimistic version. ### useActionState for Form Validation Handle server-side validation errors and return them to the form: ```tsx 'use server'; import { z } from 'zod'; const schema = z.object({ email: z.string().email('Invalid email'), password: z.string().min(8, 'Password must be at least 8 characters'), }); export type FormState = { errors?: { email?: string[]; password?: string[] }; message?: string; }; export async function signUp(prevState: FormState, formData: FormData): Promise { const parsed = schema.safeParse({ email: formData.get('email'), password: formData.get('password'), }); if (!parsed.success) { return { errors: parsed.error.flatten().fieldErrors }; } await createUser(parsed.data); return { message: 'Account created!' }; } ``` ```tsx 'use client'; import { useActionState } from 'react'; import { signUp, type FormState } from '@/app/actions/auth-actions'; const initialState: FormState = {}; export default function SignUpForm() { const [state, formAction, isPending] = useActionState(signUp, initialState); return ( ); } ``` --- ## Middleware Patterns ### Authentication Guard ```tsx // middleware.ts import { NextResponse } from 'next/server'; import type { NextRequest } from 'next/server'; const protectedRoutes = ['/dashboard', '/settings', '/profile']; const authRoutes = ['/login', '/register']; export function middleware(request: NextRequest) { const token = request.cookies.get('session-token')?.value; const { pathname } = request.nextUrl; const isProtected = protectedRoutes.some(route => pathname.startsWith(route)); const isAuthRoute = authRoutes.some(route => pathname.startsWith(route)); if (isProtected && !token) { const loginUrl = new URL('/login', request.url); loginUrl.searchParams.set('callbackUrl', pathname); return NextResponse.redirect(loginUrl); } if (isAuthRoute && token) { return NextResponse.redirect(new URL('/dashboard', request.url)); } return NextResponse.next(); } export const config = { matcher: ['/dashboard/:path*', '/settings/:path*', '/profile/:path*', '/login', '/register'], }; ``` ### Rate Limiting ```tsx // middleware.ts const rateLimit = new Map(); function isRateLimited(ip: string, limit: number, windowMs: number): boolean { const now = Date.now(); const entry = rateLimit.get(ip); if (!entry || now > entry.resetAt) { rateLimit.set(ip, { count: 1, resetAt: now + windowMs }); return false; } entry.count += 1; return entry.count > limit; } export function middleware(request: NextRequest) { if (request.nextUrl.pathname.startsWith('/api')) { const ip = request.headers.get('x-forwarded-for')?.split(',')[0] || 'unknown'; if (isRateLimited(ip, 100, 60_000)) { return NextResponse.json({ error: 'Too many requests' }, { status: 429 }); } } return NextResponse.next(); } ``` ### A/B Testing with Cookies ```tsx export function middleware(request: NextRequest) { const response = NextResponse.next(); const variant = request.cookies.get('ab-variant')?.value; if (!variant) { const newVariant = Math.random() < 0.5 ? 'A' : 'B'; response.cookies.set('ab-variant', newVariant, { maxAge: 60 * 60 * 24 * 30 }); } return response; } ``` --- ## Edge Runtime vs Node.js Runtime ### Node.js Runtime (Default) The default runtime. Full access to Node.js APIs, unlimited execution time, and the full npm ecosystem: ```tsx // Uses Node.js runtime by default export default async function Page() { const data = await fetchData(); return

{data}

; } ``` ### Edge Runtime Runs on a lightweight V8 isolate (like Cloudflare Workers). Lower latency (runs closer to the user) but limited APIs: ```tsx // app/api/geo/route.ts export const runtime = 'edge'; export async function GET(request: Request) { return new Response(JSON.stringify({ message: 'Hello from the edge!' })); } ``` ### Decision Table | Factor | Node.js Runtime | Edge Runtime | |--------|----------------|-------------| | Cold start | Slower (~250ms) | Faster (~0-50ms) | | APIs | Full Node.js APIs | Web APIs only (no `fs`, `child_process`, etc.) | | npm packages | All supported | Only packages that don't use Node.js-specific APIs | | Database | Direct connections (TCP) | HTTP-based clients only (Supabase, PlanetScale, Neon) | | Execution time | Unlimited | Limited (typically 30s on Vercel) | | Best for | Complex server logic, database queries | Auth checks, redirects, geo-routing, simple transforms | Use Edge Runtime for **middleware** and **simple API routes**. Use Node.js Runtime for **everything else**. --- ## Authentication Patterns ### Auth.js (NextAuth) Integration ```tsx // auth.ts import NextAuth from 'next-auth'; import GitHub from 'next-auth/providers/github'; import { DrizzleAdapter } from '@auth/drizzle-adapter'; import { db } from '@/lib/db'; export const { handlers, auth, signIn, signOut } = NextAuth({ adapter: DrizzleAdapter(db), providers: [ GitHub({ clientId: process.env.GITHUB_CLIENT_ID!, clientSecret: process.env.GITHUB_CLIENT_SECRET!, }), ], }); ``` ```tsx // app/api/auth/[...nextauth]/route.ts import { handlers } from '@/auth'; export const { GET, POST } = handlers; ``` ### Protecting Server Components ```tsx // app/dashboard/page.tsx import { auth } from '@/auth'; import { redirect } from 'next/navigation'; export default async function DashboardPage() { const session = await auth(); if (!session?.user) { redirect('/login'); } return (

Welcome, {session.user.name}

); } ``` ### Session in Server Actions ```tsx 'use server'; import { auth } from '@/auth'; export async function updateProfile(formData: FormData) { const session = await auth(); if (!session?.user) throw new Error('Unauthorized'); const name = formData.get('name') as string; await db.update(users).set({ name }).where(eq(users.id, session.user.id)); revalidatePath('/profile'); } ``` --- ## Database Integration Patterns ### Drizzle ORM with Server Components ```tsx // lib/db/schema.ts import { pgTable, uuid, varchar, timestamp, text } from 'drizzle-orm/pg-core'; export const posts = pgTable('posts', { id: uuid('id').defaultRandom().primaryKey(), title: varchar('title', { length: 255 }).notNull(), content: text('content').notNull(), authorId: uuid('author_id').notNull(), createdAt: timestamp('created_at').defaultNow().notNull(), updatedAt: timestamp('updated_at').defaultNow().notNull(), }); ``` ```tsx // app/posts/page.tsx — Server Component import { db } from '@/lib/db'; import { posts } from '@/lib/db/schema'; import { desc } from 'drizzle-orm'; export default async function PostsPage() { const allPosts = await db .select() .from(posts) .orderBy(desc(posts.createdAt)) .limit(20); return (

{post.title}
{post.createdAt.toLocaleDateString()}

); } ``` No API layer. No loading states. The query runs on the server, the HTML is rendered, and only the HTML is sent to the browser. ### Preventing Database Waterfalls When components each fetch data independently, they create **sequential waterfalls**: ```tsx // ❌ Sequential — each await blocks the next export default async function Dashboard() { const user = await getUser(); // 200ms const posts = await getPosts(); // 300ms const analytics = await getAnalytics(); // 400ms // Total: 900ms (sequential) } // ✅ Parallel — all fetches start at the same time export default async function Dashboard() { const [user, posts, analytics] = await Promise.all([ getUser(), // 200ms getPosts(), // 300ms getAnalytics(), // 400ms ]); // Total: 400ms (parallel — limited by the slowest) } ``` Even better — use Suspense boundaries to stream each section independently (covered in the Streaming section). --- ## Performance Optimization ### Bundle Analysis Install the bundle analyzer: ```bash npm install @next/bundle-analyzer ``` ```js // next.config.js const withBundleAnalyzer = require('@next/bundle-analyzer')({ enabled: process.env.ANALYZE === 'true', }); module.exports = withBundleAnalyzer({ // your config }); ``` ```bash ANALYZE=true npm run build ``` This opens a visual report of your JavaScript bundles, helping you identify oversized dependencies. ### Dynamic Imports (Code Splitting) Lazy-load heavy components that aren't needed on initial render: ```tsx import dynamic from 'next/dynamic'; const HeavyChart = dynamic(() => import('./heavy-chart'), { loading: () => , ssr: false, // Only render on the client (for browser-only libraries) }); export default function Dashboard() { return (

Dashboard

); } ``` ### Tree Shaking Tips - Import specific functions instead of entire libraries: `import { format } from 'date-fns'` not `import * as dateFns from 'date-fns'` - Keep `'use client'` components small — everything they import goes to the client bundle - Use the Server Component → Client Component composition pattern to minimize client JavaScript ### Image Optimization Checklist - Use `next/image` for all images - Set explicit `width` and `height` (or use `fill` with a sized container) - Use `priority` for above-the-fold images (LCP) - Use `placeholder="blur"` with `blurDataURL` for a better loading experience - Configure `formats: ['image/avif', 'image/webp']` in `next.config.js` for modern formats --- ## Error Handling Patterns ### Route-Level Error Boundaries ```tsx // app/dashboard/error.tsx 'use client'; export default function DashboardError({ error, reset, }: { error: Error & { digest?: string }; reset: () => void; }) { return (

Dashboard Error

{error.message}

); } ``` ### Global Error Handler For errors in the root layout itself: ```tsx // app/global-error.tsx 'use client'; export default function GlobalError({ error, reset, }: { error: Error & { digest?: string }; reset: () => void; }) { return (

Something went wrong

); } ``` `global-error.tsx` must include its own `` and `` tags because it replaces the root layout when triggered. ### Graceful Degradation in Server Components ```tsx export default async function PostPage({ params }: { params: { slug: string } }) { try { const post = await getPost(params.slug); return

; } catch { notFound(); // Triggers the nearest not-found.tsx } } ``` --- ## Testing Strategies ### Unit Testing with Jest ```tsx // __tests__/utils.test.ts import { formatDate, slugify } from '@/lib/utils'; describe('formatDate', () => { it('formats ISO date to readable string', () => { expect(formatDate('2026-02-18')).toBe('February 18, 2026'); }); }); describe('slugify', () => { it('converts title to URL-safe slug', () => { expect(slugify('Hello World!')).toBe('hello-world'); }); }); ``` ### Component Testing with React Testing Library ```tsx // __tests__/components/search.test.tsx import { render, screen, fireEvent } from '@testing-library/react'; import SearchInput from '@/app/components/search-input'; describe('SearchInput', () => { it('calls onChange with input value', () => { const handleChange = jest.fn(); render(); fireEvent.change(screen.getByRole('searchbox'), { target: { value: 'test' } }); expect(handleChange).toHaveBeenCalledWith('test'); }); }); ``` ### E2E Testing with Playwright ```tsx // e2e/navigation.spec.ts import { test, expect } from '@playwright/test'; test('navigates from home to blog', async ({ page }) => { await page.goto('/'); await page.click('text=Blog'); await expect(page).toHaveURL('/blog'); await expect(page.locator('h1')).toContainText('Blog'); }); test('submits contact form', async ({ page }) => { await page.goto('/contact'); await page.fill('#name', 'Test User'); await page.fill('#email', 'test@example.com'); await page.fill('#message', 'Hello, this is a test message.'); await page.click('button[type="submit"]'); await expect(page.locator('text=Thank you')).toBeVisible(); }); ``` --- ## Production Checklist Before deploying, run through this checklist: ### Performance - [ ] Run `npm run build` and check for static vs dynamic routes - [ ] Analyze bundle size with `@next/bundle-analyzer` - [ ] Ensure above-the-fold images use `priority` - [ ] Use `loading.tsx` for all data-heavy pages - [ ] Parallel data fetching with `Promise.all` or Suspense boundaries ### SEO - [ ] Set `metadataBase` in root layout - [ ] Add `generateMetadata` to dynamic pages - [ ] Create `app/sitemap.ts` for search engines - [ ] Create `app/robots.ts` for crawl directives - [ ] Test Open Graph tags with social sharing debuggers ### Security - [ ] No secrets in `NEXT_PUBLIC_` variables - [ ] Validate all Server Action inputs with Zod - [ ] Add CSRF protection (built-in for Server Actions) - [ ] Set security headers in `next.config.js` or middleware - [ ] Use `server-only` package for server modules ### Error Handling - [ ] Add `error.tsx` to critical route segments - [ ] Add `global-error.tsx` for root-level errors - [ ] Add `not-found.tsx` for 404 pages - [ ] Wrap `generateMetadata` in try/catch ### Monitoring - [ ] Set up error tracking (Sentry, LogRocket) - [ ] Configure analytics (Google Analytics, Vercel Analytics) - [ ] Monitor Core Web Vitals --- ## Quick Reference ### Route Segment Config ```tsx // Set at the top of page.tsx or layout.tsx export const dynamic = 'auto' | 'force-dynamic' | 'error' | 'force-static'; export const revalidate = false | 0 | number; export const fetchCache = 'auto' | 'default-cache' | 'only-cache' | 'force-cache' | 'force-no-store' | 'default-no-store' | 'only-no-store'; export const runtime = 'nodejs' | 'edge'; export const preferredRegion = 'auto' | 'global' | 'home' | string | string[]; ``` ### Revalidation Functions ```tsx import { revalidatePath } from 'next/cache'; import { revalidateTag } from 'next/cache'; revalidatePath('/products'); // Revalidate a specific path revalidatePath('/products', 'layout'); // Revalidate everything in the layout revalidateTag('products'); // Revalidate all fetches with this tag ``` ### Navigation Functions ```tsx import { redirect } from 'next/navigation'; import { notFound } from 'next/navigation'; import { permanentRedirect } from 'next/navigation'; redirect('/login'); // 307 redirect permanentRedirect('/new'); // 308 redirect notFound(); // Trigger not-found.tsx ``` --- ## Final Thoughts Next.js's App Router is a fundamentally different way to build web applications. Server Components, streaming, the four caching layers, and server actions represent a shift from "fetch data on the client" to "render as much as possible on the server and stream it down." The key mental model shifts: 1. **Server-first.** Default to Server Components. Push Client Components to the leaves. 2. **Streaming over waterfalls.** Use Suspense boundaries to stream independent sections. 3. **Cache by default, opt out explicitly.** Understand the four caching layers and control them intentionally. 4. **Forms are server actions.** No API routes for internal mutations. Server Actions are simpler and type-safe. 5. **Composition over configuration.** The file system is your router. Layouts compose automatically. For related topics, check out: - [Next.js 101: The Ultimate Beginner's Guide](/posts/2026/nextjs/nextjs-101-the-ultimate-beginners-guide) — if you need to brush up on the fundamentals - [React 101: The Ultimate Beginner's Guide](/posts/2025/react/react-101-the-ultimate-beginners-guide) — for React foundations - [useMemo vs useCallback: The Complete Deep Dive](/posts/2026/react/usememo-vs-usecallback-the-complete-deep-dive) — for React performance patterns --- Now go build something production-ready.

{user.name}

Welcome, {session.user.name}

{post.title}

Dashboard

Dashboard Error

Something went wrong

Next.js: The Complete Deep Dive