The Next.js App Router shipped in version 13 with enough fanfare that teams immediately wanted to rewrite everything. The docs were optimistic. The community was enthusiastic. And then people actually tried to build real production applications with it.
I've shipped four production apps on App Router now — a B2B SaaS dashboard with heavy data requirements, a content-heavy marketing site, an e-commerce adjacent project, and a multi-tenant internal tool. Each one taught me something the documentation doesn't cover. What follows are the patterns I reach for every time now, and the patterns I've explicitly retired.
Server Components for Data-Heavy Pages — But Not the Way You Think
The promise of Server Components is that you fetch data on the server and ship only HTML to the client. No loading spinners, no client-side data fetching, no layout shift. That promise is real, but the failure mode is subtle.
The mistake is treating Server Components as a replacement for a BFF (Backend for Frontend). They're not. If you start putting database queries directly inside Server Components — await db.query(...) inside a .tsx file — you'll eventually hit a problem: that query logic is now tightly coupled to your UI layer, and every time your data shape changes, you're editing components instead of service functions.
The pattern that actually works: Server Components own the composition and data-passing, but actual data fetching goes through a service layer — functions that live in /lib or /services and are independently testable. The Server Component calls await getProductData(id), it doesn't construct the SQL. This keeps your components clean and lets you test your data logic without spinning up a rendering environment.
Another real constraint: nested Server Components that each fetch independently will create waterfalls unless you're deliberate about parallelism. If your page layout fetches user data, and then a child component fetches permissions, and another child fetches notifications, those are sequential. The fix is to hoist all fetches to the top-level Server Component and pass data down as props — or use Promise.all to parallelize at the top level.
// Parallel fetches at the top level
const [user, permissions, notifications] = await Promise.all([
getUser(userId),
getPermissions(userId),
getNotifications(userId),
])
This is not how the docs present it. The docs imply you can colocate fetches anywhere and it'll be fine. In small apps it is. In apps with 15+ data dependencies per page, you will feel the waterfalls.
Client Components Only at the Leaves
The App Router's mental model is a tree where interactivity lives at the edges. Server Components are the trunk and branches — they handle structure, data, and static content. Client Components ("use client") are the leaves — they handle the specific interactive bits where state and browser APIs are needed.
Every time I've seen a team struggle with App Router, it's because they put "use client" too high up the tree. Once you mark a component as a Client Component, every component it imports becomes a Client Component too. The bundle grows. The SSR benefits evaporate.
The discipline is to make Client Components as small as possible. A page with a large data table and a single dropdown filter doesn't need the entire table to be a Client Component. The table renders server-side. The dropdown is a small, isolated "use client" component that receives the current filter state from the URL and pushes new params via useRouter. That's it.
A rule I've internalized: if a component doesn't use useState, useEffect, browser APIs, or event handlers, it has no business being a Client Component. Review any component marked "use client" and ask whether that directive actually needs to be there.
Route Groups for Layout Isolation
This is one of the genuinely good App Router features that teams underuse. Route groups — folders wrapped in parentheses like (marketing) or (dashboard) — let you create distinct layout trees without affecting the URL structure.
The concrete use case: your marketing pages (/, /about, /pricing) need a header with navigation and a footer. Your authenticated dashboard (/dashboard, /settings, /reports) needs a sidebar layout with no footer. Without route groups, you either write a single monolithic layout that conditionally renders different shells based on the current path, or you start hacking around with the layout system.
With route groups, you have (marketing)/layout.tsx with your marketing shell and (dashboard)/layout.tsx with your app shell. The URL /pricing and /dashboard both work correctly. The layouts are completely independent. You can update one without touching the other.
I use this pattern on every project now. The mental overhead is zero once you understand it, and the alternative — a single layout.tsx with 200 lines of conditional rendering — is miserable to maintain.
Parallel Routes for Modals That Don't Break the Back Button
Modals are a persistent UI problem. The standard approach — useState to toggle visibility — breaks navigation. If a user opens a modal, then hits the back button, they expect the modal to close. With state-based modals, the back button takes them to the previous page instead.
App Router's parallel routes solve this properly. You define an @modal slot in your layout, create an intercepting route, and the modal content renders as a separate route while the background page stays mounted.
The implementation is more involved than a simple useState modal, but the UX is significantly better — the modal has its own URL, back button works as expected, and you can link directly to the modal state. For any modal that represents meaningful content (a product detail overlay, a user profile drawer, a document preview), this is the right pattern.
For simple confirmations and alerts that don't need URL state, I still use a headless UI dialog component with useState. Parallel routes for everything is over-engineering. Parallel routes for content-bearing modals is the right call.
Loading Boundaries That Actually Help Users
loading.tsx is App Router's mechanism for streaming UI — you export a skeleton component and Next.js shows it while the Server Component above it is fetching. The docs make this sound straightforward. In practice, poorly designed loading states are worse than a single spinner.
The failure mode: a loading skeleton that's structurally wrong. If your loaded content has a sidebar and a main column, your skeleton should have a sidebar and a main column. If your loaded content has a table with 10 rows, your skeleton should show table rows. A generic gray rectangle where rich content will appear is disorienting — users see the content jump from skeleton to real layout and it feels broken even when it technically isn't.
The pattern I follow: build the loading skeleton after the real component is finished, not before. Once I know exactly what the rendered output looks like — its grid structure, approximate heights, number of elements — I build the skeleton to match it precisely. That takes maybe 30 extra minutes and the result is a loading state that feels intentional rather than bolted on.
One more thing: don't put loading.tsx at the page level if your page has multiple independent data sections. Use <Suspense> boundaries within the page itself to stream sections independently. Users see the fast content first, the slow content streams in. Page-level loading blocks everything equally, which is usually not what you want.
What I've Stopped Using
A few patterns I tried and retired:
Client-side data fetching with SWR or React Query inside App Router pages. For data that exists at render time, Server Components do this better. SWR still has a place for real-time or user-triggered data updates, but as a primary data fetching strategy inside App Router it's redundant.
Custom fetch wrappers that try to handle both server and client contexts. The mental gymnastics required to write a fetch function that works in both environments without diverging behavior aren't worth it. Separate your server fetching functions from your client fetching hooks. The duplication is minor. The clarity is significant.
useSearchParams without a <Suspense> boundary. This causes build errors in production that don't show up in local dev. Every component that calls useSearchParams needs to be wrapped in <Suspense>. I have this in my project checklist now.
App Router is genuinely good. But it rewards teams that understand the constraints — the component tree model, the data flow direction, the rendering boundaries. Ignore those and you'll fight the framework on every feature. Work with them and it's the most coherent React architecture I've used.