© Liashko/Shutterstock.com
Micro Frontends bringen die Idee von Microservices ins Frontend

Vom Backend ins Frontend


Micro Frontends oder auch Micro Apps werden in letzter Zeit häufiger diskutiert. Nachdem Microservices-Architekturen im Backend wachsenden Anklang finden, schwappt dieser Architekturansatz auch immer öfter ins Frontend. Das erste Mal wurden Micro Frontends im ThoughtWorks Technology Radar Ende 2016 erwähnt. Seit dieser Zeit haben sich zahlreiche Bibliotheken und Hilfsmittel rund um diesen Architekturansatz entwickelt.

Vor dem Einsatz dieser Architekturform sollten Sie sich fragen, ob Micro Frontends die richtige Lösung für Ihre Applikation sind. Analog zum Blogartikel von Dan Abramov zum Einsatz der State-Management-Bibliothek Redux „You might not need Redux“ steht auch vor der Implementierung einer Applikation mit Micro Frontends die Aussage „You might not need Micro Frontends“ im Raum. Diese Architekturform hat ihre Vor- und Nachteile, die Sie gegeneinander abwägen sollten. Die Micro-Frontend-Architektur stellt eine grundlegende Architekturentscheidung dar. Diese im Nachhinein umzustellen, gestaltet sich aufwendig.

Der Gegenentwurf zu einer Micro-Frontend-Architektur ist der klassische Monolith. Eine monolithische Applikation besteht aus einer zusammenhängenden Codestruktur. Das muss jedoch nicht zwingend bedeuten, dass es sich um unstrukturierten Spaghetticode handelt. Ein moderner Monolith weist eine modulare Struktur auf, sodass auch hier zahlreiche Vorteile einer Services-Architektur, wenn auch in abgeschwächtem Ausmaß, greifen. Das Ziel von Modularisierung und auch von Micro Frontends ist, in sich geschlossene Teile einer Applikation zu isolieren. Im Backend geht die Microservices-Architektur einen Schritt weiter und entkoppelt die einzelnen Module vollständig voneinander, sodass einzelne Prozesse entstehen, die getrennt voneinander entwickelt, veröffentlicht und gewartet werden können. Mit Micro Frontends halten viele dieser Vorteile auch Einzug ins Frontend.

Die Vorteile von Micro Frontends

Einer der Vorteile von Microservices im Backend ist, dass Sie diese Services unabhängig voneinander skalieren können, indem Sie zusätzliche Instanzen der Services hochfahren. Dieses Feature ist bei Microservices im Frontend nicht relevant, da es sich bei den Services nicht um Prozesse, sondern mehr um eigenständige Bausteine des Frontends handelt.

Micro Frontends spielen ihre wahre Stärke in der Entkopplung dieser Bausteine über die Grenzen einer bloßen Modularisierung aus. Die einzelnen Micro Frontends können ihre eigenen Technologiestacks und internen Architekturen aufweisen. Eine Applikation mit einer Micro-Frontend-Architektur kann sich also beispielsweise aus einem Angular Frontend, einem React Frontend und einem Vue Frontend zusammensetzen. Jedes dieser Frontends kann von einem eigenständigen Team umgesetzt werden. Damit lassen sich komplette Featureteams realisieren, die sich vom Backend bis zum Frontend durchziehen. Jedes Team ist damit in der Lage, Features in ihrer Gesamtheit umzusetzen und zu releasen, ohne dass die übrige Applikation in Mitleidenschaft gezogen wird.

Die Schattenseiten von Micro Frontends

Im Gegensatz zu einem modularisierten Frontend-Monolith, dessen Kern in der Regel eine Bibliothek bildet, kann sich eine Applikation mit Micro Frontends aus verschiedenen Bibliotheken zusammensetzen. Dem Vorteil der technischen Freiheit steht hier der entscheidende Nachteil eines deutlich erhöhten Transfervolumens entgegen. Diesem Nachteil kann zum Teil durch die Optimierung der Pakete, Komprimierung der Übertragung und Lazy Loading entgegengewirkt werden.

Nicht nur das erhöhte Volumen, sondern auch potenziell stark unterschiedliche Strukturen in den einzelnen Teilen der Applikation stellen ein Problem dar. So wird der Wechsel zwischen den Micro Frontends durch unterschiedliche Architekturansätze oder die Verwendung verschiedener Frameworks erschwert. Dies macht sich gerade dann bemerkbar, wenn die verschiedenen Teile des Frontends von einem Team gewartet werden müssen. Die Entwickler müssen dann den Überblick über die verschiedenen Technologien und ihre Eigenheiten haben. Diesem Problem können Sie in Ihrer Applikation durch Konventionen und eine strikte Qualitätskontrolle begegnen. Durch Vorgaben hinsichtlich Technologien und Bibliotheken schränken Sie zwar die Freiheit der Entwickler etwas ein, die Wartbarkeit der Applikation wird dadurch jedoch potenziell erhöht.

Zu guter Letzt bringt die Micro-Frontend-Architektur selbst noch den Nachteil einer erhöhten Gesamtkomplexität der Applikation mit sich. Der Grund hierfür liegt darin, dass eine Basis für die Micro Frontends geschaffen werden muss. Serverseitig werden Microservices meist in Containern deployt und von einer Softwarekomponente orchestriert. Clientseitig stellt der Browser die Laufzeitumgebung der Micro Frontends dar. Diese müssen in eine zentrale HTML-Seite eingebunden werden, damit ein Benutzer mit der Applikation interagieren kann. Für die Integration der verschiedenen Frontend Services existieren verschiedene Ansätze, von denen ich Ihnen einige im Laufe dieses Artikels vorstellen möchte. Allen Lösungen ist gemein, dass sie eine mehr oder weniger umfangreiche Abstraktionsschicht erforderlich machen.

Vorbedingungen

Angesichts der Nachteile einer Micro-Frontend-Architektur sollten Sie eine solche Architekturentscheidung nicht leichtfertig treffen. Ihre Applikation sollte zumindest einige Anforderungen erfüllen.

  • Umfangreicher Funktionsumfang: Wegen der erhöhten Komplexität spielt eine Micro-Frontend-Architektur ihre Vorteile erst ab einem bestimmten Funktionsumfang aus. Je größer die Applikation und je mehr gut voneinander abgrenzbare Features sie aufweist, desto besser.

  • Getrennte Entwicklungsteams: Mit Micro Frontends lassen sich Microservices von der Datenbank über das Backend bis ins Frontend umsetzen. Den Teams wird dadurch ein hohes Maß an Autonomie zugesprochen und auch Releases können unabhängig voneinander erfolgen.

  • Unterschiedliche Technologien und Bibliotheken: Häufig lassen sich Probleme durch spezialisierte Lösungen besser lösen. Eine Micro-Frontend-Architektur gewährt hier deutlich mehr Freiheiten als ein monolithischer Ansatz.

Mögliche Lösungsansätze

Die zahlreichen Lösungsansätze unterscheiden sich durch die verwendeten Technologien, den Aufwand bei der Umsetzung und die Integrierbarkeit der verschiedenen Lösungen. Grundsätzlich können mehrere Frameworks und Bibliotheken auf einer HTML-Seite eingebunden werden. Der Nachteil ist, dass die Build-Prozesse der einzelnen Lösungen nicht hierauf ausgerichtet sind und es gerade bei komplexeren Applikationen zu Problemen kommen kann. Auch die Integration der einzelnen Applikationen kann aufwendig sein.

Mehrere Applikationen über iFrames einbinden

Geht es nur darum, mehrere Frameworks auf einer Seite zu betreiben, ist der einfachste Ansatz die Verwendung von iFrames. Ein iFrame erlaubt die Einbindung einer HTML-Seite in eine andere. Dabei kann die eingebundene Applikation nicht direkt auf den Kontext der Basisapplikation zugreifen, sie wird also in einer Art Sandbox ausgeführt. Eine einfache Kommunikation zwischen beiden Applikationsteilen ist über Nachrichten möglich. Bei dieser Lösung bleiben die einzelnen Micro Frontends der Applikation vollständig u...

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