Next.js App Router at Scale: Patterns We Use at MetadevX

Structure Is the Real Scaling Problem

Once an App Router project passes a few hundred routes, the performance questions answer themselves and the organisational ones start hurting. What keeps a codebase maintainable is a predictable folder contract and a clear rule for where data is fetched.

Patterns We Reach For

These four decisions account for most of the clarity we have gained, and every one of them is cheap to adopt on an existing project.

• Server Components by default, with client boundaries pushed to the leaves
• Route groups for product areas instead of a flat app/ directory
• One data-access module per domain, never fetch calls scattered in components
• Suspense boundaries sized to the slowest meaningful section, not the page
• Parallel routes for chrome-like slots such as filters and side panels

Pitfalls We Keep Hitting

The same handful of mistakes shows up in every review, usually because they feel faster in the moment they are written.

• Marking a whole tree "use client" to share one interactive component
• Re-fetching in a Client Component what the Server Component already had
• Leaving dynamic APIs in shared layouts so every route opts out of caching
• Using searchParams for state that should live in the URL only when shared
• Shipping large charts inside the initial payload instead of streaming them