Micro-Frontends mit Multi-Zones und Next.js erstellen
Beispiele
Multi-Zones sind ein Ansatz für Micro-Frontends, bei dem eine große Anwendung auf einer Domain in kleinere Next.js-Anwendungen aufgeteilt wird, die jeweils einen Satz von Pfaden bedienen. Dies ist nützlich, wenn es Sammlungen von Seiten gibt, die nicht mit den anderen Seiten der Anwendung verbunden sind. 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 Build-Zeiten verbessert und Code entfernt, der nur für eine der Zonen notwendig ist. Da die Anwendungen entkoppelt sind, ermöglichen Multi-Zones auch, dass andere Anwendungen auf der Domain ihr eigenes Framework verwenden können.
Nehmen wir zum Beispiel an, Sie haben folgende 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 Multi-Zones 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 Soft Navigations, einer Navigation, die kein Neuladen der Seite erfordert. In diesem Diagramm würde beispielsweise die Navigation von /
zu /products
eine Soft Navigation sein.
Die Navigation von einer Seite in einer Zone zu einer Seite in einer anderen Zone, wie von /
zu /dashboard
, führt zu einer Hard 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 liegen, um Hard Navigations zu vermeiden.
Wie eine Zone definiert wird
Eine Zone ist eine normale Next.js-Anwendung, in der Sie auch einen assetPrefix konfigurieren, um Konflikte mit Seiten und statischen Dateien in anderen Zonen zu vermeiden.
Next.js-Assets wie JavaScript und CSS werden mit assetPrefix
versehen, um sicherzustellen, dass sie nicht mit Assets aus anderen Zonen kollidieren. Diese Assets werden unter /assetPrefix/_next/...
für jede der Zonen bereitgestellt.
Die Standardanwendung, die alle Pfade behandelt, die nicht einer spezifischeren Zone zugeordnet sind, benötigt keinen assetPrefix
.
In Versionen älter als Next.js 15 benötigen Sie möglicherweise zusätzlich ein Rewrite, um die statischen Assets zu handhaben. Dies ist in Next.js 15 nicht mehr notwendig.
Wie Anfragen an die richtige Zone geroutet werden
Mit dem Multi-Zones-Setup müssen Sie die Pfade an die richtige Zone routen, da sie von verschiedenen Anwendungen bereitgestellt werden. Sie können jeden HTTP-Proxy dafür verwenden, aber eine der Next.js-Anwendungen kann auch verwendet werden, um Anfragen für die gesamte Domain zu routen.
Um Anfragen mit einer Next.js-Anwendung an die richtige Zone zu routen, 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, und Sie müssen auch die Anfragen für die statischen Assets umschreiben. Zum Beispiel:
destination
sollte eine URL sein, die von der Zone bereitgestellt wird, einschließlich Schema und Domain. Dies sollte auf die Produktionsdomain der Zone verweisen, kann aber auch verwendet werden, um Anfragen in der lokalen Entwicklung auf localhost
zu routen.
Gut zu wissen: URL-Pfade sollten für eine Zone eindeutig sein. Beispielsweise würden zwei Zonen, die
/blog
bedienen wollen, einen Routing-Konflikt verursachen.
Anfragen mit Middleware routen
Das Routen von Anfragen über rewrites
wird empfohlen, um die Latenz für die Anfragen zu minimieren, aber Middleware kann auch verwendet werden, wenn eine dynamische Entscheidung beim Routen notwendig ist. Zum Beispiel, wenn Sie ein Feature-Flag verwenden, um zu entscheiden, wohin ein Pfad geroutet werden soll, wie während einer Migration, können Sie Middleware verwenden.
Verlinkung zwischen Zonen
Links zu Pfaden in einer anderen Zone sollten ein a
-Tag anstelle der Next.js <Link>
-Komponente verwenden. Dies liegt daran, dass Next.js versucht, jeden relativen Pfad in der <Link>
-Komponente vorabzuladen und mit einer Soft Navigation aufzurufen, was über Zonen hinweg nicht funktioniert.
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 teilen zu können. Für Zonen, die in verschiedenen Repositories leben, kann Code auch über öffentliche oder private NPM-Pakete geteilt werden.
Da die Seiten in verschiedenen Zonen zu unterschiedlichen Zeiten veröffentlicht werden können, können Feature-Flags nützlich sein, um Funktionen über die verschiedenen Zonen hinweg einheitlich zu aktivieren oder zu deaktivieren.
Server Actions
Bei der Verwendung von Server Actions mit Multi-Zones müssen Sie die benutzerorientierte Origin explizit erlauben, da Ihre benutzerorientierte Domain mehrere Anwendungen bedienen kann. Fügen Sie in Ihrer next.config.js
-Datei die folgenden Zeilen hinzu:
Weitere Informationen finden Sie unter serverActions.allowedOrigins
.