Eine Micro-Frontend-Architektur unterteilt eine Browser-Anwendung in unabhängig erstellte und bereitgestellte Segmente, für die jeweils ein einzelnes Team die vollständige Verantwortung trägt. Anstatt einer einzigen Codebasis, bei der jedes Team auf Änderungen warten muss, gibt es nun mehrere, die jedes Team über seine eigene Pipeline ausliefert. Das Frontend ist somit kein Flaschenhals mehr hinter einem Microservices-Backend.
Das ist das gesamte Versprechen. Es ist jedoch nicht umsonst. Sie gewinnen unabhängige Bereitstellungen, eine freie Technologiewahl pro Segment und kleinere Bundles; dafür übernehmen Sie eine gemeinsam zu wartende Plattform, ein Design-System, das teamübergreifend überwacht werden muss, und einen Koordinationsaufwand, den nur wenige Teams bewältigen können. Bei weniger als drei oder vier autonomen Teams übersteigen die Gemeinkosten in der Regel den Nutzen gegenüber dem Monolithen, den sie ersetzen.
Ist also die Frage, ob Micro-Frontends funktionieren? Nein. Die Frage ist, ob Ihre Organisation bereits an dem Punkt ist, an dem sie sich auszahlen. Dieser Beitrag erläutert, was ein Micro-Frontend ist, wie sich diese Architektur zu Microservices verhält, welche Vor- und Nachteile sich in der Praxis bei der Bereitstellung ergeben, welche Plattformkosten anfallen und einen Drei-Stufen-Check zur Einsatzbereitschaft, den Sie für Ihre eigene Infrastruktur durchführen können, bevor Sie sich entscheiden.
Ein Micro Frontend besteht aus mehreren kleinen, autonomen und modularen Komponenten. Die Module sind in sich geschlossen und können auf anderen Seiten wiederverwendet werden. Sie können diese Komponenten in einer beliebigen Programmiersprache schreiben: JavaScript und JavaScript-Frameworks sind die gängige Wahl, aber alles, was sich kompilieren und in ein JavaScript-Bundle packen lässt, kann importiert und vom restlichen Frontend zusammengesetzt werden.
Stellen Sie sich ein Einkaufszentrum vor. Ein Dach, ein Eingang, ein Parkplatz, eine einheitliche Beschilderung, und hinter jeder Ladenfront richtet ein anderes Team seine eigene Fläche nach seinem eigenen Zeitplan ein. Die Kunden erleben einen einzigen Ort; die Geschäfte werden von denjenigen betrieben, die ihr Handwerk am besten verstehen.
In der Micro-Frontend-Architektur ist das genau die Anordnung. Sie zerlegen die monolithische Anwendung in kleinere Teile und programmieren, testen und implementieren jedes Fragment separat, sodass funktionsübergreifende Teams jede Komponente – von der Datenbank bis zur Benutzeroberfläche – unabhängig voneinander entwickeln können. Was die Übergänge verbirgt, sind die Shell und das gemeinsame Design-System: Die Shell rendert jeden Teilbereich zu einer einzigen Seite mit einer Navigation und einer Sitzung, und das Design-System sorgt für einheitliche Komponenten und ein konsistentes Styling.
Das Muster wurde benannt und katalogisiert unter micro-frontends.org, und das Team von Martin Fowler veröffentlichte den kanonischen Artikel über das Micro-Frontend-Muster, einschließlich der Integrationsstile, auf die wir weiter unten eingehen.
Hier sind einige bekannte Unternehmen, die Micro Frontends verwenden:
Betrachten Sie diese Liste als Beweis dafür, dass das Muster skalierbar ist, nicht als Grund für dessen Einführung. Jedes der aufgeführten Unternehmen beschäftigt Dutzende von Frontend-Teams. Genau darauf ist diese Architektur ausgelegt.
Das Ziel eines Micro-Frontends ist es, die Vorteile von Microservices für das Backend zu nutzen, ohne die Nachteile eines großen Frontend-Monolithen in Kauf nehmen zu müssen.
Um zu verstehen, warum das funktioniert, müssen wir zwei Dinge genau betrachten: Was Microservices auf der Serverseite tatsächlich verändert haben und was auf der Clientseite hartnäckig unverändert blieb. Wir haben beide Seiten dieser Grenze beim Umbau gesehen Eurofounds Frontend- und Backend-Integration, bei der ein modulares Backend immer noch auf ein einziges Frontend treffen musste.
Microservice-Architektur ist ein Entwurfsmuster in der Backend-Entwicklung. Während eine monolithische Architektur als eine Einheit ausgeliefert wird, bestehen Microservices aus mehreren unabhängig voneinander bereitstellbaren Komponenten, die nach Geschäftsbereichen getrennt und über APIs verbunden sind.
Was das für ein Unternehmen bedeutet, ist weniger umfangreich, als die übliche Liste von Adjektiven vermuten lässt, und sollte klar benannt werden:
Genau diese vier Eigenschaften besitzt ein Frontend-Monolith nicht, egal wie modern das dahinterliegende Backend ist. Unser Leitfaden zur Softwarearchitektur zeigt auf, wie sich diese Abwägung bei unterschiedlichen Teamgrößen verhält.
Ein Frontend-Monolith ist die Client-Seite einer Webanwendung, die aus einer einzigen Codebasis erstellt wurde. Viele Produkte nutzen diesen Ansatz noch immer, selbst wenn ihr Backend bereits vollständig dekomponiert ist. Die Serverseite ist modular, das Frontend bleibt ein Ganzes.
Für ein oder zwei Teams ist das die richtige Struktur. Ehrlich gesagt ist sie meistens sogar länger die richtige Struktur, als man vermuten würde. Die Probleme treten erst auf, wenn die Anzahl der Teams, die an dieser Codebasis arbeiten, wächst. Sie sind spezifisch genug, um sie zu identifizieren:
Ein Frontend-Monolith schränkt also die unabhängige Bereitstellung ein, die man eigentlich durch Microservices erreichen wollte. Genau diese Lücke schließen Micro-Frontends. Man muss jedoch offen aussprechen, worin diese Lücke besteht: Sie ist organisatorischer Natur. Wenn die Verzögerung in der Review-Kultur oder in einem Change-Board begründet liegt und nicht in der Codebasis, wird eine Aufteilung des Codes das Problem nicht lösen.
Unabhängiges Deployment hilft nur, wenn der dahinterstehende Bereitstellungsprozess diszipliniert ist. Genau hier haben die besten agilen Praktiken ihren Platz.
Mit einem Micro-Frontend können Unternehmen:
Dieser Ansatz eignet sich für Teams, die im Backend bereits unabhängig voneinander arbeiten. Die Vorteile sind spürbar, doch wie im nächsten Abschnitt erläutert, ist jeder von ihnen mit einem gewissen Aufwand verbunden.
Die Liste der veröffentlichten Vorteile dieser Architektur ist lang. In der Praxis lassen sie sich auf vier Kernpunkte reduzieren, jeweils mit dem zugrunde liegenden Mechanismus und der notwendigen Voraussetzung.
Die Kosten entsprechen denselben vier Eigenschaften, nur aus einer anderen Perspektive betrachtet. Keine davon ist ein Grund, diese Architektur zu meiden. Aber für alle braucht es einen Verantwortlichen, bevor Sie beginnen.
Die beiden Architekturen lösen unterschiedliche Probleme. Hier ist der Vergleich auf einen Blick – betrachten Sie ihn als Entscheidungshilfe für die Frage „Welche Einschränkungen liegen bei mir tatsächlich vor?“ und nicht als Bewertung, was besser ist.
| Dimension | Monolithisches Frontend | Micro-Frontend |
|---|---|---|
| Codebasis | Ein gemeinsames Repository, an dem alle arbeiten | Mehrere unabhängig verwaltete Abschnitte |
| Bereitstellung (Deployment) | Eine gemeinsame Pipeline / Release Train | Pipeline pro Abschnitt, Bereitstellung bei Bedarf |
| Eignung für Teams | Ein bis zwei Teams | Drei, vier oder mehr autonome Teams |
| Release-Frequenz | Abhängig von der langsamsten Änderung im Paket | Jeder Abschnitt wird veröffentlicht, sobald er fertig ist |
| Schadensradius (Blast Radius) | Ein Fehler (Regression) kann das gesamte Frontend lahmlegen | Auf einen einzelnen Abschnitt beschränkt |
| Technologie | Gemeinsames Framework und Versionen; ein Upgrade ist ein projektweites Unterfangen | Freie Wahl pro Abschnitt; ein Upgrade wird zuerst an einem Abschnitt erprobt |
| Bundle-Größe | Ein einzelnes Paket, keine Duplizierung | Nur der Code, den eine Seite benötigt – jedoch Risiko doppelter Framework-Kopien |
| Testen | Einfachere End-to-End-Tests: eine Gesamteinheit zu testen | Abschnitte werden isoliert getestet; das zusammengesetzte Produkt benötigt eine eigene E2E-Testsuite |
| Laufende Plattformkosten | Keine über die Anwendung selbst hinaus | Shell + Komposition + Design System + E2E-Testsuite (≈ ein Entwickler plus ein Verantwortlicher für das Design System) |
| Ideal wenn | Release-Engpässe nicht Ihr Hauptproblem sind | Mehrere autonome Teams Schlange stehen, um dieselbe Codebasis bereitzustellen |
Die wirtschaftliche Entscheidung ist ein Abwägen zwischen Koordinationsaufwand und Liefergeschwindigkeit, das sich erst ab einer gewissen Größenordnung rechnet. Die folgenden Zahlen sind eher als Richtwerte zu verstehen. Die Art der Abwägung ist wichtiger als die konkreten Zahlen.
Micro-Frontend-Architekturen bieten echte Vorteile, sind aber keine Universallösung. Nicht jede Webanwendung eignet sich für diesen Ansatz, und die entscheidenden Faktoren sind ebenso organisatorischer wie technischer Natur.
Bevor wir uns für Micro Frontends entscheiden, durchläuft ein Projekt drei Prüfphasen. Besteht es eine davon nicht, ist der Monolith weiterhin die bessere Wahl – wobei die jeweilige Hürde als erste Aufgabe definiert ist.
Zwei weitere Rahmenbedingungen sind ebenfalls wichtig. Unterschiedliche Technologie-Stacks für verschiedene Module sollten eine echte Anforderung und keine bloße Präferenz sein, und das Budget muss die oben genannten laufenden Plattformkosten decken können.
Wenn Sie unsicher sind, ob Micro Frontends für Ihr Projekt geeignet sind, gehen Sie die drei Prüfphasen mit jemandem durch, der eine solche Migration bereits durchgeführt hat. Letztlich hängt es von den Besonderheiten Ihres Geschäftsplans ab und nicht von den abstrakten Vorzügen der Architektur.
Das Frontend aufzuteilen ist der einfache Teil. Ob das Ergebnis als Ganzes funktioniert, hängt von vier Bereichen ab, für die kein einzelner Slice zuständig ist. Für jeden dieser Bereiche muss vor der ersten Migration eine Entscheidung getroffen werden, nicht erst danach.
Utility-Komponenten, die den Status verwalten oder mit der Anwendungsumgebung kommunizieren, anstatt UI-Elemente zu rendern, können wie jeder andere Slice bei Bedarf geladen werden. Da sie meist kein UI besitzen, werden sie bei der Festlegung der Zuständigkeiten leicht übersehen.
Sie können Micro-Frontends auf zwei Arten integrieren: zur Build-Zeit oder zur Laufzeit.
Der Container installiert jeden Slice als Bibliothek, ähnlich wie Sie ein Paket aus dem npm-Registry für Node.js installieren würden. So wird heute der Großteil des Codes geschrieben, und es ist die einfachste funktionierende Lösung.
Die Nachteile sind der Grund, warum die meisten Teams diesen Ansatz hinter sich lassen. Mehrere Versionen gemeinsam genutzter Bibliotheken müssen synchron gehalten werden, was bei Versäumnissen zu Build-Problemen führt. Die Kombination verschiedener Technologien ist schwierig. Das finale Paket enthält sämtliche Abhängigkeiten und ist daher sehr groß. Da jede Änderung an einer Abhängigkeit ein erneutes Build und Deployment des Containers erfordert, bleiben der Container und alle seine Slices eng miteinander gekoppelt. Genau diese Kopplung soll durch die Architektur jedoch vermieden werden.
Bei der Laufzeit-Integration wird die Seite aus unabhängig bereitgestellten Slices zusammengesetzt, während sie ausgeliefert wird oder nachdem sie geladen wurde. Dadurch kann ein Slice veröffentlicht werden, ohne den Container neu zu bauen. Es gibt drei Arten der Komposition:
@module-federation/nextjs-mf Plugin unterstützte immer nur den älteren Pages Router, niemals den standardmäßigen App Router, und die Betreuer haben es für ein Ende des Lebenszyklus um Ende 2026 markiert. Für App-Router-Projekte ist das offizielle @vercel/microfrontends Paket – das auf einem Multi-Zones-Modell statt auf dem Zusammenfügen von Chunks zur Laufzeit basiert – nun der unterstützte Weg. single-spa bleibt die wichtigste Alternative, wenn Slices mit unterschiedlichen Frameworks erstellt werden.Ein Micro Frontend ist ein Teilbereich der Benutzeroberfläche einer Webanwendung, der vom zuständigen Team eigenständig entwickelt und bereitgestellt wird. Anstatt einer einzigen Frontend-Codebasis, an der alle arbeiten, wird die Seite zur Build-Zeit oder direkt im Browser aus mehreren unabhängigen Teilen zusammengesetzt. Jedes Team kann seine Änderungen veröffentlichen, ohne auf andere warten zu müssen.
Wählen Sie den Monolithen, es sei denn, Release-Konflikte sind Ihr tatsächlicher Engpass. Eine einzelne Frontend-Codebasis ist einfacher zu erstellen, zu testen und zu verstehen, und sie bleibt die richtige Lösung für ein oder zwei Teams. Micro Frontends lohnen sich erst, wenn mehrere autonome Teams darauf warten, dieselbe Codebasis bereitzustellen, und nicht der Code, sondern die Warteschlange Sie ausbremst.
Neben den Teams selbst sollten Sie ein Budget für die Plattforminfrastruktur einplanen: die Shell, die Kompositionsschicht, ein gemeinsames Design-System und eine End-to-End-Testsuite. Bei den Projekten, die wir sehen, entspricht dies etwa der kontinuierlichen Kapazität eines Entwicklers plus einer Person für das Design-System, und dieser Aufwand bleibt auch nach dem Launch bestehen. Die Einsparung, die dies ausgleicht, ist die Durchlaufzeit, nicht die Anzahl der Mitarbeiter.
Drei bis vier autonome Frontend-Teams sind in der Regel die Schwelle, wobei Autonomie wichtiger ist als die reine Anzahl. Wenn jedes Release weiterhin über einen Lead oder ein Change-Board läuft, beseitigt die Aufteilung des Frontends einen Engpass, der gar nicht das eigentliche Problem war. Ein einzelnes Team, das Micro Frontends einführt, erhält die Betriebskosten eines verteilten Systems ohne jeglichen organisatorischen Nutzen.
Drei Fehler treten immer wieder auf: Das Ausliefern einer eigenen Framework-Kopie mit jedem Teilbereich, wodurch die Seite langsamer wird als der Monolith, den sie ersetzt hat. Das Design-System nicht zu pflegen, sodass die Benutzeroberfläche zwischen den Bereichen sichtbar auseinanderdriftet. Und das Zulassen unterschiedlicher Versionen in unabhängig bereitgestellten Bereichen, was erst in der Produktion auffällt. Alle drei sind eher Governance-Fehler als technische Probleme.
Das kann in beide Richtungen gehen. Die Aufteilung der Anwendung bedeutet, dass der Browser nur den Code lädt, den eine Seite tatsächlich benötigt, was hilft. Doppelte Abhängigkeiten in den verschiedenen Bereichen wirken jedoch in die entgegengesetzte Richtung und können die Gesamtgröße des Payloads erhöhen. Welcher Effekt überwiegt, hängt davon ab, ob gemeinsame Abhängigkeiten gezielt verwaltet werden. Messen Sie daher die Seitengeschwindigkeit pro Release, anstatt Annahmen zu treffen.
Ja, und das ist der risikoärmere Weg. Setzen Sie eine Shell vor den bestehenden Monolithen, lösen Sie einen vertikalen Bereich mit klaren Grenzen heraus und übertragen Sie die vollständige Verantwortung dafür an ein Team. Jeder weitere Bereich folgt demselben Muster. Planen Sie für die Migration eher Quartale als Sprints ein und halten Sie sich die Option offen, den Prozess jederzeit zu stoppen.
Micro-Frontends bieten dem Frontend das, was Microservices dem Backend gebracht haben: unabhängige Bereitstellung durch den Tausch von Koordinationsaufwand gegen Liefergeschwindigkeit. Dieser Tausch lohnt sich erst bei entsprechender Skalierung: Die Plattform verursacht laufende Kosten und die Fehlerquellen sind eher organisatorischer als technischer Natur. Prüfen Sie daher zuerst die drei Voraussetzungen: Teamgröße und Autonomie, Domänentrennung sowie Reifegrad der Bereitstellung. Wenn eine davon nicht erfüllt ist, ist deren Behebung die wertvollere Aufgabe, und der Monolith bleibt vorerst die bessere Lösung.
Wir haben sowohl Micro-Frontends als auch Monolithen entwickelt, gewartet und migriert. Gerne begleiten wir Ihre Systemlandschaft durch diese drei Prüfschritte – auch wenn das Ergebnis lautet, alles beim Alten zu belassen. Kontaktieren Sie uns und wir schauen uns das gemeinsam an.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
Ein ganz normaler Webentwickler, der sich gerne im Backend versteckt. Javascript und Ruby sind mein Ding. Ich tue mich noch schwer mit Docker und meine Builds gehen ziemlich oft kaputt.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
