React for Two Computers
by Dan Abramov
Dan Abramov derives React Server Components from first principles, distinguishing imperative 'recipes' from declarative 'blueprints' and showing why splitting a program across two machines produces the server/client boundary the App Router is built on. Explains why the App Router's constraints exist rather than what its APIs are, which is the difference between a developer who fights the framework and one who predicts it.
More resources on Next.js
Composition, Caching, and Architecture in Modern Next.js
Next.js Conf 2025 talk on structuring App Router applications at scale: composing server and client components, where boundaries belong, and how the current caching model and routing behaviour shape real project architecture. It answers the question the docs deliberately do not — how to lay out a large App Router codebase — from someone inside the team.
Common Mistakes with the Next.js App Router and How to Fix Them
Ten concrete anti-patterns with corrected code: needless Route Handlers between server components and data, misplaced Suspense boundaries, over-applied 'use client', broken context composition, missed revalidation after mutations, and redirect inside try/catch.
Making Sense of React Server Components
Long-form explainer separating React Server Components from server-side rendering, then working through the 'use client' boundary, component composition rules, serialization of props across the boundary, and the bundle-size and hydration consequences.
Next.js App Router Documentation
Official reference for the App Router, currently documenting Next.js 16. Covers project structure, layouts, linking and prefetching, server versus client components, data fetching, mutations, caching, revalidation, route handlers, metadata and deployment.
Learn Next.js: App Router Foundations
Vercel's official 16-chapter course builds a Postgres-backed financial dashboard, covering App Router file conventions, layouts, server-side data fetching, streaming, Server Actions, error handling, authentication and metadata, with code checkpoints per chapter. Project-based rather than a feature tour: you ship a real app with a database, mutations and auth. Kept current with the framework, so it teaches the App Router as the primary path with no Pages Router legacy.