Next.js 16 for developers

Nearly every Next.js problem people bring to a colleague reduces to one of two questions: where does this code run, and when was this output cached? Developers who can answer both for any line of their application rarely get stuck.

The framework has become more explicit about both over successive versions, which is good but means the mental model matters more, not less. Copying patterns without understanding them produces applications that work locally and behave strangely in production.

The App Router builds directly on React Server Components, so the boundary discussion from React applies here first. Files are server-side by default, and interactivity is opted into deliberately.

The conventions carry real meaning rather than being naming ceremony. Layouts persist across navigation and do not re-render, which is why putting request-specific logic in one causes confusing staleness. Loading and error files define Suspense and error boundaries implicitly.

• Server by default; client components opted into explicitly
• Layouts persist across navigation — state in them survives
• Loading files create Suspense boundaries for free
• Error files scope error boundaries to a segment
• Route handlers for API endpoints, separate from page rendering

The caching model is the single most common source of production surprises. Data that should be fresh is stale; pages that should be static are rendered per request; a deployment behaves differently from local development because development disables much of it.

The way to stay out of trouble is to be deliberate rather than implicit. Decide for each data dependency whether it can be cached, for how long, and what should invalidate it — and write that decision down in the code rather than relying on defaults you have not read.

Server actions let a client component invoke server code without writing an endpoint. They remove a lot of ceremony for forms and mutations, and they pair naturally with the React Actions model.

The security point is easy to miss: a server action is a public endpoint. It does not matter that it is only called from one component behind a permission check, because the endpoint can be invoked directly. Every action needs its own authentication and authorisation, exactly as an API route would.

• Authenticate and authorise inside every action, not only in the caller
• Validate inputs — the caller is not the only possible caller
• Keep secrets in the action, never passed in as props
• Revalidate affected caches deliberately after a mutation

The biggest wins are usually structural rather than configuration. Shrinking the client boundary so less JavaScript ships. Avoiding sequential data fetches that could run in parallel. Streaming so the page is useful before every dependency resolves.

Image and font handling deserve attention because they dominate perceived load time on real connections, and the framework handles both well if you use the provided components rather than raw tags.

Expect questions about where code runs, how you would cache a specific piece of data and why, and how you would secure a server action. These separate candidates who have shipped a Next.js application from those who have followed a tutorial.

A strong answer to the security question in particular — recognising unprompted that a server action is a public endpoint — signals real production experience more reliably than listing features.