- Microfrontends wenden Microservice-Prinzipien auf die Browser-Benutzeroberfläche an und zerlegen große Frontends in autonome, domänenorientierte Bereiche, die von funktionsübergreifenden Teams betreut werden.
- Die Integration basiert auf dem DOM, Custom Elements, Module Federation und einer Anwendungsshell, die Routing, Sicherheit, Komposition und gemeinsam genutzte Bibliotheken orchestriert.
- Frameworks wie React, Angular und Next.js ermöglichen zusammen mit Mustern wie BFF, Event-Bussen und Lazy Loading skalierbare, robuste und beobachtbare Microfrontend-Systeme.
- Microfrontends erhöhen zwar die architektonische Komplexität, zahlen sich aber bei großen, teamübergreifenden Produkten aus, bei denen unabhängige Bereitstellung, schrittweise Migration und differenzierte Skalierung entscheidend sind.
Microfrontends haben sich zu einem der meistdiskutierten Frontend-Architekturmuster entwickelt. Für Teams, die dem klassischen Single-Page-Monolithen entwachsen sind. Wenn Dutzende Entwickler an derselben Codebasis arbeiten, verlangsamen sich Release-Zyklen, Regressionen schleichen sich überall ein und kleine UI-Änderungen erfordern plötzlich massive Koordination. Microfrontends lösen genau dieses Problem, indem sie die Benutzeroberfläche in unabhängig voneinander erstellte und bereitgestellte Komponenten aufteilen.
In diesem Leitfaden erklären wir, was Microfrontends sind, warum sie entstanden sind und wie sie mit Microservices zusammenhängen.Wir werden die Kernideen betrachten, die Sie beim Design berücksichtigen sollten, und wie diese in der Praxis mit Technologien wie React, Angular, Next.js, Web Components, Webpack Module Federation und Single-SPA funktionieren. Außerdem werden wir uns mit realen Architekturmustern, Best Practices, häufigen Fehlern und konkreten Beispielen wie einem als separate Microfrontends implementierten Produktkatalog und Warenkorb befassen.
Was sind Microfrontends und warum sind sie entstanden?
Der Begriff „Mikro-Frontends“ wurde um 2016 im ThoughtWorks Technology Radar populär. Als Antwort auf einen ganz konkreten Trend: Backend-Architekturen entwickelten sich hin zu Microservices, während die Browserseite ein großer, fehleranfälliger Monolith blieb, der von einem einzigen Team betreut wurde. Mit der Zeit wird die Weiterentwicklung dieser „Fat Client“-SPA immer schwieriger, selbst wenn das Backend in kleine Services aufgeteilt ist.
Ein Microfrontend ist im Wesentlichen das Microservice-Konzept, angewendet auf die Browser-Benutzeroberfläche.Anstelle eines großen Frontend-Repositorys wird die Benutzeroberfläche aus mehreren kleineren, in sich abgeschlossenen Anwendungen zusammengesetzt. Jede Anwendung hat einen klar definierten Geschäftsbereich (z. B. „Kasse“, „Produktsuche“, „Studentenprofile“) und kann unabhängig entwickelt, getestet und bereitgestellt werden.
Genau wie Microservices die Backend-Logik in separate, bereitstellbare Einheiten aufteilen, unterteilen Microfrontends das Frontend in vertikale Segmente. Diese Bereiche erstrecken sich von der Datenbank bzw. den APIs über das Backend bis hin zur Benutzeroberfläche. Ein funktionsübergreifendes Team verantwortet diesen vertikalen Abschnitt von Anfang bis Ende, vom Datenschema bis zu den UI-Komponenten.
Diese „vertikale Organisation“ steht im Gegensatz zu einer horizontalen Aufteilung in Schichten. (Ein Team für die Benutzeroberfläche, ein anderes für die APIs, ein weiteres für die Datenbank). Vertikale Teams arbeiten tendenziell schneller, da sie nicht jede kleine Änderung im halben Unternehmen koordinieren müssen.
Aus Anwendungssicht ist ein Microfrontend eine autonome Webanwendung. Das kann zu einem umfassenderen Erlebnis zusammengestellt werden: Es kann über ein eigenes Routing, Zustandsmanagement, Designsystem und eine eigene Bereitstellungspipeline verfügen, solange es eine Reihe von Verträgen mit dem Rest des Systems (URLs, Ereignisse, APIs, gemeinsam genutzte Bibliotheken usw.) einhält.
Kernideen und Prinzipien hinter Microfrontends
In erfolgreichen Microfrontend-Architekturen zeigen sich mehrere wiederkehrende Prinzipien.Es handelt sich zwar nicht um strenge Regeln, aber sie werden Ihnen viel Ärger ersparen, wenn Sie sie als Leitplanken verwenden.
Technologieagnostik Eines der bekanntesten Prinzipien lautet: Jedes Team sollte seinen Technologie-Stack frei wählen und aktualisieren können, ohne sich mit den anderen abstimmen zu müssen. So könnte beispielsweise ein Microfrontend auf React, ein anderes auf Angular und ein älteres auf Vue basieren. Browser-native Abstraktionen wie Custom Elements (Web Components) helfen, diese Unterschiede hinter einer standardisierten DOM-API zu verbergen.
Eine starke Isolation der Codebasen der Teams ist ein weiteres wichtiges Ziel.Idealerweise teilen sich Microfrontends weder eine JavaScript-Laufzeitumgebung noch globale Variablen. Jedes Bundle ist in sich abgeschlossen, lädt seine eigenen Abhängigkeiten und greift nicht auf versteckte Zustände anderer Bundles zu. Dadurch werden unbeabsichtigte Kopplungen reduziert und unabhängige Bereitstellungen deutlich realistischer.
Um Namenskonflikte zu vermeiden, einigen sich Teams häufig auf explizite Namensräume. für CSS-Klassen, DOM-Ereignisse, localStorage-Schlüssel, Cookies oder sogar Namen von benutzerdefinierten Elementen. Beispielsweise könnte ein Checkout-Team Einträge mit einem Präfix versehen. chk- oder verwenden Sie ein Tag wie <blue-buy>, während ein Empfehlungsteam verwendet rec- or <green-recos>Auf einen Blick verrät Ihnen das DOM, wem welches Stück gehört.
Ein weiteres Prinzip ist, den nativen Browserfunktionen den Vorzug vor benutzerdefinierten globalen APIs zu geben.Anstatt ein universelles PubSub-System zu entwickeln, können Sie auf Standard-DOM-Ereignisse zurückgreifen. CustomEventDie History-API dient entweder für das Routing oder das DOM selbst als Integrationsschicht. Wann immer Sie eine gemeinsam genutzte API benötigen, halten Sie diese so klein und stabil wie möglich.
Schließlich sollte Resilienz von Anfang an Teil des Designs sein.Jedes Microfrontend sollte auch dann noch einen Mehrwert bieten, wenn JavaScript langsam ist, ausfällt oder blockiert ist. Techniken wie serverseitiges Rendering, progressive Verbesserung und Skeleton Screens tragen dazu bei, die wahrgenommene Leistung auch unter schlechten Netzwerkbedingungen hoch zu halten.
Was ist in diesem Zusammenhang eine „moderne Webanwendung“?
Nicht jede Website benötigt Microfrontends oder eine komplexe Browserintegrationsstrategie.Ein gutes mentales Modell ergibt sich aus dem „Dokument-zu-Anwendungs-Kontinuum“: Links befinden sich meist statische, miteinander verknüpfte Dokumente; rechts befinden sich vollständig interaktive Anwendungen wie ein Online-Fotoeditor.
Wenn Ihr Projekt eher statischen Dokumenten ähnelt, genügt oft eine einfache serverseitig gerenderte Darstellung.Der Server sammelt HTML-Fragmente aus verschiedenen Quellen, fügt sie zusammen und sendet sie an den Browser. Aktualisierungen erfolgen entweder durch vollständige Seitenaufrufe oder durch kleine Ajax-Anfragen – und das ist völlig in Ordnung.
Wenn Sie sich dynamischeren, app-ähnlichen Erlebnissen zuwenden– Sofortiges Feedback, Offline-Funktionalität, optimistische UI-Aktualisierungen – reine serverseitige Integration reicht nicht mehr aus. Sie benötigen clientseitige Komposition, Zustandsverwaltung und Routing. Hier kommen Microfrontends ins Spiel: Sie ermöglichen es, diese Komplexität teamübergreifend zu skalieren.
Vertikale Organisation und domänengesteuerte Segmente
Eine gängige Empfehlung ist, Microfrontends eher an Geschäftsdomänen als an technischen Schichten auszurichten.Denken Sie in Bezug auf Benutzerabläufe: „Warenkorb“, „Produktdetails“, „Administratoren“, „Kurspläne“, „Studentendatensätze“, „Rechnungen“ usw.
Jede dieser Domänen kann zu einem eigenen Microfrontend mit einer klar definierten Verantwortung werden.In einem Universitätssystem könnte eine App die Studierendenprofile, eine andere die Mitarbeiterprofile, eine dritte die Stundenpläne und eine weitere die Benutzeroberfläche für die Prüfungsergebnisse verwalten. Sie teilen sich zwar eine Grundstruktur und gegebenenfalls einige Designelemente, sind aber aus Sicht der Bereitstellung jeweils eigenständige Anwendungen.
Gutes Slicing berücksichtigt auch die abgegrenzten Kontexte Ihrer Backend-Microservices.Idealerweise kommuniziert das Microfrontend für die Abrechnung hauptsächlich mit den Abrechnungs-Microservices, das Frontend für den Katalog mit den Katalog-Services usw. Dadurch bleiben die einzelnen Bereiche in sich geschlossen und teamübergreifende Abhängigkeiten werden reduziert.
Technische Integration: DOM als API und Web Components
In browserseitigen Microfrontend-Architekturen fungiert das DOM selbst häufig als primäre Integrations-API.Anstatt den JavaScript-Code des jeweils anderen Teams direkt aufzurufen, stellen die Teams die Funktionalität über HTML-Elemente, Attribute und Ereignisse bereit.
Benutzerdefinierte Elemente (Teil der Webkomponenten) sind ein leistungsstarkes Grundelement dafür.Ein Team kann eine Funktion mit einem beliebigen Framework erstellen und sie dann beispielsweise als benutzerdefiniertes Tag einbinden. <order-minicart></order-minicart>Der öffentliche Vertrag dieser Komponente wird durch ihren Tag-Namen, ihre Attribute und die ausgelösten Ereignisse definiert, nicht durch ihre interne Implementierung.
Die Browserunterstützung für Custom Elements v1 ist nun in allen gängigen Browsern vollständig gewährleistet.Das bedeutet, dass Sie selten Polyfills benötigen. Die meisten gängigen Frameworks – React, Vue, Angular, Svelte, Preact – können benutzerdefinierte Elemente wie reguläre HTML-Tags rendern oder einbetten, und viele von ihnen können auch selbst zu einem benutzerdefinierten Element kompiliert werden.
Das Integrationsmuster sieht in etwa so aus:Ein Microfrontend für eine „Produktseite“ legt fest, welche Elemente auf der Seite angezeigt werden (Auswahlfilter, Kaufbuttons, Mini-Warenkorb, Empfehlungen). Es fügt benutzerdefinierte Elemente wie beispielsweise … ein. <blue-buy sku="t_porsche"></blue-buy> or <green-recos sku="t_porsche"></green-recos>Die Teams, denen diese Funktionen gehören, registrieren ihre Elemente bei customElements.define und implementieren Sie Lebenszyklus-Callbacks wie connectedCallback or attributeChangedCallback.
Wenn sich eine Produktvariante ändert, kann die Seite das Element entweder neu erstellen oder nur dessen Attribute aktualisieren.Wenn die Komponente relevante Attribute erkennt, kann sie sich neu rendern. Intern kann die Komponente Template-Strings, React, Vue oder eine beliebige Rendering-Engine verwenden; der Integrator muss sich darum nicht kümmern.
Clientseitige Kommunikation: Ereignisse und DOM-Beziehungen
Die Übergabe von Attributen eignet sich gut für unidirektionale „Daten rein“-Szenarien.Viele reale Interaktionen erfordern jedoch, dass Komponenten mit ihrer Umgebung oder anderen Komponenten kommunizieren. Ein typisches Beispiel ist ein „Kaufen“-Button, der den Warenkorb benachrichtigen muss, sobald ein Artikel hinzugefügt wird.
Anstatt einen benutzerdefinierten globalen Ereignisbus zu erstellen, können Sie auf Browserereignisse zurückgreifen.Komponentenversand CustomEvent Instanzen, die im DOM-Baum nach oben wandern. Ein übergeordnetes Element oder sogar window können diese Ereignisse abfangen und entsprechende Reaktionen koordinieren.
Beispielsweise könnte die Schaltfläche „Kaufen“ ein Ereignis auslösen wie: blue:basket:changed mit der aktuellen WagenlastDer Mini-Warenkorb abonniert dieses Ereignis am window oder auf einem gemeinsam genutzten Containerelement und aktualisiert dessen internen Zustand bei jedem Auslösen.
Dieser Ansatz gewährleistet die Unabhängigkeit der Komponenten.Der Kaufbutton weiß nicht, wer – falls überhaupt jemand – auf seine Ereignisse reagiert. Er erfüllt einfach seinen Auftrag. Und der Mini-Warenkorb hängt ausschließlich von der Ereignissemantik ab, nicht von den Implementierungsdetails anderer Fragmente.
Serverseitiges Rendering und universelle Komponenten
Wenn Ihnen die Ladezeit beim ersten Seitenaufruf, SEO oder die Ausfallsicherheit bei JavaScript-Fehlern wichtig sind, ist serverseitiges Rendering (SSR) unerlässlich.Reine clientseitige Webkomponenten werden erst nach dem Herunterladen und Ausführen des JS-Bundles angezeigt, was bei langsamen Netzwerken zu einem weißen Bildschirm führen kann.
Eine pragmatische Lösung besteht darin, Custom Elements mit serverseitigen Includes (SSI/ESI) zu kombinieren.Jedes Microfrontend stellt einen HTTP-Endpunkt bereit, der das HTML für sein Fragment zurückgibt, zum Beispiel /blue-buy?sku=t_porscheDie Hauptseite, die von einer Shell oder Host-Anwendung gerendert wird, enthält Platzhalter wie <!--#include virtual="/blue-buy?sku=t_porsche" --> die der Webserver (oft nginx) expandiert, bevor er die Antwort an den Browser sendet.
Zur Laufzeit im Browser wird dasselbe benutzerdefinierte Element aktualisiert oder neu initialisiert. Sobald das zugehörige JS-Bundle geladen ist, erhalten Sie eine „universelle“ Komponente: Sie kann serverseitig für Geschwindigkeit und Suchmaschinenoptimierung gerendert werden und sich anschließend clientseitig wie ein vollständig interaktives, benutzerdefiniertes Element verhalten.
Ein Nachteil von SSR mit Includes ist, dass das langsamste Fragment die gesamte Antwortzeit bestimmt.Caching auf Fragmentebene ist nahezu unerlässlich. Bei aufwändigen, hochgradig personalisierten Elementen (wie Empfehlungen) kann man auf serverseitiges Rendering verzichten und diese asynchron auf dem Client laden.
Skelettbildschirme sind ein guter Kompromiss, um abrupte Layoutwechsel zu vermeiden.Ein Fragment kann serverseitig einen ausgegrauten Platzhalter rendern, der in etwa die gleiche Größe wie der endgültige Inhalt hat. Sobald die eigentlichen Daten clientseitig eintreffen, wird das Gerüst ohne größere Neuberechnungen ausgetauscht.
Datenladen und wahrgenommene Leistung
In der Welt der Microfrontends muss man sorgfältig darüber nachdenken, wo und wann Daten abgerufen werden.Sie können alle Daten serverseitig, alle clientseitig oder in einer Hybridlösung abrufen. Jede dieser Optionen beeinflusst die Caching-Strategien, die Interaktivitätszeit und die wahrgenommene Geschwindigkeit.
Serverseitige Includes fördern naturgemäß serverseitige Abrufe pro Fragment.Jedes Microfrontend kommuniziert mit seinen Backend-Diensten, rendert HTML und gibt es an die Shell zurück. Dieses HTML kann unabhängig von anderen Fragmenten zwischengespeichert werden, was die Skalierung stark frequentierter Bereiche wie Login oder Produktlisten erleichtert.
Beim Laden von Daten auf den Client sollten Sie progressive Zustände einplanen.Ein initiales Grundgerüst, schnelle Aktualisierungen bei Attributänderungen und ein Ausweichverhalten bei langsamen APIs. Manchmal ist es optisch weniger störend, die alten Daten beizubehalten, bis die neuen eintreffen, als bei jeder kleinen Änderung ein Grundgerüst anzuzeigen.
Microfrontends mit React
React ist aufgrund seines Ökosystems und seiner Rendering-Optimierungen eine sehr beliebte Wahl für die Implementierung von Microfrontends.Das virtuelle DOM und die Diffing-Funktion ermöglichen es, kleine Teile der Benutzeroberfläche auf Basis von Prop-Änderungen oder globalen Zustandsänderungen unkompliziert zu aktualisieren, und React-Apps können entweder als eigenständige SPAs oder als Custom Elements gebündelt werden.
Die Migration zwischen React-Versionen erfolgt in der Regel schrittweise und relativ problemlos. Im Vergleich zu anderen Frameworks ist dies hilfreich, wenn viele unabhängige Teams separate Microfrontends pflegen. Es ist nicht erforderlich, dass alle Fragmente gleichzeitig von einer Hauptversion zur nächsten springen.
Die Kehrseite der Medaille ist, dass dezentrale React-Mikrofrontends zu einer unkontrollierten Ressourcenausbreitung führen können.Mehrere Teams, mehrere CI/CD-Pipelines, viele Bundles, viele kleine Repositories. Ohne ausreichende Automatisierung für Build, Provisionierung und Observability wird dieser Aufwand schwer zu bewältigen.
Ein weiteres praktisches Problem ist die Bündelgröße.Wenn jedes Microfrontend seine eigene Kopie von React und gemeinsam genutzten Bibliotheken ausliefert, kann die Gesamtgröße des Downloads enorm ansteigen, insbesondere wenn mehrere Fragmente zum Rendern einer Seite benötigt werden. Lösungen wie Module Federation (zum Teilen von Abhängigkeiten zur Laufzeit) oder ein streng aufeinander abgestimmter Stack über alle Teams hinweg können dies verhindern.
Microfrontends mit Angular
Angular eignet sich gut für stärker meinungsbildende Microfrontend-Setups.Dies gilt insbesondere bei der Verwendung von Monorepos und den dazugehörigen Tools (wie Nx). Angular-Workspaces sind in Projekte und Bibliotheken unterteilt, wodurch es naheliegend ist, eine große Lösung in mehrere Anwendungen und gemeinsam genutzte Bibliotheken aufzuteilen.
Seit Angular 12 und Webpack 5 ist die Modulföderation zu einem integralen Bestandteil geworden.Ein Angular-Projekt kann mithilfe von Schematic-Befehlen als Host oder Remote konfiguriert werden, indem die notwendigen Verbindungen hergestellt werden. webpack.config.js und Bootstrap-Logik für Sie.
In diesem Modell fungiert die „Host“-Angular-App als Shell. Das System orchestriert Navigation, gemeinsamen Zustand und Abhängigkeitsverteilung. Einzelne Angular-Mikrofrontends (Remotes) stellen Angular-Module bereit, die der Host über Modulföderation dynamisch nachladen kann.
Die üblichen Angular-Routing-Primitive gelten weiterhin.Innerhalb eines Microfrontends verwendet man RouterModule.forChild für untergeordnete Routendefinitionen, so dass nur der Host verwendet wird forRootAuf diese Weise können mehrere Angular-Apps unter einem einheitlichen URL-Bereich ohne Router-Konflikte koexistieren.
Modulföderation in der Praxis (Angular-Beispiel)
Webpack Module Federation ist eine Funktion von Webpack 5, die es mehreren Builds ermöglicht, Code zur Laufzeit gemeinsam zu nutzen.Ein Build (der Host) lädt dynamisch Module, die von anderen Builds (Remotes) bereitgestellt werden, über eine kleine Manifestdatei, die typischerweise benannt ist. remoteEntry.js.
In Angular lässt sich das recht schnell erstellen.Beispielsweise könnten Sie eine Host-App erstellen (host-app) und dann einen Schaltplan ausführen wie ng add @angular-architects/module-federation --project host-app --port 4200Dadurch werden eine ModuleFederationPlugin-Konfiguration, Bootstrapping-Dateien und Laufzeitlogik eingerichtet.
Anschließend erstellen Sie zwei Remote-Angular-Anwendungen: eine für einen Produktkatalog und eine für den Warenkorb.Jede App erhält ihren eigenen Port (z. B. 4201 für …). products-app, 4202 für cart-app) und seiner eigenen Modulföderationskonfiguration. In webpack.config.js von jeder Fernbedienung, die Sie verwenden exposes um ein Modul (typischerweise das Hauptanwendungsmodul) unter einem Schlüssel wie ./ProductsModule or ./CartModule.
Die Host-Shell definiert dann Routen, die diese Remote-Module verzögert laden. loadRemoteModule von @angular-architects/module-federationZum Beispiel die Navigation zu /products löst einen dynamischen Import aus http://localhost:4201/remoteEntry.js und Ladungen ProductsModule; /cart Dasselbe gilt für die Fernbedienung des Einkaufswagens.
Im Katalog-Mikrofrontend könnten Sie Folgendes haben: ProductsComponent das eine Tabelle mit Elementen erzeugt, Daten aus einem lesen PRODUCTS_CATALOG Die Seite ist konstant und bietet einen „In den Warenkorb“-Button. Beim Klicken wird der Artikel im Warenkorb gespeichert. localStorage unter einem „Warenkorb“-Schlüssel, wobei die Mengen erhöht werden, wenn das Produkt bereits existiert.
Das Warenkorb-Mikrofrontend liest dann aus demselben localStorage HauptDie Anwendung zeigt eine Tabelle mit Produktname, Preis, Menge und Gesamtbetrag an und bietet eine Schaltfläche „Warenkorb leeren“, die den Speicher löscht und den internen Zustand zurücksetzt. Dies ist eine einfache, aber anschauliche Möglichkeit, Zustände zwischen zwei unabhängigen Anwendungen auszutauschen, ohne dass eine enge Kopplung erforderlich ist.
Aufbau der Host-Shell: Layout, Startseite und Navigation
Eine solide Host-Shell ist entscheidend für eine gute Benutzererfahrung auf Microfrontends.Es verwaltet üblicherweise das globale Layout (Header, Footer, Sidebars), das Routing auf oberster Ebene und manchmal auch globale Zustände wie Authentifizierung oder Feature-Flags.
Im Angular-Beispiel definiert der Host einen LayoutComponent das einen Header und ein verschachteltes Element rendert router-outletDer Header befindet sich in einem eigenen Bereich. HeaderModule und stellt Navigationslinks zur Startseite, Produktliste und zum Warenkorb über Angular bereit. routerLinkRoutenpfade können in einem Enum zentralisiert werden, wie zum Beispiel RoutesPath um magische Zeichenketten zu vermeiden.
Das Layout-Routing-Modul richtet eine übergeordnete Route ein mit LayoutComponent als seine Komponente und definiert untergeordnete Routen für /home, /products kombiniert mit einem nachhaltigen Materialprofil. /cartdem „Vermischten Geschmack“. Seine /home Der Pfad lädt eine lokale HomeModuleDie anderen verwenden loadRemoteModule um die Angular-Mikrofrontends zur Laufzeit einzubinden.
Innerhalb des Wirts, ein SharedModule kann wiederverwendbare Bausteine sammeln wie Header, Layout, allgemeine Direktiven und Konstanten. Dieses Modul kann in das Stammverzeichnis importiert werden. AppModule zusammen mit AppRoutingModule, wodurch der leere Pfad auf die Layout-Routing-Konfiguration verweist.
Next.js und Microfrontends
Next.js eignet sich als produktionsreifes React-Framework auch gut für einen Microfrontend-Ansatz.Insbesondere seit der Einführung von Webpack 5 und damit der Unterstützung für Module Federation. Der Fokus auf serverseitiges Rendering (SSR), inkrementelle statische Generierung und Routing macht es zu einem vielversprechenden Kandidaten für Shells, individuelle Microfrontends oder beides.
Um Microfrontends in Next.js zu implementieren, konfiguriert man typischerweise die Modulföderation auf Webpack-Ebene.Dabei werden bestimmte Seiten oder Komponenten als Remote-Ressourcen bereitgestellt und von einem Host aus geladen. Obwohl die Modulföderation „nur“ eine Funktion des JavaScript-Bundlers ist, kann man sie als Architekturmuster betrachten: Sie ermöglicht das dynamische Laden von Code verschiedener Teams, ohne alles im Voraus bündeln zu müssen.
Für ältere Next.js-Versionen ohne Webpack 5 benötigen Sie externe Adapter. Um die Unterstützung für Föderationen zu ermöglichen. Ab Next 10.2 ist die Unterstützung für Webpack 5 integriert, was die Einrichtung erheblich vereinfacht.
Single-SPA und andere Microfrontend-Frameworks
Single-SPA ist eine weitere bekannte Lösung für Microfrontends, insbesondere in React-Ökosystemen.Der Fokus liegt auf der Orchestrierung mehrerer unabhängiger Anwendungen auf derselben Seite, wobei jede Anwendung basierend auf der aktuellen Route in einen eigenen DOM-Knoten eingebunden wird.
Mit Single-SPA können Sie mehrere React-Anwendungen (oder sogar eine Mischung aus React, Vue und Angular) parallel betreiben.Das Framework regelt, wann die einzelnen Microfrontends beim Navigieren des Benutzers gestartet, eingebunden oder uneingebunden werden, und Sie binden es in Ihre Routing-Strategie ein (zum Beispiel mit React Router in jedem Fragment).
Bei der Wahl zwischen Single-SPA und ModulföderationTeams berücksichtigen häufig ihre Präferenzen bezüglich Bundler und Tools. Module Federation integriert sich tief in Webpack (und zunehmend auch in Alternativen wie Rspack oder Rollup, sobald diese Unterstützung bieten). Single-SPA hingegen konzentriert sich mehr auf die Laufzeit-Orchestrierung als auf die gemeinsame Nutzung von Bundles, sodass es mit verschiedenen Build-Tools verwendet werden kann, während die Code-Freigabe auf andere Weise gehandhabt wird.
Ziele, Merkmale und Vorteile von Microfrontends
Das Hauptziel von Microfrontends ist es, die Frontend-Entwicklung über viele Teams hinweg zu skalieren, ohne dass der Koordinationsaufwand zu groß wird.Anstelle einer riesigen Codebasis mit synchronisierten Releases erhält man kleinere, unabhängig voneinander einsetzbare Einheiten.
Zu den wichtigsten Zielen gehören in der Regel: Dies ermöglicht es mehreren Teams, parallel zu arbeiten, unterstützt die unabhängige Bereitstellung für verschiedene Teile der Benutzeroberfläche, erhält die Flexibilität, unterschiedliche Technologien einzusetzen, wo dies sinnvoll ist, und verbessert die Wartbarkeit durch die Reduzierung der Größe und Komplexität der einzelnen Codebasen.
Typische Merkmale einer solchen Architektur sind die Wiederverwendung von Komponenten durch gemeinsam genutzte Bibliotheken.Modulare Integration über eine Anwendungsshell, unabhängige Pipelines pro Microfrontend, Leistungsoptimierung durch CDNs und Caching, zentralisierte Sicherheitsbehandlung und starke Beobachtbarkeit.
Aus betriebswirtschaftlicher Sicht sind die Vorteile beträchtlich.Die Entwicklung skaliert besser mit mehr Teams, Fehler lassen sich besser isolieren, Funktionen können pro Domäne eingeführt oder zurückgesetzt werden, und veraltete Frontend-Stacks können schrittweise migriert werden, indem jeweils ein Teil ersetzt wird, anstatt die gesamte Anwendung neu zu schreiben.
Schlüsselkomponenten einer Microfrontend-Architektur
Obwohl die Implementierungen variieren, weisen die meisten Microfrontend-Architekturen einige gemeinsame Strukturkomponenten auf. die alles zusammenhalten.
Die Anwendungshülle (oder der Container) ist das RückgratEs ist verantwortlich für das äußere Layout, die globale Navigation, die Authentifizierung, teilweise den globalen Zustand und die Logik zum Laden und Entladen von Microfrontends. In browserbasierten Umgebungen ist es die Seite, die alle anderen Bundles einbindet.
Jedes Microfrontend ist ein in sich geschlossenes Modul, das eine spezifische Funktion implementiert.Funktionen wie Produktkatalog, Warenkorb, Benutzerprofil oder Administrationsbereich werden bereitgestellt. Es bietet eine Integrationsschnittstelle (Routen, benutzerdefinierte Elemente, Modulföderations-Remotes) und verbirgt interne Details vor dem Rest des Systems.
Für die Kommunikation zwischen verschiedenen Microfrontends ist häufig ein Ereignisbus oder ein Nachrichtensystem vorhanden.Dies kann eine einfache Abstraktion von DOM-Ereignissen, ein zentralisierter Redux-Speicher oder ein benutzerdefinierter Message Broker sein. Ziel ist eine entkoppelte Publish/Subscribe-Semantik: Ein Microfrontend sendet Ereignisse, ohne zu wissen, wer diese verarbeitet.
Gemeinsam genutzte Bibliotheken enthalten wiederverwendbare UI-Komponenten, Hilfsprogramme, Design-Tokens und gängige Clients.In Monorepo-Setups spielen Tools wie Nx ihre Stärken aus, da sie es ermöglichen, gemeinsam genutzte Pakete zu definieren, die von mehreren Anwendungen verwendet werden, mit festgelegten Grenzen und konsistenten Versionen.
Observability-Kollektoren und -Tools (z. B. mit OpenTelemetry) Die Protokolle, Metriken und Traces aller Microfrontends werden aggregiert, wodurch es möglich wird, Probleme zu diagnostizieren, die mehrere Fragmente oder Dienste betreffen.
CDNs vervollständigen das Bild auf der Lieferseite.Durch das Zwischenspeichern statischer Ressourcen wie JS-Bundles, CSS und Bilder in der Nähe der Nutzer werden Latenzzeiten reduziert und die Ursprungsserver entlastet. In Microfrontend-Setups werden die Ressourcen jedes Fragments häufig auf einem eigenen CDN-Pfad gehostet, um unabhängiges Caching und Rollouts zu ermöglichen.
Architektur- und Designmuster für Microfrontends
Es gibt einen umfangreichen Katalog von Mustern, die speziell für Microfrontends gelten., was üblicherweise dadurch definiert wird, wie man sie zusammenstellt, bereitstellt und miteinander verbindet.
Komponentenbasierte Komposition bedeutet, die Benutzeroberfläche aus Webkomponenten oder ähnlichen Grundelementen zu erstellen.Jede Komponente hat eine klar definierte Aufgabe, eindeutige Ein- und Ausgaben und kann isoliert getestet werden. Eine übergeordnete Kompositionsschicht (wie ein Shell- oder Orchestrierungsframework) ordnet diese Komponenten zu vollständigen Seiten an.
Das Föderationsmuster betont die vollständige Autonomie der Anwendung.Jedes Microfrontend ist eine eigenständige Anwendung mit eigenem Lebenszyklus und eigenem Team; die Shell oder ein API-Gateway leitet Anfragen/Daten lediglich an das richtige Fragment weiter. Die Kommunikation erfolgt über klar definierte REST-APIs oder Ereignisse.
Das Anwendungsshell-Muster ist im Grunde der „Host“-Ansatz.Die Shell lädt Microfrontends, kümmert sich um übergreifende Belange wie Navigation und Sicherheit und sorgt für ein einheitliches Erscheinungsbild. Dies ist typisch für Setups mit Modulföderation oder Single-SPA.
API-Gateway- und Backend-for-Frontend-(BFF)-Muster konzentrieren sich auf die Serverseite.Ein API-Gateway fungiert als Vermittler zwischen verschiedenen Backend-Diensten, leitet Anfragen weiter und sorgt für Sicherheit. Ein Backend-Framework (BFF) geht noch einen Schritt weiter: Jedes Frontend (Web, Mobil, IoT) kann ein eigenes, auf seine Bedürfnisse zugeschnittenes Backend erhalten.
Verteilte Datenspeichermuster berücksichtigen, dass verschiedene Microfrontends ihre eigenen Datenquellen verwalten können. oder Caches. Im Browser bedeutet dies oft die Verwendung separater localStorage-Schlüssel, IndexedDB-Datenbanken oder In-Memory-Speicher, während es im Backend separate Datenbanken pro Microservice bedeutet.
Beobachtbarkeit, unabhängige Bereitstellung, horizontale Skalierbarkeit und Sicherheitsmuster Wir gehen auf operative Belange ein: Wie überwacht man jedes Fragment? Wie stellt man sie ohne globale Ausfälle bereit? Wie skaliert man sie unter Last? Und wie setzt man Authentifizierung/Autorisierung konsistent durch?
Routing-Komposition und Lazy-Loading-Muster sind zentral für UX und Performance.Ein Master-Router legt fest, welches Microfrontend welchen Pfad verarbeitet, und jedes Microfrontend verfügt über einen eigenen internen Router. Lazy Loading stellt sicher, dass nur der Code für die tatsächlich für die aktuelle Route benötigten Fragmente heruntergeladen wird.
Schließlich gewährleisten ereignisbasierte Kommunikationsmuster, dass lose gekoppelte Mikrofrontends weiterhin koordinieren können. durch Domänenereignisse, ohne direkte Abhängigkeiten einzuführen, die den Sinn der Modularität zunichtemachen würden.
Wann man Microfrontends einsetzen sollte (und wann nicht)
Mikrofrontends glänzen in großen, komplexen Anwendungen mit klar definierten Funktionsbereichen.Denken Sie an E-Commerce-Plattformen, Enterprise-Management-Systeme, kommunale Portale, Bildungsplattformen, große Gesundheitsportale oder jedes Produkt, bei dem viele Teams an separaten Funktionsbereichen arbeiten.
Sie sind besonders nützlich, wenn mehrere Teams parallel arbeiten. Wenn Sie bei technischen Entscheidungen, Release-Zyklen und Prioritäten Autonomie benötigen oder ein bestehendes Frontend schrittweise modernisieren und sich eine vollständige Neuentwicklung nicht leisten können, können Sie jeweils einen Bereich in ein neues Microfrontend auslagern und dieses in die bestehende Architektur integrieren.
Sie sind auch dann hilfreich, wenn verschiedene Teile der App unterschiedlich skaliert werden müssen.Eine Anmelde- oder Checkout-Seite kann deutlich mehr Traffic generieren als eine Administrator-Konfigurationsseite; durch die unabhängige Skalierung dieser Bereiche lassen sich erhebliche Infrastrukturkosten einsparen.
Mikrofrontends sind jedoch kein kostenloses MittagessenSie erhöhen die architektonische Komplexität, erfordern eine intensive Abstimmung hinsichtlich UX und gemeinsamer Verträge und führen zu neuen Fehlerquellen (z. B. dass ein Fragment nicht geladen wird). Für kleine oder mittlere Anwendungen mit einem einzigen Team ist ein gut strukturierter Monolith oft einfacher und kostengünstiger.
Teams sollten sich auch vor „Framework-Anarchie“ hüten.Technisch gesehen ist es zwar möglich, dass jedes Microfrontend einen völlig anderen Technologie-Stack verwendet, doch eine unkontrollierte Mischung verschiedener Frameworks erschwert die Personalsuche, die Bereitstellung von Tools und die gemeinsame Nutzung von Code. Ein angemessener Grad an Abstimmung (z. B. „Wir setzen primär auf React, erlauben aber Angular für bestimmte Anwendungsbereiche“) ist langfristig meist die bessere Lösung.
Microfrontends erweitern das Microservices-Konzept auf den Browser und geben Teams die Möglichkeit, große Frontends in autonome, domänenorientierte Teile zu zerlegen, die sich unabhängig voneinander weiterentwickeln, bereitstellen und skalieren lassen und dennoch ein einheitliches Benutzererlebnis bilden, wenn sie über eine Anwendungshülle, gemeinsam genutzte Bibliotheken, Modulföderation, Webkomponenten oder Orchestrierungsframeworks wie Single-SPA kombiniert werden.
