Umfangreiche Webanwendungen werden häufig über Jahre erweitert. Neue Funktionen kommen hinzu, mehrere Entwicklungsteams arbeiten parallel und Änderungen an einem Teil der Benutzeroberfläche können Auswirkungen auf andere Teile der Anwendung haben. Wird das gesamte Frontend als eine gemeinsame Anwendung entwickelt und veröffentlicht, steigen dadurch technische und organisatorische Abhängigkeiten.
Eine Micro-Frontend-Architektur setzt an diesem Punkt an. Sie unterteilt die Benutzeroberfläche entlang fachlicher Verantwortungsbereiche in eigenständige Module. Ein Team kann dadurch beispielsweise das Kundenkonto weiterentwickeln, ohne gleichzeitig Änderungen an Produktsuche oder Warenkorb veröffentlichen zu müssen.
Kurzfassung
- Micro-Frontends teilen umfangreiche Benutzeroberflächen entlang fachlicher Domänen in eigenständige Module.
- Ein Micro-Frontend-Modul übernimmt einen abgegrenzten fachlichen Aufgabenbereich und kann unabhängig entwickelt und veröffentlicht werden.
- Eine gemeinsame Anwendungsschicht verbindet Navigation, Anmeldung, Layout und die einzelnen Module zu einer einheitlichen Oberfläche.
- Definierte Schnittstellen begrenzen Abhängigkeiten zwischen den Modulen.
- Der Ansatz eignet sich vor allem für umfangreiche Anwendungen mit mehreren Teams und voneinander unabhängigen Entwicklungszyklen.
Welches Problem Micro-Frontends lösen
In einem monolithischen Frontend gehören sämtliche Funktionen zu einer gemeinsamen Anwendung. Produktsuche, Kundenkonto, Warenkorb und Bestellverwaltung können beispielsweise im selben Quellcode entwickelt, gemeinsam getestet und zusammen veröffentlicht werden.
Mit zunehmendem Umfang wächst der Abstimmungsbedarf. Eine Änderung an gemeinsam verwendeten Komponenten kann mehrere Funktionen betreffen. Unterschiedliche Teams müssen ihre Releases koordinieren und selbst kleinere Anpassungen können Tests für die gesamte Anwendung erforderlich machen.
Micro-Frontends sollen diese Abhängigkeiten reduzieren. Die Anwendung wird dazu nicht beliebig technisch zerlegt, sondern nach fachlichen Aufgaben gegliedert. Die Verantwortung für einen abgegrenzten Teil der Benutzeroberfläche kann dadurch bei einem bestimmten Team liegen.
Der Vorteil liegt deshalb weniger in der Anzahl einzelner Frontends als in klaren Verantwortlichkeiten und möglichst unabhängigen Entwicklungs- und Releaseprozessen.
Wie Domänen und Micro-Frontend-Module zusammenhängen
Die fachliche Aufteilung bildet die Grundlage der Architektur. Eine Domäne beschreibt einen fachlich zusammenhängenden Aufgabenbereich innerhalb der Anwendung. Bei einer E-Commerce-Plattform können Produktsuche, Warenkorb, Kundenkonto und Bestellabwicklung beispielsweise unterschiedliche Domänen bilden.
Ein Micro-Frontend-Modul ist die technische Umsetzung eines solchen fachlich abgegrenzten Bereichs innerhalb der Benutzeroberfläche.
Das Warenkorb-Modul kann beispielsweise die Darstellung des Warenkorbs, Mengenänderungen und die angezeigte Zwischensumme übernehmen. Welche Informationen anschließend für Bestellung oder Zahlung benötigt werden, wird über definierte Schnittstellen weitergegeben.
Die Grenzen der Module sollten sich deshalb an fachlichen Verantwortlichkeiten orientieren. Eine rein technische Aufteilung nach einzelnen Komponenten schafft zwar zusätzliche Module, reduziert aber nicht automatisch die fachlichen Abhängigkeiten innerhalb der Anwendung.
Wie mehrere Module zu einer gemeinsamen Anwendung werden
Damit für Nutzer alles wie aus einem Guss aussieht, werden Navigation, Gestaltung und grundlegende Funktionen über alle Module hinweg vereinheitlicht.
Häufig übernimmt eine übergeordnete Anwendungsschicht diese Aufgabe. Sie wird als App-Shell bezeichnet. Dort können beispielsweise Hauptnavigation, Layout, Anmeldung oder globale Fehlermeldungen organisiert werden.
Die App-Shell bindet anschließend die benötigten Micro-Frontend-Module in die Benutzeroberfläche ein. Ob diese bereits auf dem Server zusammengesetzt oder erst während der Laufzeit im Browser geladen werden, ist eine technische Umsetzungsentscheidung.
Diese Entscheidung beeinflusst unter anderem Ladeverhalten, Deployment und technische Komplexität. Sie ist jedoch nicht der Ausgangspunkt der Architektur. Zunächst müssen die fachlichen Grenzen und Verantwortlichkeiten feststehen.
Im Zusammenhang mit einer Micro-Frontend-Architektur ist deshalb entscheidend, wie eigenständig die einzelnen Module entwickelt werden können und über welche definierten Wege sie miteinander kommunizieren.
Wie Module Informationen austauschen
Auch fachlich getrennte Module benötigen gemeinsame Informationen. Die Produktsuche kann beispielsweise eine Produkt-ID an das Warenkorb-Modul übergeben und nach einer erfolgreichen Anmeldung müssen mehrere Module wissen, welcher Benutzer angemeldet ist.
Der Austausch sollte über definierte Schnittstellen oder Ereignisse erfolgen. Ein Modul sollte dagegen nicht direkt auf interne Zustände oder Implementierungsdetails eines anderen Moduls zugreifen.
REST- oder GraphQL-Schnittstellen können beispielsweise eingesetzt werden, wenn Daten aus Backend-Systemen benötigt werden. Ein Modul kann etwa melden, dass ein Produkt zum Warenkorb hinzugefügt wurde. Andere Module können auf dieses Ereignis reagieren, ohne die interne Funktionsweise des Warenkorbs kennen zu müssen.
Entscheidend ist nicht eine bestimmte Technologie. Wichtig ist, dass festgelegt wird, welche Informationen ein Modul bereitstellt und welche Abhängigkeiten zwischen den Modulen zulässig sind.
Wie Gestaltung und gemeinsame Funktionen einheitlich bleiben
Unabhängig entwickelte Module können sich ohne gemeinsame Vorgaben im Erscheinungsbild und Verhalten unterscheiden. Ein Designsystem schafft deshalb verbindliche Regeln für die Benutzeroberfläche.
Es definiert beispielsweise Farben, Typografie, Abstände und wiederverwendbare Komponenten. Auch Anforderungen an Tastaturbedienung, Kontraste und andere Aspekte der Barrierefreiheit können darin festgelegt werden.
Gemeinsam verwendete Bibliotheken benötigen ebenfalls klare Regeln. Werden unterschiedliche Versionen derselben Abhängigkeit gleichzeitig geladen, können zusätzliche Datenmengen oder technische Konflikte entstehen.
Unabhängigkeit bedeutet deshalb nicht, dass jedes Team sämtliche technischen Entscheidungen selbst trifft. Für Funktionen und Standards, die die gesamte Anwendung betreffen, ist eine gemeinsame Abstimmung erforderlich.
Welche Rolle Deployment und Sicherheit spielen
Ein wesentlicher Vorteil von Micro-Frontends liegt darin, dass einzelne Module unabhängig veröffentlicht werden können. Dafür benötigt jedes Modul einen zuverlässigen Build-, Test- und Releaseprozess.
Gemeinsame technische Vorgaben bleiben trotzdem notwendig. Dazu gehören beispielsweise Logging, Fehlerbehandlung, Versionierung und der Umgang mit gemeinsam verwendeten Abhängigkeiten.
Auch Authentifizierung und Berechtigungen sollten zentral abgestimmt werden. Nicht jedes Modul sollte eigene Regeln für Anmeldung oder Sitzungsverwaltung entwickeln. Stattdessen muss feststehen, wie Benutzerinformationen bereitgestellt werden und auf welche Daten ein Modul zugreifen darf.
Externe Bibliotheken müssen regelmäßig aktualisiert und überprüft werden. Bei mehreren unabhängig entwickelten Modulen muss nachvollziehbar bleiben, welche Abhängigkeiten innerhalb der Anwendung eingesetzt werden und welche Versionen miteinander kompatibel sind.
Fazit
Micro-Frontends sind keine automatische Verbesserung gegenüber einem monolithischen Frontend. Sie lösen vor allem ein Skalierungsproblem umfangreicher Anwendungen, bei denen mehrere Teams an unterschiedlichen fachlichen Domänen arbeiten.
Die Grundlage bildet eine klare fachliche Aufteilung. Micro-Frontend-Module setzen diese Domänen technisch um, definierte Schnittstellen begrenzen Abhängigkeiten und eine gemeinsame Anwendungsschicht sorgt für eine einheitliche Benutzeroberfläche.
