Next.js App Router Routing Is Just Files in the Right Folders
Convention-based routing eliminates an entire category of boilerplate—no route tables, no separate API server, no manual wiring between layouts and pages. But the trade-off is that the directory structure is the source of truth, so dynamic segments like `/post/:id` require a different mechanism, and the server/client boundary demands careful placement of data-fetching logic to avoid empty first paints.
A Next.js project with zero route configuration still serves pages at `/`, `/about`, `/dashboard`, and `/api/todos`. The secret is that `app/` directory structure maps directly to URLs: `page.tsx` becomes a page, `layout.tsx` wraps child routes in a shared shell, and `route.ts` under `api/` exposes HTTP endpoints. All three roles are determined by filename and location, not by a central router declaration.
The `'use client'` directive marks a component for hydration—it still renders on the server first, then ships JavaScript to the browser to activate interactivity. This means a `useEffect` data fetch won't populate the initial HTML; the first paint shows an empty state until hydration completes. Three common beginner mistakes surface in the demo code: a POST handler that never updates local state, a delete button with no click handler, and leftover `console.log` calls.
Convention-based routing shifts the developer's mental model from "configuring a router" to "organizing a filesystem," which makes project structure immediately legible but also locks URL design to directory layout.
The `'use client'` boundary is widely misunderstood as a browser-only marker; in practice it creates a dual-render lifecycle where the server produces static HTML and the browser later hydrates it, making initial data-fetching strategy critical.
Next.js blurs the frontend-backend line by letting `route.ts` files live in the same project tree as pages, which removes CORS and deployment overhead but also tempts developers to put business logic directly in route handlers.