Next.js Patterns
Use App Router, server boundaries, data fetching, and route ownership consistently.
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.
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?