Microfrontends unter Realbedingungen

Vor einigen Jahren, als der Hype um Microfrontends Fahrt aufnahm, blieb ich an einer Formulierung hängen:

TRUE independent teams

TRUE war tatsächlich vollständig großgeschrieben.

Das klang verdächtig nach Marketing. Trotzdem hat mich der Satz beschäftigt. Denn echte Unabhängigkeit von Teams ist ein starkes Architekturversprechen. Nicht nur technisch, sondern auch organisatorisch: Ein Team versteht sein System, verändert es, testet es, veröffentlicht es und betreibt es, ohne für jeden Schritt auf den Rest der Plattform warten zu müssen.

Ich begann, mich intensiver mit Microfrontends und den Konzepten dahinter zu beschäftigen. Dabei habe ich unter anderem viel von Manfred Steyer und Rainer Hahnekamp gelesen. Je länger ich mich mit dem Thema befasste, desto weniger interessant wurde für mich allerdings die Frage, wie man das erste Remote lädt.

Interessanter wurde, was danach passiert.

Kein weiteres Getting Started

Diese Serie ist keine Anleitung nach dem Muster:

So baust du einen Host und drei Remotes.

Wer Microfrontends oder Module Federation mit Nx technisch aufsetzen möchte, findet dafür eine offizielle Anleitung in der Nx-Dokumentation.

Die technische Initialisierung ist der vergleichsweise einfache Teil. Generatoren und vorhandene Integrationen übernehmen viele Details, die in einer handgeschriebenen Konfiguration schnell unsichtbar werden.

Mein Rat aus Erfahrung: Schreib dafür nicht vorschnell eine eigene Konfiguration.

Das heißt nicht, dass jede individuelle Lösung zwangsläufig scheitert. Aber eine Sonderkonfiguration braucht einen guten Grund. Sonst entsteht aus wenigen vermeintlich einfachen Einstellungen eine dauerhafte Wartungsaufgabe mit eigenen Kompatibilitätsproblemen.

Diese Serie beginnt deshalb nicht beim ersten erfolgreichen Build.

Sie beginnt dort, wo der Host läuft und die einfachen Folien aufhören.

Unabhängigkeit unter Realbedingungen

Unter Realbedingungen reicht es nicht, Code in getrennte Remotes zu legen.

Dann stellen sich andere Fragen: Was bedeutet Unabhängigkeit wirklich? Welche Abhängigkeiten entstehen trotzdem? Wie gehen Teams mit unterschiedlichen Frameworks oder Framework-Versionen, gemeinsamer UI, Authentifizierung und unabhängigen Releases um? Wie entwickelt ein Team sein Remote, ohne die gesamte Plattform lokal zu starten? Und welchen Preis hat die gewonnene Autonomie?

Die Serie betrachtet reale Anforderungen und Architekturprobleme, typische Antipatterns, Runtime-Integration und die technischen, organisatorischen und wirtschaftlichen Konsequenzen unabhängiger Auslieferung. Sie folgt unabhängig ausgelieferten Frontends durch Entwicklung, Test, Release und Betrieb.

Dabei geht es auch um den Unterschied zwischen echter und nur behaupteter Unabhängigkeit.

Ein Frontend wird nicht allein dadurch unabhängig, dass sein Code in einem eigenen Remote liegt. Entscheidend ist, ob Teams ihre Systeme eigenständig verstehen, verändern, testen, veröffentlichen und betreiben können.

Das Ergebnis muss nicht immer ein Microfrontend sein.

Manchmal ist es sinnvoll, ein Feature bewusst zweimal zu bauen. Manchmal ist eine gemeinsame Abstraktion teurer als die Duplikation. Manchmal ist ein modularer Monolith die bessere Architektur. Manchmal ist die zusätzliche Autonomie wirtschaftlich schlicht zu teuer.

Microfrontends sind weder grundsätzlich überlegen noch grundsätzlich falsch.

Sie sind eine Architekturentscheidung mit Konsequenzen.

Um diese Konsequenzen geht es in den folgenden Artikeln.