Autoren: Krzystof Dabkowski und Dario Fiore

Micro Frontends werden in der Softwareentwicklung immer beliebter, da sie komplexe Frontends in kleinere, besser zu verwaltende Komponenten aufteilen. Erfahre in diesem Blog mehr zu diesem Ansatz, der durch den Erfolg von Microservices im Backend inspiriert wurde.

Die Welt wird komplexer — so auch die Frontends

Mit dem Digitalisierungsschub der letzten Jahre wurde für viele unserer Kunden Differenzierung an der Kundenschnittstelle wie z.B. an Kundenportalen noch wichtiger. Entsprechend wird in benutzerfreundliche, oft grosse und komplexe Frontends investiert. Gross und komplex ist ein Frontend spätestens dann, wenn mehrere Teams gleichzeitig an einem gemeinsamen Frontend entwickeln. Die Konsequenz davon ist, dass Anpassungen oder Fehler in einer Komponente sich auf das ganze Frontend auswirken und so Releases zur Zitterpartie werden können. Darum ist es für alle Architekt:innen, Projektleiter:innen und Teamleiter:innen besonders wichtig, dass sie sich mit den Architekturansätzen verschiedener Frontends auskennen und die jeweiligen Vor- bzw. Nachteile kennen.

Es waren einmal… monolithische Frontend-Architekturansätze

Während sich im Backend schon seit Jahren Microservice-Architekturen durchgesetzt haben, waren Frontend Projekte bisher oft monolithisch aufgebaut. Das führt dazu, dass die Frontends als komplette Einheit erstellt werden, die in sich geschlossen und weniger abhängig von anderen Anwendungen sind (siehe Abb. 1).

Eine solche monolithische Frontend-Architektur führt oft zu folgenden Problemen:

• Der Frontend-Code wird rasch umfangreich, komplex und unübersichtlich. Der Wartungsaufwand steigt und Fehler nehmen zu.
• Die Abhängigkeiten führen zu überraschenden Fehlern bei Releases.
• Es entsteht eine sStarke Kopplung der Funktionalität im Frontend.

Es gibt zwar verschiedene Ansätze zur Modularisierung monolithischer Frontends, diese bringen jedoch gewichtige Nachteile mit sich. Hier eine Auswahl:

• Absprünge in separate Frontends via Links erlauben sehr einfach andere Frontends zur Laufzeit “anzubinden”, resultieren aber in Wartezeiten, bis das neue Frontend geladen und aufgebaut ist. Das zeigt sich besonders, wenn die Benutzer:innen häufig zwischen den Frontends wechseln müssen oder die Absprünge zeitkritisch sind.
• iFrames sind eine lang bekannte Technologie, um andere Frontends zur Laufzeit einzubinden. Die wesentlichen Nachteile im Enterprise Kontext sind allerdings, dass kein direkter Datenaustausch mit dem iFrame Inhalt möglich ist und dass keine Lesezeichen für den Inhalt der iFrames gesetzt werden können. Ausserdem kann es dazu führen, dass responsives Design (Anpassung des Inhalts an den Bildschirm) nicht möglich ist.
• Integration von Web Components zur Build-Zeit: Web Components werden eigenständig entwickelt und zur Build-Zeit integriert. Sie sind eigentlich auch Micro Frontends und bieten Vorteile hinsichtlich Usability. Der Nachteil hier ist allerdings, dass sie eine starke Kopplung aufweisen und dies zu Fehlern bei der Build- oder noch schlimmer der Laufzeit führen kann.

Klein und oho: die Micro Frontends

Da, wo monolithische Ansätze beim Aufbau von komplexen Frontend-Anwendungen an ihre Grenzen kommen, können Micro Frontends helfen. Beispielsweise indem sie eine unbegrenzte Anzahl von Teams, Entwicklern und Features und minimale Abhängigkeit zueinander ermöglichen. Denn gerade grosse Vorhaben benötigen Skalierung und Flexibilität, um in kurzer Zeit (z.B. kurze time-to-market) und oft gleichzeitig Kundenbedürfnisse mit neuen Features adressieren zu können (siehe Abb. 2).

Lass uns hier ein wenig tiefer eintauchen und näher auf Micro Frontend Ansätze eingehen, die mit Webpack 5 ModuleFederationPlugin, ab Angular 14 mit Angular Module Federation oder Frameworks wie Single-SPA (https://single-spa.js.org/) umgesetzt werden.

High Level besteht eine Web-Anwendung im Micro Frontend Ansatz aus einem Rahmen und einer Reihe von unabhängigen, wenn nötig miteinander kommunizierenden Module. Nachfolgend die mögliche Strukturierung eines Kundenportals in Micro Frontends (siehe Abb. 3):

Mit Micro Frontends sollen die Schwächen der monolithischen Architekturansätze adressiert werden, indem Frontend-Komponenten unabhängig entwickelt, deployed und dem Benutzer zur Laufzeit ausgeliefert werden.
Feature-Teams von einer überschaubaren Grösse, die Effizienz sicherstellen, können fachlich geschnittene Module (z.B. aus der Motorfahrzeug-Domäne) entwickeln und stellen Frontend-Komponenten wie eine API zur Verfügung (z.B. Police-Detail-Ansicht).
Solche Komponenten (=Micro Frontends) werden vom Kundenportal-Team an der richtigen Stelle eingebunden, ohne dass sie die Inhalte genau kennen müssen. Für das Micro Frontend wird eine Schnittstelle definiert, die quasi einen Vertrag (nachfolgend Contract) darstellt, der vom übergeordneten Rahmen eingehalten werden muss. So bleiben die Micro Frontends resp. Teams sowohl in der Entwicklung, als auch im Releasing und Betrieb unabhängig.
Konkret verspricht der Micro Frontend Ansatz folgende Vorteile:

• Geringere Komplexität der Codebasis
• Unabhängige Deployments
• Unabhängige Teams
• Inkrementelle Upgrades

Als Konsequenz können Feature-Teams ihre End-to-End bzw. Full-Stack Verantwortung und Umsetzung (Front- und Backend) übernehmen und weitgehend unabhängig leben. Verschiedene Schnittführungen sind dabei denkbar, wie beispielsweise entlang von Branchen, Produkten, Marktsegmenten oder Nutzergruppen.

Die Realität zeigt: es funktioniert! 

Mit einigen unserer Kunden durften wir bereits den Micro Frontends Ansatz erfolgreich umsetzen. Nachfolgend zwei Beispiele.

Beispiel 1: Vertriebsportal für einen Nicht-Leben-Versicherer

Es wurde ein Vertriebsportal für Privatkunden-Versicherungen (Hausrat, Privathaftpflicht, etc.) und Motorfahrzeugversicherungen entwickelt. Für beide Branchen wurde je eine Offertierungsstrecke als Micro Frontend entwickelt und in ein Vertriebsportal eingebunden. Damit konnten mehrere Teams gleichzeitig entwickeln und die Abhängigkeiten reduziert werden.

Beispiel 2: Offertstrecken für eine Krankenkasse 

Für den eigenen Vertrieb und externe Makler wurde je ein eigenes Vertriebsportal entwickelt, um die spezifischen Anforderungen zu berücksichtigen. Trotzdem nutzen beide Portale eine gemeinsame Offertierungs-Komponente, welche als Micro Frontend umgesetzt wird. Durch die gemeinsame Komponente wird Doppelspurigkeit vermieden, Umsetzungsaufwand reduziert und eine einheitliche Benutzerfreundlichkeit erleichtert.