After shipping 10 production projects on Next.js 14's App Router, we've accumulated a set of lessons that we wish someone had told us before we started. This post covers the most impactful ones.
Server Components vs Client Components
The biggest mental shift is understanding when to use "use client". The rule is simple: if a component uses browser APIs, React hooks (useState, useEffect, etc.), or event handlers, it needs to be a Client Component. Everything else should stay as a Server Component.
The mistake most teams make is reaching for "use client" at the page level out of habit. This defeats the purpose of the App Router entirely. Instead, push "use client" as far down the component tree as possible — ideally to small, isolated interactive leaves.
ISR Cache Invalidation
Incremental Static Regeneration in the App Router works differently from Pages Router. The revalidate export now sits at the route segment level. For on-demand revalidation, use Route Handlers with revalidatePath or revalidateTag. We use tags extensively — tag every fetch with a content type, then invalidate all posts in one call when a new article is published.
Parallel Routes and Error Boundaries
Parallel routes are powerful for dashboards but easy to overcomplicate. We use them sparingly — primarily for modal patterns where we need independent loading states for two sections of the same page.
Error boundaries in the App Router are file-based. Put an error.tsx at the right level of your route tree. Don't put it too high — a top-level error boundary that catches everything gives users no context about what went wrong.
Data Fetching Patterns
Avoid waterfall fetches. If a page needs data from three sources, fetch them in parallel using Promise.all. Use the cache function for request deduplication within a render pass.
Conclusion
The App Router is genuinely excellent once you internalise the mental model. The friction mostly comes from trying to apply Pages Router patterns to a fundamentally different architecture. Invest time upfront understanding Server Components and the request lifecycle — it pays off on every project.