Next.js Patterns
Use App Router, server boundaries, data fetching, and route ownership consistently.
Key takeaways
- Next.js architecture should make rendering, data access, and route ownership explicit to reduce accidental client complexity and route coupling.
- Use the server side for secure data, secrets, session context, and bundle reduction; use the client only for interactivity, browser events, and browser-only APIs.
- Keep data fetching close to route ownership, never pass secrets into client components, and make caching and revalidation visible in review.
- In Next.js 16, prefer
proxy.tsovermiddleware.ts(Node.js runtime, noruntimeconfig), and enablecacheComponentswithuse cache,cacheLife, andcacheTag. - Keep slow data fetching out of Proxy, moving it to Route Handlers, Server Actions, or backend jobs, and use the codemod before large middleware renames.
Next.js architecture should make rendering, data access, and ownership explicit. Enterprise teams need conventions that reduce accidental client-side complexity and route-level coupling.
Route Ownership
| Area | Decision |
|---|---|
| Route group | Which product surface owns the route |
| Layout | Shared navigation, auth, and data boundaries |
| Page | Primary user task and data dependency |
| Loading and error | Expected latency and failure state |
| Metadata | Search, sharing, and compliance needs |
Server and Client Boundary
| Use server-side when | Use client-side when |
|---|---|
| Fetching secure data | Handling interactive state |
| Reading secrets or session-only context | Responding to browser events |
| Rendering mostly static or request-scoped UI | Managing rich controls or realtime updates |
| Reducing bundle size | Using browser-only APIs |
Data Access Rules
- Keep data fetching close to route or feature ownership.
- Do not pass secrets or privileged data into client components.
- Standardize error handling for expected failures.
- Use shared API clients or schemas when multiple apps consume the same backend.
- Make caching and revalidation choices visible in code review.
Next.js 16 Rules
| Area | Current guidance |
|---|---|
| Proxy | Prefer proxy.ts over middleware.ts; use it for lightweight routing, redirects, headers, and request-boundary logic |
| Proxy runtime | Proxy uses the Node.js runtime in Next.js 16 and cannot be configured with runtime |
| Caching | Enable cacheComponents and use use cache, cacheLife, and cacheTag for explicit cached pieces |
| Slow work | Keep slow data fetching out of Proxy and move it to Route Handlers, Server Actions, or backend jobs |
| Migration | Use the Next.js codemod before renaming large middleware files manually |
Review Checklist
- Is the client boundary justified?
- Can the route fail gracefully?
- Is metadata complete for important public pages?
- Are loading states stable on slow networks?
- Does the route import only allowed package layers?
- Are Proxy and caching decisions aligned with Next.js 16 behavior?