Scaling Frontend Teams: Next.js Multi-Zones 🧩

The Monolithic Frontend Bottleneck

In the early days of a product, a single monolithic Next.js repository is a beautiful thing. It’s easy to navigate, easy to deploy, and state flows freely. However, as an enterprise scales, the frontend team grows from 3 developers to 50 developers spread across distinct squads: the Marketing Team, the Core Dashboard Team, and the Billing/Checkout Team.

When 50 engineers constantly push code to a single Next.js application, chaos ensues. Git merge conflicts become a daily blockade. CI/CD build times skyrocket from 2 minutes to 25 minutes. A critical bug deployed by the Marketing team accidentally takes down the Checkout flow. The monolith has become a massive bottleneck, severely restricting the organization's deployment velocity.

At Smart Tech Devs, we break this bottleneck by implementing Micro-Frontends. Specifically, we utilize Next.js’s native architectural feature: Multi-Zones. This allows us to split a massive web application into entirely separate Next.js projects that are developed, built, and deployed independently, yet appear to the end-user as a single, cohesive, instantaneous website.

Multi-Zones vs. Module Federation

While Webpack Module Federation is a popular way to build micro-frontends by injecting components at runtime, it is incredibly complex to configure correctly with Next.js Server-Side Rendering (SSR) and the App Router. Next.js Multi-Zones offers a vastly superior, URL-routing based approach.

With Multi-Zones, you deploy multiple independent Next.js apps. You then place a single Gateway (or reverse proxy) in front of them that seamlessly routes traffic based on the URL path. /about goes to the Marketing App, while /dashboard goes to the App Router Dashboard.

Phase 1: Architecting the Sub-Applications

Let's architect a system with a main marketing-app and a separate dashboard-app. First, the dashboard-app team must configure their application to understand that it does not own the root domain. It only owns the /dashboard path.

// dashboard-app/next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  // This is critical: It tells Next.js that all its internal 
  // assets (_next/static...) must be prefixed with /dashboard
  basePath: '/dashboard',
  
  // Optional: If you are using cross-zone API calls
  async headers() {
      return [
          {
              source: "/api/:path*",
              headers: [
                  { key: "Access-Control-Allow-Origin", value: "*" },
              ]
          }
      ]
  }
}

module.exports = nextConfig

Phase 2: Configuring the Main Zone (Gateway)

The marketing-app will serve as our primary entry point. It will handle the homepage, the pricing page, and act as the routing gateway. We configure its next.config.js to utilize Rewrites.

When a user requests /dashboard, the Marketing App transparently fetches the HTML from the heavily scaled Dashboard App's URL without changing the browser's URL bar.

// marketing-app/next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  async rewrites() {
    return [
      // If the URL starts with /dashboard, seamlessly proxy the request 
      // to the independently deployed Dashboard Application.
      {
        source: '/dashboard',
        destination: 'https://dashboard-app.production.com/dashboard',
      },
      {
        source: '/dashboard/:path*',
        destination: 'https://dashboard-app.production.com/dashboard/:path*',
      },
    ]
  },
}

module.exports = nextConfig

Phase 3: Seamless Navigation Between Zones

The magic of Multi-Zones is that to the user, the transition is invisible. However, as developers, we must handle linking correctly. If you are in the Marketing app and want to link to the Dashboard, you cannot use the Next.js <Link> component, because the Dashboard is a completely different Next.js instance; the router doesn't know about it.

Instead, we use a standard HTML <a> tag for cross-zone navigation.

// marketing-app/app/page.tsx
export default function Home() {
  return (
    <main className="flex flex-col items-center p-24">
      <h1 className="text-5xl font-bold">Smart Tech Solutions</h1>
      
      {/* Internal Zone Link: Uses standard Next.js Link for instant SPA routing */}
      <Link href="/pricing" className="mt-4">View Pricing</Link>

      {/* Cross-Zone Link: Uses standard anchor tag to trigger a hard navigation to the Dashboard app */}
      <a href="/dashboard" className="mt-8 px-6 py-3 bg-blue-600 text-white rounded-lg">
        Go to Dashboard
      </a>
    </main>
  )
}

Handling Shared State (Authentication)

The biggest challenge in Micro-Frontends is shared state, specifically authentication. Because the applications are hosted on different underlying URLs (behind the proxy), React Context or LocalStorage will not be shared.

The enterprise solution is to rely exclusively on HTTP-Only Cookies set at the root domain level. When the user logs in via the Marketing App, the backend sets a cookie for .smarttechdevs.in. Because both zones share the same top-level domain in the browser, the browser will automatically attach the authentication cookie to requests sent to both the Marketing zone and the Dashboard zone. Each zone can then independently verify the JWT at the edge using Next.js Middleware.

The Engineering ROI

Implementing Next.js Multi-Zones radically transforms enterprise frontend engineering. It completely decouples your engineering squads. The Dashboard team can deploy 10 times a day without ever worrying about breaking the Marketing site. The Checkout team can upgrade their Next.js version independently. CI/CD pipelines run in seconds because they are only building a fraction of the application. Yet, despite this massive architectural separation on the backend, the end-user experiences a perfectly unified, lightning-fast application, proving that true scalability is as much about scaling teams as it is about scaling servers.