Next.js / Basic: routes and execution boundaries / Lesson 1

App Router rendering and application boundaries

Separate route composition, server rendering, browser interaction and domain authority before choosing component boundaries.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain why server/client component identity is not the same as static/dynamic rendering.
Describe the selected caching mode and honest local verification boundary.

A route is a composition across execution environments

Next.js App Router combines React components, file conventions and server capabilities into a route tree. Server Components can perform server-side work and return rendered descriptions without shipping their implementation to the browser. Client Components add state, event handlers and browser integrations. This is not a division between secure and insecure business rules: every server entry point still needs domain authorization. A course portal can keep an eligible course read in a server-only data layer while passing a narrow public card to a small interactive control. Start from data ownership and user tasks rather than marking the whole application client-side.

State the rendering configuration before discussing cache behavior

This course’s primary examples select App Router with Cache Components disabled. That makes traditional fetch and route-cache guidance the applicable starting model. A later advanced lesson separately opts into Cache Components and current Partial Prefetching configuration. Do not mix instructions from those modes or assume a flag name from an older experimental release has the same meaning. The configuration fragment is illustrative and no Next build was run. Current documentation was reviewed on 2026-10-28; pin exact Next, React and runtime versions before real integration.

typescript Primary-mode configuration illustration

import type { NextConfig } from "next";
const config: NextConfig = {cacheComponents:false};
export default config;

The selected examples use the documented model without Cache Components unless a lesson explicitly opts into another mode. No config is applied.

Distinguish build work, request work and hydration

A Server Component is not automatically evaluated once per request; prerendering and caching determine when its output is produced or reused. A Client Component is not necessarily absent from initial server-rendered HTML. Initial rendering can provide HTML before client code hydrates interactive behavior, while navigation can exchange React Server Component payloads. Hydration requires consistent initial output. Keep browser-only access out of server evaluation and do not call a render function a safe place for side effects. Rendering may occur for build, prefetch or retry rather than only after a visible user click.

Test the public boundary as a plain function

The local projection strips an internal note from a synthetic course record. It is complete JavaScript and needs no React or Next package. This verifies which properties the function returns, not whether a Server Component authorizes access or a React payload serializes correctly. Pass only data intended for the receiving client boundary and choose serializable values supported by React. A secret can leak through rendered text or props even when its source module runs only on the server. Execution location protects implementation code, not every value that code deliberately returns.

javascript Complete offline public-card model

function publicCard(record) {return {id:record.id,title:record.title};}
const card=publicCard({id:"c1",title:"App Router",internalNote:"lab-only"});
console.assert(JSON.stringify(card) === '{"id":"c1","title":"App Router"}');
console.assert(!Object.hasOwn(card,"internalNote"));

Both assertions pass for the synthetic record. No React rendering, hydration or Next route was executed.

Keep framework and operational claims separate

This course uses the Next 16 App Router documentation baseline and stable React concepts; the App Router’s bundled React features must match the selected Next release rather than an arbitrary independent canary. Server actions, Route Handlers and data access all need explicit input and permission contracts. Deployment platforms also differ in runtime and cache persistence. Local function and JSON checks cannot establish a build, browser, server cache or hosting result. Every framework fragment remains runnable:false, and no dependency installation, development server, database, cloud or live endpoint is used during authoring.

Common errors and fixes

A Client Component is assumed browser-only

Why it happens: Component boundary and initial rendering were conflated.
How to fix it: Design consistent initial output and isolate browser APIs appropriately.
Prevent it next time: Test server render and hydration separately in real integration.

A Server Component leaks private fields

Why it happens: Server execution was mistaken for automatic output privacy.
How to fix it: Authorize reads and project permitted data.
Prevent it next time: Review rendered text and client props.

Cache advice changes when a flag is enabled

Why it happens: Two rendering/cache models were mixed.
How to fix it: Record the exact mode before applying guidance.
Prevent it next time: Retain configuration with behavioral fixtures.

Check your understanding

1. Does a successful projection assertion prove that the course page is secure?

Show worked solution

No. It proves only that this function returns two keys for its fixture. Authentication, object eligibility, routing, serialization and cache audience are untested. Preserve that narrow evidence and separately verify the actual server/client boundary in an authorized isolated project rather than treating server placement as a complete privacy guarantee.

2. Why should mutations not happen during component rendering?