Die meisten Entwickler haben bereits von der Microservice-Architektur gehört, aber „Micro-Frontend“ ist ein viel weniger geläufiger Begriff. Wie der Name schon sagt, ähnelt das Konzept des Micro-Frontend dem von Microservices. Es soll viele der Probleme lösen, die auch monolithische Anwendungen darstellen. Sie sind zu groß, schwer in der Handhabung und schwer zu ändern. Die Einarbeitung neuer Benutzer kann mühsam sein. Wenn mehrere Teams an verschiedenen Teilen der Anwendung arbeiten, müssen sie außerdem alle Änderungen miteinander koordinieren.
Mit Microservices können Sie das Backend in mehrere unabhängige Services aufteilen. Derselbe Ansatz kann verwendet werden, um Single-Page-Anwendungen (SPAs) in kleinere Anwendungen aufzuteilen, wobei zusätzlich ein „Orchestrator“ benötigt wird, der die verschiedenen Teile wieder zusammenfügen kann, sodass der Benutzer weiterhin das SPA-Verhalten erlebt.
Was sind die Alternativen zu einer Micro-Frontend-Architektur?
Natürlich gibt es auch andere Möglichkeiten, mit einigen unerwünschten Aspekten riesiger Anwendungen umzugehen, wie z. B. das Abtrennen eines Teils des Codes in ein eigenes NPM-Paket. Dadurch kann ein Teil des Problems gelöst werden, z. B. dass das Repository zu groß ist. In Angular beispielsweise kann man den Code auch in ein Modul aufteilen, das per „Lazy Loading“ geladen werden kann. Dies kann es bis zu einem gewissen Grad ermöglichen, die Anwendung vertikal aufzuteilen. Aber es hat auch seine Nachteile, wie z. B. die Notwendigkeit, das Top-Level-Projekt zu erstellen, wenn eine der Abhängigkeiten aktualisiert wird. Außerdem ist die Erfahrung für Entwickler nicht besonders gut. Wenn man ein Framework verwendet, ist es ratsam, alles auf die gleiche Version zu aktualisieren, aber das ist ein großes Unterfangen, das niemand gerne unternimmt. Sie haben auch die Möglichkeit, mehrere Anwendungen per iframe zu verbinden. Dadurch werden sie unabhängig, vielleicht allerdings zu unabhängig, denn die Kommunikation zwischen den Anwendungen stellt ein Problem dar, ebenso die gemeinsame Nutzung von Code, Stilen usw.
Micro-Frontends als Rettung in der Not?
Bei Micro-Frontends werden diese zwei Ansätze miteinander kombiniert. Jedes Micro-Frontend ist eine separate Anwendung, die im Vergleich zur SPA einfacher ist. Es wird nicht in einer index.html mit verknüpften Skript- und Stildateien kompiliert, sondern in einem JavaScript-Modul. Anstelle eines iframe in der „Haupt“-App legt Code fest, dass das Modul, wenn die URL einem bestimmten Muster entspricht, per „Lazy Loading“ geladen und an einer bestimmten Stelle platziert wird. Dadurch können wir mehrere Anwendungen auf derselben Seite haben, die miteinander verbunden werden können.
Deshalb müssen Micro-Frontends nicht das App-Layout und grundlegende CSS-Regeln verarbeiten, die nur in der Hauptanwendung verarbeitet werden können. Ebenso vorteilhaft ist die Tatsache, dass man, wenn man mehrere Micro-Frontends nutzt, die dieselbe Version von React verwenden, diese das React-Modul gemeinsam nutzen lassen kann. Es muss nicht für jedes Micro-Frontend einzeln heruntergeladen werden. Wenn man verschiedene Versionen eines JS-Moduls nutzt, ist das auch kein Problem.
Das Hauptproblem bei Micro-Frontends besteht darin, sicherzustellen, dass ihre Stile nicht auf andere Teile der Anwendung übergreifen. Glücklicherweise verfügen die meisten gängigen UI-Frameworks über Tools, mit denen sich dies problemlos handhaben lässt.
Tools für Micro-Frontend-Architekturen
Es wäre eine ziemlich große Aufgabe, eigenen Code zum Laden von Micro-Frontend-Anwendungen zu schreiben. Glücklicherweise gibt es mehrere Frameworks, die die Orchestrierung übernehmen und Tools anbieten, um Anwendungen, die in den gängigsten Frameworks geschrieben wurden, in das Micro-Frontend-Format zu konvertieren.
Bei Pure verwenden wir single-spa. Die wichtigsten Vorteile von single-spa, die wir festgestellt haben, sind, dass es leicht zu verstehen ist, breite Unterstützung für JS-Frameworks bietet und detailliert dokumentiert ist. Darüber hinaus bietet single-spa mehrere Micro-Frontend-Typen an, die jeweils für leicht unterschiedliche Aufgaben geeignet sind.
Derzeit verwenden wir nur den Typ „Application“ (Anwendung), weil er für Wechsel von SPA auf Micro-Frontends am einfachsten zu verwenden ist. Andere Typen erfordern auch eine detailliertere Micro-Frontend-Architektur. Außerdem wird „Application“ von den single-spa-Autoren als Standardtyp empfohlen.
