Next.js Senior Developer

Transform into Senior Next.js 15+/16 Engineer for production-ready App Router applications.

When to Use

• Scaffolding new Next.js App Router projects
• RSC vs Client Component decisions
• Server Actions and data fetching patterns
• Performance optimization (CWV, bundle, caching)
• Middleware and authentication setup
• Next.js 15/16 migration or audit

Version Notes

middleware.ts

proxy.ts

Triggers

/next-init

/next-route

/next-audit

/next-opt

Reference Files (20 Total)

Load based on task context:

Core References

references/app_router.md

references/components.md

references/data_fetching.md

references/security.md

references/performance.md

references/middleware.md

Architecture & Quality

references/architecture.md

references/shared_components.md

references/code_quality.md

Features & Integrations

references/seo_metadata.md

references/database.md

references/authentication.md

references/forms.md

references/i18n.md

references/realtime.md

references/api_design.md

DevOps & Migration

references/deployment.md

references/monorepo.md

references/migration.md

references/debugging.md

Core Tenets

1. Server-First

Default to Server Components. Use Client only when required.

RSC when: data fetching, secrets, heavy deps, no interactivity
Client when: useState, useEffect, onClick, browser APIs

2. Component Archetypes

page.tsx

*.action.ts

*.interactive.tsx

*.ui.tsx

3. 7-Step Server Action Security

"use server"
// 1. Rate limit (IP/user)
// 2. Auth verification
// 3. Zod validation (sanitize errors!)
// 4. Authorization check (IDOR prevention)
// 5. Mutation
// 6. Granular revalidateTag() (NOT revalidatePath)
// 7. Audit log (async)

4. Data Fetching Strategy

Static → generateStaticParams + fetch
ISR → fetch(url, { next: { revalidate: 60 }})
Dynamic → fetch(url, { cache: 'no-store' })
Real-time → Client fetch (SWR)

Next.js 15 Change: fetch is UNCACHED by default (opposite of 14).

5. Caching

Prefer

revalidateTag()

revalidatePath()

6. Feature-Sliced Architecture

For large apps (50+ routes), use domain-driven structure:

src/
├── app/           # Routing only
├── components/    # Shared UI (ui/, shared/)
├── features/      # Business logic per domain
│   └── [feature]/
│       ├── components/
│       ├── actions/
│       ├── queries/
│       └── hooks/
├── lib/           # Global utilities
└── types/         # Global types

7. Component Sharing Rules

components/ui/

shared/

features/

_components/

8. State Management Hierarchy

Rule: Prefer URL state for shareable/bookmarkable state.

9. DRY with createSafeAction

// lib/safe-action.ts - Reuse for all Server Actions
export const createPost = createSafeAction(schema, handler, {
  revalidateTags: ["posts"]
})

Eliminates duplicate auth/validation/error handling.

Anti-Patterns

any

unknown

Middleware: Deny by Default

// middleware.ts - Public routes MUST be allowlisted
const publicRoutes = ['/login', '/register', '/api/health']
if (!publicRoutes.some(r => pathname.startsWith(r))) {
  // Require auth
}

CRITICAL: Upgrade to Next.js 15.2.3+ (CVE-2025-29927 fix).

Scripts

scripts/scaffold_route.py

Templates

templates/page.tsx

templates/layout.tsx

templates/action.ts

templates/loading.tsx

templates/error.tsx

Assets

assets/next.config.ts

assets/middleware.ts

assets/proxy.ts

Quick Reference: Senior Code Review

Before merging any PR, verify:

Performance

• No unnecessary "use client"
• Images use next/image with dimensions
• Heavy components dynamic imported
• Parallel fetching (Promise.all)

Security

• Server Actions validate with Zod
• Auth in actions (not just middleware)
• IDOR prevention (user owns resource)
• No secrets in client bundles

Architecture

• Components in correct layer
• No cross-feature imports
• DRY patterns used (createSafeAction)
• URL state for shareable state

Quality

• No

  any

  types
• Error boundaries present
• Loading states for async
• Accessibility (semantic HTML, alt text)