Micro-Frontends: Die bessere Art User Interfaces zu implementieren? Teil #3

Im ersten und zweiten Teil der Blogreihe hatten wir bereits die Idee hinter Micro-Frontends erläutert und haben verschiedene Ansätze vorgestellt. In diesem Teil wollen wir noch drei weitere Ansätze diskutieren: das Single-SPA Metaframework, Project Mosaic von Zalando und den WebComponents Ansatz. Danach sollen alle in dieser Serie vorgestellten Varianten kurz verglichen und ein abschließendes Fazit gezogen werden.

Single-SPA Metaframework – CanopyTax

Beim ‚single-spa'-Framework von Canopy-Tax können mehrere SinglePageApplications (SPA) bei einer Root-Applikation registriert werden. Das Ergebnis soll sich weiterhin wie eine SPA anfühlen. Eine Child-Applikation muss folgende Eigenschaften erfüllen.

Sie muss...

... auf Routingevents reagieren
... wissen wie sie sich in den DOM mounted
... wissen wie sie sich bootstrapped
... wie sie sich vom DOM entfernt

Eine Child-Applikation kann also aktiv sein, ist somit sichtbar und reagiert auf Routingevents, oder aber sie ist inaktiv und wird dann aus dem DOM-Baum entfernt. Das ermöglicht es einzelne UI-Komponenten in verschiedenen Technologien zu implementieren, löst aber nicht das Problem der möglichen Technologieunverträglichkeit. Das Routing wird hier teilweise durch die Micro-Frontends selbst übernommen – das kann aber schnell unübersichtlich werden.

Project Mosaic – Zalando

     Abbildung 1https://www.mosaic9.org/

Abbildung 1https://www.mosaic9.org/

Project Mosaic heißt das Micro-Frontend-Framework von Zalando. Es besteht aus mehreren Softwarekomponenten von denen die wichtigsten Bausteine als Open-Source verfügbar sind.

Aus diesem high-level Architekturbild sind die Komponenten Skipper, InnKeeper und Tailor als Open-Source verfügbar.

Skipper übernimmt dabei das Routing zu verschiedenen Micro-Frontends. Das hört sich beim ersten Mal eher nach einem Multi-Page=Multi-App-Ansatz an, allerdings wird hier nicht nur an einzelne Anwendung weitergeleitet sondern über das Tool Tailor können auch mehrere Micro-Frontends auf einer Seite vereinigt werden. Einfach ausgedrückt ist es ein ähnlicher Ansatz wie bei der ‚single-spa'-Lösung von CanopyTax aber um einen vorgelagerten Router erweitert. Das Problem der möglichen Technologieunverträglichkeiten ist auch hier nicht gelöst. Die im Tailor definierten Templates können mit allgemein gültigen JavaScript und CSS angereichert werden. Jedes Micro-Frontend ist aber in der Lage ein Applikations-JavaScript und ein Applikations-CSS auszuliefern. Die einzelnen Micro-Frontends werden separat gehostet und durch Tailor an den Endbenutzer gestreamt. Wie die Inter-App-Kommunikation stattfindet wird nicht geklärt. Wahrscheinlich ist es eine Mischung aus Backend-Services und Browser-Events. Das Hosting der Micro-Frontends ist etwas umständlich, denn mit dem HTML-Content wird das referenzierte JavaScript und CSS als Fragment-Link im HTTP-Header ausgeliefert. Die einzelnen Fragmente können dafür auch asynchron geladen werden.

WebComponents

Wenn man sich die Definition von WebComponents durchliest, kommt dem Leser fast unweigerlich die Idee in den Kopf damit Micro-Frontends umzusetzen.

"Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. [...] Features to support web components are currently being added to the HTML and DOM specs, letting web developers easily extend HTML with new elements with encapsulated styling and custom behavior."
https://www.webcomponents.org/introduction

Die Bausteine Shadow DOM, Custom Elements, HTML Imports und HTML Template erinnern ebenfalls an bisherige Lösungsansätze. Die bisher schlechte Browserunterstützung scheint den Siegeszug von WebComponents noch zu verhindern. Eine Handvoll Tools und Libraries, wie Stencil.js, Polymer oder Bosonic helfen bei der Implementierung von WebComponents. Probleme wie Routing und Inter-Komponenten-Kommunikation werden von WebComponents nicht direkt adressiert und müssen selbst überwunden werden. Im Gegenzug orientiert man sich an einem Standard.

Abschließender Vergleich

Wenn man sich alle Implementierungen von Micro-Frontends ins Gedächtnis ruft und bewerten möchte, kommt man, wie so häufig, zu der Erkenntnis, dass es keine perfekte Lösung gibt. Alle Lösungsansätze haben ihre Stärken und Schwächen. iFrames und „Multi-Page=Multi-App“ können sehr gut mit unterschiedlichen Technologien umgehen, wohingegen „Black Box React Components“ auf eine spezielle Technologie zugeschnitten ist. Single-SPA und Project Mosaic sind proprietäre Lösungen, die ihre Stärken in der Performance oder im Routing innerhalb der Webanwendung haben, wohingegen ESI-Lang und WebComponents sich an alten oder neuen Standards orientieren. Die vorgestellten Lösungsansätze sind nicht erfinden das Rad nicht neu sondern bedienen sich an Ideen anderer Implementierungen und versuchen so einen möglichst guten TradeOff zu bieten.

Fazit & weiterführende Informationen

Persönlich gefällt mir „Project Mosaic“ von Zalando am besten, die Aufteilung in kleine spezialisierte Unterkomponenten, die durch einen Proxy gebündelt werden und letztendlich im Browser des Nutzers zusammenfinden, machen einen eleganten Eindruck. Die am einfachsten nachvollziehbaren Lösungen sind hingegen die Nutzung von iFrames und der Multi-Page=Multi-App-Ansatz aus dem zweiten Teile unserer Blogserie. Trotzdem muss man sich genau überlegen ob man Micro-Frontends einsetzen möchte. Sie ermöglichen es einem Team die Verantwortung über einen Teil der Anwendung vom Frontend bis zum Backend zu übernehmen. Der Preis dafür ist eine nicht zu unterschätzende Komplexität bei der Integration und der Sicherstellung eines einheitlichen Look&Feels. Das zahlt sich erst aus, wenn viele Teams an derselben Webanwendung arbeiten.

Quellen und weiterführende Literatur: