Micro Frontends

Der Begriff micro frontends wurde erstmals im Technlogy Radar Volume 24 von Thoughtworks erwähnt. Im Zuge der immer stärkeren Verbreitung von microservices konnten viele Vorteile im Backend hinzu gewonnen werden, jedoch blieben viele Probleme im Frontend bestehen.

Die Grafik verdeutlicht, dass trotz microservices ein wesentlicher Bestandteil einer Web-Anwendung monolithisch bleibt. Während im Backend, dargestellt durch die microservices, moderne Arbeitsweisen, Skalierbarkeit, Verfügbarkeit und autonomes Arbeiten unterschiedlicher Teams eingeführt bzw. optimiert werden können, entwickelt sich das Frontend unter Umständen zu einem extremen Flaschenhals.

Egal wie Teams aufgebaut sind, beim Frontend führt die Integration der microservice Funktionalitäten zu einem organisatorischen Aufwand, der mit steigender Größe der Gesamtanwendung, zunehmend größer wird. Zudem unterliegen technische Aspekte wie Skalierbarkeit und Verfügbarkeit des Frontends denselben Problemen wie in einer gesamtmonolithischen Architektur. So hat beispielsweise die Last einer Teilfunktion des Frontends einen Einfluss auf die Performance des gesamten Frontends. Dies wiederum kann einen Einfluss auf die Verfügbarkeit des gesamten Frontends haben usw.

Es sind sicherlich nicht nur diese Aspekte, die u.a. bei Thoughtworks zu einem gewissen Umdenken geführt haben. Abstrakt betrachtet, ist die Einführung von micro frontends die logische Evolution der microservices. Die Funktion eines microservices wird hierbei im eigenen micro frontend abgebildet. Die Summe aller micro frontends bildet am Ende die gesamte Anwendung.

Die vorangehende Grafik visualisiert den Gedanken eines Frontends, basierend auf einer micro frontend Architektur. Das gesamte Frontend besteht aus einer Vielzahl von micro frontends, die entweder alle gleichzeitig oder nach Bedarf integriert werden. Vom Verständnis her ist ein micro frontend allerdings ein fester Bestandteil des jeweiligen microservice und beide zusammen bilden eine Einheit.

Dadurch ergeben sich viele Vorteile, die bereits microservice Architekturen mit monolithischen Frontends mit sich brachten. So sind Aspekte der verteilten Skalierbarkeit, Verfügbarkeit, autonomes Arbeiten in unterschiedlichen Teams, eigene Code Repositories bis hin zum Einsatz unterschiedlicher Web-Frameworks in den jeweiligen micro frontends möglich oder anwendbar. Wer wissen möchte, wie eine existierende, Monolithische Anwendung in eine Microservices Architektur überführt werden kann, der schaut in unseren Blogbeitrag Vom Monolithen zum Microservice an.

Allerdings ist anzuführen, dass sich an anderen Stellen im Frontend der Aufwand erhöhen kann. Ein Beispiel dafür ist die Authentifizierung, die innerhalb eines monolithischen Frontends „überall“ gilt. In der micro frontend Architektur müssen unter Umständen neue Wege gegangen werden, damit ein Anwender innerhalb eines micro frontends identifiziert werden kann. Wie genau eine Umsetzung erfolgt, ist nicht klar geregelt und von der Gesamtsituation abhängig.

Eine intern praktizierte Lösung ist die Authentifizierung über Identity Provider in der Cloud. Mit der Authentifizierung beim Aufrufen der Startseite werden Informationen über den Anwender eingeholt und weitere Daten, mittels welcher die Authentifizierung dieses Anwenders ohne Interaktion innerhalb des jeweiligen micro frontends ermöglicht werden.

Wie funktioniert jedoch die Integration einzelner micro frontends in ein gesamtes Frontend? Kurz gesagt: Es gibt nicht DEN Weg. Was (fast) alle Wege gemeinsam haben, ist die Zusammenführung in einem gesamten Frontend, welches idealerweise lediglich eine Art Container ohne jegliche Logik zur Verfügung stellt. Diese Zusammenführung kann bereits im Build Prozess erfolgen, oder auch zur Laufzeit (Runtime Integration). Welcher Ansatz gewählt wird, hängt von den Anforderungen und Präferenzen ab.

Im Folgenden wird auf die Runtime Integration mit Hilfe des single-spa Frameworks eingegangen. Das Framework behauptet von sich, es biete eine erweiterte micro frontend Architektur. Für die Zusammenführung der micro frontends ist eine root config notwendig. Innerhalb dieser werden alle micro frontends registriert und je nach Aufbau direkt oder on demand integriert. Das Framework baut dabei auf die importmap Funktion des Dynamic ES Module Loaders SystemJS, daher auch der Bezug zur Integration während der Laufzeit.

Eine Voraussetzung für die dynamische Integration eines micro frontends ist das zur Verfügungstellen dreier Methoden (bootstrap, mount und unmount) in dem micro frontend, mittels welcher die root config dieses micro frontend (ent-)laden kann.

Ein micro frontend wird innerhalb von single-spa als Application verstanden und muss in eine einzelne Javascript Datei gepackt werden. Welcher Packer verwendet wird, ist dabei irrelevant. Das Framework single-spa bietet bereits etliche Node packages, die über das CLI auf das jeweilige micro frontend angewendet werden können. Viele populäre Web-Frameworks werden bereits unterstützt. Es besteht aber auch die Möglichkeit das micro frontend manuell für eine Integration als single-spa Application vorzubereiten.

In den Beispielen der single-spa Dokumentation basiert die root config häufig auf simplem HTML. Es ist aber durchaus möglich auch die root config mit einem Web-Framework zu bauen.

Warum sollte man dies tun, wenn die root config nur eine Art Container ohne Logik sein soll? Ein Beispiel dafür ist die Art der Integration eines micro frontends. Diese erfolgt im Standard via Page Refresh. Wenn allerdings ein Ladeverhalten wie in einer monolithischen Single-Page Application gewünscht ist, spricht nichts dagegen ein Web-Framework in der root config zu verwenden, welche genau diese Eigenschaft bietet.

Ob und wie micro frontends benutzt werden, ist stets situationsabhängig. Bei sehr kleinen Anwendungen oder einer schlecht umgesetzten microservice Architektur macht es eher keinen Sinn, weil der Aufwand unter Umständen dem Nutzen nicht gerecht oder sehenden Auges in technische Schulden gerannt wird.