© rozmarin/shutterstock.com
Ihr 6+1-Punkte-Plan zur Erstellung einer Microfrontend-Shell

Der Teil und das Ganze


Microfrontends sind derzeit ein viel diskutiertes Thema. Nach dem Vorbild von Microservices wird dabei ein großes Frontend auf mehrere kleine aufgeteilt. Dadurch sollen einzelne Teams autark arbeiten und sogar eigene Technologieentscheidungen treffen können. Während diese Idee im Kern simpel ist, ist es die konkrete Umsetzung leider nicht. In diesem Artikel fasse ich die in verschiedenen Projekten gesammelten Erfahrungen in 6 + 1 Punkten zusammen und zeige, wie sich eine Microfrontend-Shell umsetzen lässt.

Bei unserem Beispiel handelt es sich um eine Anwendung, die bei Bedarf die einzelnen Microfrontends lädt (Abb. 1). Anwender erhalten so den Eindruck, mit einer großen, integrierten Softwarelösung zu arbeiten. Den Quellcode dafür stelle ich in meinem GitHub-Account [1] zur Verfügung.

steyer_angular_1.tif_fmt1.jpgAbb. 1: Shell, die ein Microfrontend (rot umrahmt) geladen hat

Vorbedingungen

Alle Architekturstile haben bekanntlich ihre speziellen Vor- und Nachteile – das gilt auch für Microfrontends. Zudem erfordern diese einen gewissen Mehraufwand, weil die aktuellen Frameworks nicht auf sie ausgerichtet sind. Doch zunächst ein paar Vorteile:

  • Teams werden entkoppelt.

  • Teams können autark arbeiten und eigene Technologie- sowie Architekturentscheidungen treffen.

  • Separates Deployment: Teams müssen nicht aufeinander warten, bis sie ein neues Feature in Produktion setzen können.

Wie man sieht, geht es bei Microfrontends besonders um organisatorische Aspekte. Man erhofft sich mehr Agilität, indem jedes Team möglichst autark arbeiten kann. Ein angenehmer Nebeneffekt ist, dass einzelne Programmteile mit verschiedenen Technologien gebaut werden können. Das macht niemand, weil es hip ist, sondern weil große Softwaresysteme mit einer Lebensdauer von 10 bis 20 Jahren oder mehr so manche Technologie überleben.

Wenn diese Ziele nicht entscheidend für den Erfolg der Softwarelösung sind, sollte man sich allerdings gut überlegen, ob man die negativen Seiten dieses Architekturstils im Kauf nehmen möchte. Zu den Nachteilen gehören die folgenden Aspekte:

  • Keine Framework-Unterstützung: Aktuelle SPA Frameworks sind nicht auf Microfrontends ausgelegt. Teams müssen sich diese Unterstützung selbst bauen, was sowohl eine tiefe Kenntnis der eingesetzten Frameworks als auch der JavaScript-Plattform an sich erfordert.

  • Abhängig von der gewählten Implementierungsvariante können sich größere Bundles ergeben.

Die größeren Bundles folgen unter anderem daraus, dass jedes Microfrontend seine eigenen Frameworks mitbringen kann.

Eine Voraussetzung für Microfrontends ist, dass man die jeweilige Anwendung in verschiedene, möglichst autarke Teile trennen kann. Domain-driven Design bezeichnet diese Teile als Subdomänen. Diese Bedingung erfüllen u. a. alle Produkte, die man auch als Produktsuite betrachten könnte. Ein Paradebeispiel ist für mich ein Enterprise-Resource-Planning-System (ERP) (Abb. 2): Finanzbuchhaltung, Anlagenbuchhaltung, Kostenrechnung und Personalverrechnung sind möglichst unabhängig voneinander. Ab und an müssen zwar Daten von einem Teil in den anderen übernommen werden, aber solche Schnittstellen kennen wir auch von anderen Systemen.

steyer_angular_2.tif_fmt1.jpgAbb. 2: Subdomains in einem ERP-System

Ein Beispiel, das wir alle kennen, ist Office365 (Abb. 3). Auch hier lässt sich jeder Bestandteil als separate SPA nutzen. Interessant ist, dass sogar Outlook in mehrere Anwendungen aufgesplittet wurde, die jeweils eine eigene Subdomäne widerspiegeln: E-Mail-Client, Kontakte, Kalender und Tasks.

steyer_angular_3.tif_fmt1.jpgAbb. 3: Aufgesplittet: Office365

Schritt 1: Komposition

Während das Unterteilen eines Systems in viele kleine Anwendungen für Entwicklungsteams Vorteile bringen kann, sind Anwender darüber häufig nicht erfreut. Sie wollen nämlich nicht ständig eine neue Anwendung öffnen müssen, sondern erwarten ein integriertes Benutzererlebnis. Der einfachste Ansatz hierfür ist der Einsatz von Hyperlinks wie im Fall von Office365 (Abb. 3). Diese Vorgehensweise ist sehr einfach zu realisieren und sollte nach Möglichkeit bevorzugt werden. Sie ist allerdings nur dann sinnvoll, wenn sich die meisten Anwendungsfälle komplett in einem Microfrontend befinden. Ein etwas komplexerer Ansatz ist die Bereitstellung einer Shell, die die einzelnen Microfrontends bei Bedarf lädt (Abb. 4).

steyer_angular_4.tif_fmt1.jpgAbb. 4: Eine Shell lädt die einzelnen Microfrontends

Eine Lösung dafür ist das dynamische Laden und Aktivieren der Micro Frontends innerhalb einer Seite. Da es dafür derzeit keine guten Meta-Frameworks gibt, muss man sich um diese Aufgabe manuell kümmern. Dazu muss man direkt mit dem DOM interagieren. Wie bei Frameworks üblich, sollte man die Implementierungsdetails in einzelnen Klassen und Funktionen verstecken – ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang