Microfrontends – das Ende der Monolithen?

Microfrontends – das Ende der Monolithen?

Während Microservices mittlerweile eine bewährte Strategie zur Vermeidung von Monolithen im Backend darstellen, wurde das Frontend in den meisten Fällen außer Acht gelassen. Durch das Microfrontend-Architektur-Pattern hat sich das nun endlich geändert. Doch Vorsicht – während im Allgemeinen die Analogie zu Microservices sinnvoll ist, gibt es durchaus ein paar Alleinstellungsmerkmale bei Microfrontends.

Microservices fürs Frontend?

Das Versprechen beim Einsatz von Microfrontends ist einfach: Die Vorteile von Microservices fürs Backend auch im Frontend einsetzbar machen. Einige sinnvolle Analogien kann man sicherlich schnell finden: So wird aus einem Gateway die Application Shell, die Kommunikation über Message Broker wird durch Events ersetzt. Doch dann wird die Luft schon dünner. Beispielsweise beschränkt sich der Einfluss der Verwendung verschiedener Technologien (Frameworks) nicht mehr exklusiv auf organisatorische Faktoren, sondern beeinflusst auch die Performance.

Im Allgemeinen ist eine der Schwierigkeiten beim Aufbau von Microfrontend-Anwendungen, die richtige Mischung aus der puristischen Perspektive (die jedem Microfrontend volle Freiheit gewährt) und dem klassischen Monolithen (mit wohldefinierten Technologievorgaben) zu finden. In vielen Fällen fällt daher die richtige Wahl auf den „Modulithen“. Der Begriff des Modulithen wurden bei Microservice Backends bereits eingeführt. Hier definiert ein Modulith einen Monolithen, der bereits eine Architektur umsetzt, welche sich durch lose Kopplung in Form von Modulen dynamisch erweitern lässt.

Bei Microfrontends können wir uns dem zu Nutze machen: Der Monolith wird durch die Application Shell abgelöst, welche neben einigen gemeinsam genutzten Bibliotheken auch eine Pattern Library bereitstellt. Der Vorteil: Alle Module können die gemeinsamen Ressourcen nutzen und können somit beliebig klein gemacht werden. Der Nachteil: Über die Application Shell können (unwissend) brechende Änderungen durch die Aktualisierung von gemeinsamen Bibliotheken eingeführt werden.

Das folgende Diagram skizziert die Relation der Microfrontends mit der Application Shell.

Vorhandene Lösungen

Wie bei jedem Trend so ist auch bei Microfrontends die Lösungslandschaft vielschichtig und noch nicht vollkommen ausgereift. Wer gerne auf React für die Application Shell zurückgreift und eine hochinteraktive Applikation (beispielsweise für ein digitales Serviceportal) erstellen möchte, kann auf Piral (piral.io) zurückgreifen. Der Vorteil: Piral ist serverless-first und developer-first.

Eine sehr einfache und flexible Gestaltung ist hier ohne weiteres möglich. Unabhängige Deployments werden durch einen dedizierten Service garantiert, welcher für die Auslieferung der Module zuständig ist. Mit Hilfe von Feature Flags können dadurch einzelne Funktionalitäten dynamisch zur Laufzeit freigeschaltet bzw. deaktiviert werden.

Bei Mosaic (mosaic9.org) werden die Anforderungen für ein Mircofrontend vorwiegend im Backend abgebildet. Hierfür sind einige Änderungen im Backend erforderlich, zum Beispiel müssen Feature Flags und andere Spezialfälle in den entsprechenden Backend Services nachgerüstet werden. Ein weiterer Nachteil ist die erhöhte Schwierigkeit, ein zuverlässiges lokales Setup zum Testen der Microfrontends aufzubauen.

Eine andere Möglichkeit ist Luigi (luigi-project.io). Hier wird ein ähnlicher Ansatz wie bei Piral verfolgt, allerdings ohne Basisframework und ohne erweitertes Tooling. Stattdessen wird eine Reihe von Bashskripten verwendet. Ein Service, um die verschiedenen Module zu liefern, ist momentan nicht vorhanden – im einfachsten Fall (bekannte Module) kann dies auch hardkodiert werden. Nachdem die verschiedenen Module nicht – wie bei Piral – isoliert voneinander laufen, wird auf die Application Shell direkt über das window Objekt zugegriffen.

Fazit

Microfrontends stellen eine spannende Alternative für den Aufbau großer Webanwendungen dar. Für kleine und mittlere Anwendungen mit fixem Scope ist der Overhead allerdings unnötig. Bei der Technologieauswahl sollte man durchaus konservativer sein als bei Microservices und sich falls möglich auf eine Technologie festlegen. Die User-Experience sollte hier in jedem Fall im Vordergrund stehen.