Multi-Zonen

Multi-Zonen sind ein Ansatz für Micro-Frontends, bei dem eine große Anwendung auf einer Domain in kleinere Next.js-Anwendungen unterteilt wird, die jeweils eine Reihe von Pfaden bedienen. Dies ist nützlich, wenn es Sammlungen von Seiten gibt, die nicht mit den anderen Seiten der Anwendung zusammenhängen. Durch das Verschieben dieser Seiten in eine separate Zone (d.h. eine separate Anwendung) können Sie die Größe jeder Anwendung reduzieren, was die Buildzeiten verbessert und Code entfernt, der nur für eine der Zonen erforderlich ist. Da die Anwendungen entkoppelt sind, ermöglichen Multi-Zonen anderen Anwendungen auf der Domain auch die Verwendung ihres eigenen Frameworks.

Nehmen wir beispielsweise an, Sie haben die folgenden Seiten, die Sie aufteilen möchten:

• /blog/* für alle Blogbeiträge
• /dashboard/* für alle Seiten, wenn der Benutzer im Dashboard angemeldet ist
• /* für den Rest Ihrer Website, der nicht von anderen Zonen abgedeckt wird

Mit der Unterstützung von Multi-Zonen können Sie drei Anwendungen erstellen, die alle auf derselben Domain bereitgestellt werden und für den Benutzer gleich aussehen, aber Sie können jede der Anwendungen unabhängig entwickeln und bereitstellen.

Die Navigation zwischen Seiten in derselben Zone führt zu sanften Navigationen, eine Navigation, die kein Neuladen der Seite erfordert. In diesem Diagramm bedeutet dies beispielsweise, dass die Navigation von / zu /products eine sanfte Navigation sein wird.

Die Navigation von einer Seite in einer Zone zu einer Seite in einer anderen Zone, wie von / zu /dashboard, führt zu einer harten Navigation, bei der die Ressourcen der aktuellen Seite entladen und die Ressourcen der neuen Seite geladen werden. Seiten, die häufig zusammen besucht werden, sollten in derselben Zone leben, um harte Navigationen zu vermeiden.

Wie man eine Zone definiert

Eine Zone ist eine normale Next.js-Anwendung, bei der Sie zusätzlich ein assetPrefix konfigurieren, um Konflikte mit Seiten und statischen Dateien in anderen Zonen zu vermeiden.

/** @type {import('next').NextConfig} */
const nextConfig = {
  assetPrefix: '/blog-static',
}

Next.js-Assets wie JavaScript und CSS werden mit assetPrefix versehen, um sicherzustellen, dass sie nicht mit Assets aus anderen Zonen in Konflikt geraten. Diese Assets werden für jede Zone unter /assetPrefix/_next/... bereitgestellt.

Die Standardanwendung, die alle Pfade behandelt, die nicht an eine andere spezifischere Zone weitergeleitet werden, benötigt kein assetPrefix.

In Versionen vor Next.js 15 benötigen Sie möglicherweise zusätzliche Rewrites zur Behandlung der statischen Assets. Dies ist in Next.js 15 nicht mehr erforderlich.

/** @type {import('next').NextConfig} */
const nextConfig = {
  assetPrefix: '/blog-static',
  async rewrites() {
    return {
      beforeFiles: [
        {
          source: '/blog-static/_next/:path+',
          destination: '/_next/:path+',
        },
      ],
    }
  },
}

Wie man Anfragen an die richtige Zone weiterleitet

Bei der Multi-Zonen-Einrichtung müssen Sie die Pfade an die richtige Zone weiterleiten, da sie von verschiedenen Anwendungen bedient werden. Sie können dafür einen HTTP-Proxy verwenden, aber auch eine der Next.js-Anwendungen kann verwendet werden, um Anfragen für die gesamte Domain weiterzuleiten.

Um mit einer Next.js-Anwendung an die richtige Zone weiterzuleiten, können Sie rewrites verwenden. Für jeden Pfad, der von einer anderen Zone bedient wird, fügen Sie eine Rewrite-Regel hinzu, um diesen Pfad an die Domain der anderen Zone zu senden. Zum Beispiel:

async rewrites() {
    return [
        {
            source: '/blog',
            destination: `${process.env.BLOG_DOMAIN}/blog`,
        },
        {
            source: '/blog/:path+',
            destination: `${process.env.BLOG_DOMAIN}/blog/:path+`,
        }
    ];
}

destination sollte eine URL sein, die von der Zone bedient wird, einschließlich Schema und Domain. Dies sollte auf die Produktions-Domain der Zone zeigen, kann aber auch verwendet werden, um Anfragen zu localhost in der lokalen Entwicklung weiterzuleiten.

Hinweis: URL-Pfade sollten für eine Zone eindeutig sein. Wenn zwei Zonen versuchen, /blog zu bedienen, würde dies zu einem Routing-Konflikt führen.

Weiterleiten von Anfragen mit Middleware

Das Weiterleiten von Anfragen über rewrites wird empfohlen, um die Latenzüberlagerung für die Anfragen zu minimieren. Middleware kann jedoch auch verwendet werden, wenn eine dynamische Entscheidung beim Routing erforderlich ist. Wenn Sie beispielsweise ein Feature-Flag verwenden, um zu entscheiden, wohin ein Pfad weitergeleitet werden soll, z.B. während einer Migration, können Sie Middleware verwenden.

export async function middleware(request) {
  const { pathname, search } = req.nextUrl;
  if (pathname === '/your-path' && myFeaturFlag.isEnabled()) {
    return NextResponse.rewrite(`${rewriteDomain}${pathname}${search});
  }
}

Verknüpfen zwischen Zonen

Links zu Pfaden in einer anderen Zone sollten das a-Tag anstelle der Next.js <Link>-Komponente verwenden. Dies liegt daran, dass Next.js versuchen wird, jeden relativen Pfad in der <Link>-Komponente vorab abzurufen und sanft zu navigieren, was über Zonen hinweg nicht funktionieren wird.

Code teilen

Die Next.js-Anwendungen, die die verschiedenen Zonen bilden, können in jedem Repository leben. Es ist jedoch oft praktisch, diese Zonen in einem Monorepo zu platzieren, um Code einfacher zu teilen. Für Zonen in verschiedenen Repositorys kann Code auch über öffentliche oder private NPM-Pakete geteilt werden.

Da die Seiten in verschiedenen Zonen möglicherweise zu unterschiedlichen Zeiten veröffentlicht werden, können Feature-Flags nützlich sein, um Funktionen zonenübergreifend einheitlich zu aktivieren oder zu deaktivieren.

Bei Next.js auf Vercel können Sie ein Monorepo verwenden, um alle betroffenen Zonen mit einem einzigen git push bereitzustellen.

Server-Aktionen

Bei Verwendung von Server-Aktionen mit Multi-Zonen müssen Sie den benutzerseitigen Ursprung explizit zulassen, da Ihre Benutzer-Domain möglicherweise mehrere Anwendungen bedient. Fügen Sie in Ihrer next.config.js-Datei die folgenden Zeilen hinzu:

const nextConfig = {
  experimental: {
    serverActions: {
      allowedOrigins: ['your-production-domain.com'],
    },
  },
}

Weitere Informationen finden Sie unter serverActions.allowedOrigins.