Skip to content

Next HOME

Table of Contents

Getting Started

Data & Rendering

Security

Deployment & Advanced

Next.js went from "that React framework for static sites" to a full-stack monster that eats Express's lunch

You can build your entire application - frontend , backend , API , auth , database queries - inside a single Next.js project. That's powerful. That's also terrifying because when every layer is in one codebase , one misconfigured middleware or leaked environment variable compromises every layer at once. Deal with it

what Next.js is

Next.js is a React framework that adds server-side rendering , static generation , API routes , and file-based routing on top of React

React is a UI library - it runs in the browser and has no opinion about servers. Next.js wraps React and gives you: * Server Components that run on the server and never ship to the client * Route handlers for building APIs without a separate backend * Middleware that runs at the edge for auth , redirects , and headers * Build-time and runtime rendering strategies you can pick per page

The boundary between frontend and backend doesn't exist anymore. That's the point and the danger

App Router vs Pages Router

Two routing systems exist in Next.js and you need to know which one you're looking at

App Router (current - since Next.js 13): 

app/
  page.js          -> /
  layout.js        -> shared layout
  api/route.js     -> /api endpoint
  blog/[id]/page.js -> /blog/123

Pages Router (legacy - still supported): 

pages/
  index.js         -> /
  api/hello.js     -> /api/hello
  blog/[id].js     -> /blog/123

Everything in this curriculum uses App Router because that's where all development is happening in 2026 Pages Router is maintenance mode. Don't start new projects with it. If you're maintaining a legacy project , migrate when you can

SSR , SSG , ISR - the holy trinity

Next.js doesn't force one rendering strategy. You pick per page or per component

  • SSR (Server-Side Rendering) - generates HTML on every request. Fresh data , higher latency
  • SSG (Static Site Generation) - generates HTML at build time. Blazing fast , stale data
  • ISR (Incremental Static Regeneration) - generates HTML at build time , revalidates in background. Best of both worlds
  • CSR (Client-Side Rendering) - ships an empty shell , React fills it in the browser. SEO nightmare

You can mix these in the same app. A marketing page can be SSG. A dashboard can be SSR. A blog post can be ISR with on-demand revalidation. The rendering strategy is a configuration decision , not an architectural one

security posture at a glance

Next.js is more secure than plain React because more runs on the server. But "more secure" doesn't mean "secure"

  • Server Components - data fetching happens server-side , never reaches the client bundle. But pass one object to a Client Component wrong and your secrets are in devtools
  • Server Actions - built-in CSRF protection , but mutation validation is on you. No built-in rate limiting
  • Middleware - runs at the edge before the request hits your route. But edge runtime can't access the filesystem or do heavy computation
  • Route handlers - no built-in CSRF. If you're using cookie auth with route handlers , SameSite is your only defense

The attack surface checklist:

  • NEXT_PUBLIC_ prefix - anything with this goes to the client bundle. API keys , database URLs , secrets - keep them server-side only
  • Client Component imports - importing server-only code in a Client Component ships it to the browser
  • Middleware matcher - wrong matcher config means your auth middleware skips entire route groups
  • Server Action validation - no built-in validation framework. You write the validation or you get pwned
  • Bundle leaks - environment variables referenced in client code get inlined at build time

prerequisites

React basics - know what components , props , and hooks are If you've never written a React component go do that first

next → next_01_intro.md