Micro-Frontends: Wie Autonomie die Komplexität in der Webentwicklung formt

Die Monolith-Erkenntnis

Bevor ich zu Micro-Frontends kam, musste ich das Problem zeigen.

Das Problem ist alt. Das Problem ist vertraut. Aber es wird mit jeder neuen Technologie wieder neue zu ignoriert. Dann zu spät erkannt. Dann zu schnell ignoriert.

Das Problem der monolithischen Frontends.

Stell dir vor, du bist bei einem Startup. Es ist 2015. Du brauchst eine Website. Du brauchst eine Anwendung. Also schreibst du React. Du packst alles in ein Repository. Ein großes, wunderbares Repository, das am Anfang alles ist, was du brauchst.

Die Anwendung wächst. Neue Features kommen. Neue Teams werden eingestellt. Das Team, das die Produktseite baut, arbeitet parallel zu dem Team, das das Checkout-System baut. Aber beide arbeiten sie in der gleichen Codebasis. Sie teilen sich die gleichen Dependencies. Sie teilen sich den gleichen Build-Prozess.

Das funktioniert am Anfang.

Dann wird es langsam. Der Build dauert fünf Minuten. Zehn Minuten. Fünfzehn Minuten. Ein Team wartet auf das andere. Ein Deploy wird zu einem koordinierten Event. Jede Änderung könnte die ganze Anwendung brechen. Das ist nicht Paranoia, das ist Erfahrung.

Die wahre Natur des Problems

Aber im Saal in Köln, auf dem React Barcamp, versuchte ich etwas zu vermitteln, das über Technik hinausgeht.

Das Problem der monolithischen Frontend ist nicht wirklich ein Frontend-Problem. Es ist ein Team-Problem. Es ist ein organisatorisches Problem.

Wenn du eine große Anwendung hast, wenn du viele Teams hast, wenn du schnell iterieren musst, dann kannst du nicht alle in einer Codebasis haben. Das ist nicht möglich. Es ist physikalisch möglich, ja. Aber organisatorisch, psychologisch, produktiv ist es unmöglich.

Die Teams beginnen, sich gegenseitig zu blockieren. Ein Team kann nicht deployen, weil das andere Team noch nicht fertig ist. Ein Bug in einer Komponente bricht die ganze Anwendung. Eine Performance-Optimierung in einem Feature zieht das ganze System runter.

Das ist nicht ein Problem der Entwickler. Das ist ein Problem der Architektur.

Das ist, was ich im Saal versucht habe zu kommunizieren. Dass das Monolith-Problem nicht technisch ist. Es ist strukturell.

Inspiration aus dem Backend

Das Backend hatte das Problem gelöst. Das Backend war Microservices. Das Backend war dezentralisiert.

Jeder Microservice hatte seine eigene Verantwortlichkeit. Sein eigenes Repository. Sein eigenes Deploy-Prozess. Die Teams konnten unabhängig voneinander arbeiten. Sie konnten ihre eigenen Technologien wählen. Sie konnten schnell iterieren.

Das Backend hatte Freiheit.

Das Frontend hatte Fesseln.

Das war die Asymmetrie, die ich auf der Bühne unterstrichen habe. Das Backend hatte die Lösung gefunden. Das Frontend war noch in der Monolith-Welt gefangen.

Warum?

Warum erlaubten wir dem Backend, zu fragmentieren, aber zwangen das Frontend in eine Monokultur?

Das war die Frage, die ich im Saal stellte.

Der Gedanke: Micro-Frontends

Und dann kam die Antwort. Nicht meine Antwort. Die Antwort, die es bereits gab, aber die nicht viele Menschen kannten.

Micro-Frontends.

Der Gedanke ist einfach. Wende den gleichen Gedanken an, den das Backend nutzt. Fragmentiere das Frontend in kleine, unabhängige Einheiten. Nicht nach technischen Aspekten. Nach Geschäftsfeldern.

Ein Team ist verantwortlich für die Produktseite. Ein anderes für das Checkout-System. Ein drittes für die Benutzerkonten. Jedes Team arbeitet autonom. Jedes Team hat seinen eigenen Repository. Jedes Team hat seinen eigenen Deploy-Prozess.

Das ist nicht revolutionär. Das ist nur ehrlich.

Ehrlich mit dem Problem. Ehrlich mit der Lösung. Ehrlich mit den Grenzen.

Integration Ansätze

Ich zeigte, wie Micro-Frontends integriert werden können, mit Konzepten. Mit Denkmustern.

Build-Time-Integration. Jedes Micro-Frontend ist ein separates Paket. Die Host-Anwendung installiert alle Pakete und baut sie zusammen. Das ist schnell. Das ist einfach. Aber die Teams sind gekoppelt an den Build-Prozess. Es ist nicht wirklich autonom.
Server-Side-Integration. Der Server orchestriert. Jedes Micro-Frontend hat seinen eigenen Endpoint. Der Server kombiniert die Antworten. Es ist wie das alte Fragment-System, aber moderner. Es gibt mehr Freiheit, aber der Server wird komplexer.
Runtime-Integration. Die Anwendung lädt die Micro-Frontends dynamisch zur Laufzeit. Jedes Micro-Frontend ist wirklich autonom. Aber die Komplexität steigt. Du musst Kommunikation zwischen den Fragments bauen. Du musst Fehlerbehandlung haben.

Ich zeigte diese drei Welten als Spektrum. Nicht als “gut” oder “schlecht”. Sondern als Trade-offs. Je autonomer die Teams sein dürfen, desto komplexer wird das System.

Die Unbekannte Implementation

Und dann, während ich im Saal stand, während die Entwickler:innen fragten, wo die Grenzen sind, wo es zu komplex wird, merkte ich etwas.

Ich kannte die Theorie. Ich kannte die Konzepte. Aber ich hatte noch nicht wirklich implementiert.

Ich war noch nicht an dem Punkt angekommen, wo ich sagen konnte: “Hier ist ein Projekt, hier habe ich alle drei Ansätze kombiniert, hier sind die Lernlektionen.” Das kam später. Das kam in Andalusien, neun Monate später, wenn meine Bachelorarbeit fertig war und meine Fallstudie reif.

Und ich denke, die Entwickler:innen merkten das. Sie merkten, dass ich nicht vorgab zu wissen, alles zu wissen. Dass ich eine Frage stelle, eine mögliche Antwort zeige, aber nicht behaupte, die Antwort zu haben.

Das war wichtig.

Der Kern des Vortrags

Der Kern dessen, was ich in Köln sagte, war nicht eine Lösung. Es war eine Erkenntnis.

Die Erkenntnis lautete: Monolithische Frontends sind ein Problem, wenn sie Entwickler blockieren. Nicht weil sie monolithisch sind. Sie werden zum Problem, wenn Teams nicht mehr unabhängig arbeiten können. Wenn Deployments koordiniert werden müssen. Wenn eine Änderung die ganze Anwendung gefährdet.

Und es gibt einen Weg, dieses Problem zu lösen. Einen Weg, den das Backend bereits gegangen ist.

Micro-Frontends.

Aber das ist nicht einfach. Es ist nicht eine schnelle Lösung. Es ist eine Architektur-Entscheidung. Mit Vor- und Nachteilen. Mit neuen Herausforderungen.

Das war die Botschaft.

Die Wichtigkeit des Fragenstellen

Was ich gelernt habe, während ich auf verschiedenen Bühnen stand und über Micro-Frontends sprach, ist nicht nur über Architektur.

Es ist über die Wichtigkeit, Fragen zu stellen. Über die Wichtigkeit, Probleme zu identifizieren. Über die Wichtigkeit, nicht zu behaupten, alle Antworten zu haben.

Im Januar in Köln hatte ich die Fragen. Ich hatte die Erkenntnis der Probleme. Ich hatte die Intuition einer Lösung.

Im Oktober in Andalusien hatte ich die Antworten. Ich hatte die Implementierung. Ich hatte die Lernlektionen.

Aber der Talk in Köln war nicht weniger wertvoll. Er war vielleicht sogar wertvoller. Denn er erlaubte den Entwickler:innen, selbst zu denken. Selbst zu fragen. Selbst zu explorieren.

Das ist die Kraft eines Vortrags, der keine Antworten gibt, sondern Fragen stellt.

Der Monolith ist nicht immer falsch

Heute, sechs Jahre später, gibt es immer noch viele monolithische Frontends. Das ist nicht falsch. Das ist nur ein anderer Kontext.

Aber die Frage, die ich im Januar 2019 gestellt habe, die Frage ist lebendiger als je zuvor.

Web-Anwendungen werden größer. Teams werden größer. Die Komplexität wächst. Und die Frage wird lauter: Wie können wir Frontend-Monolithen vermeiden? Wie können wir Teams ermöglichen, autonom zu arbeiten?

Micro-Frontends ist eine Antwort. Nicht die Antwort. Eine Antwort.

Das kleine Anfangen

Was ich vom React Barcamp gelernt habe, ist: Du musst nicht alle Antworten haben, um eine wichtige Konversation zu starten.

Du musst nur die richtigen Fragen haben. Du musst nur die Probleme sehen. Du musst nur die Mut haben, zu sagen: “Das ist kaputt. Es gibt einen besseren Weg.”

Neun Monate später stand ich vor 300 Menschen in Andalusien und zeigte konkrete Fallbeispiele. Aber das begann in Köln, vor viel weniger Menschen, mit viel weniger Klarheit, mit viel mehr Unsicherheit.

Das ist der Weg eines Gedankens. Das ist die Evolution einer Idee.

Die Monolithen sind nicht natürlich. Sie sind eine Wahl. Eine Wahl, die Sinn machte, als die Anwendungen kleiner waren. Aber wenn deine Anwendung wächst, wenn dein Team wächst, dann ist es Zeit, neu zu denken.

P.S. Wenn du die tieferen Implementierungen und konkreten Fallbeispiele von Micro-Frontends lesen möchtest, schaue dir meinen späteren Talk in Andalusien an, wo ich zeige, wie die Theorie tatsächlich funktioniert.

Wenn du Fragen hast oder über Micro-Frontends diskutieren möchtest, zögere nicht, mich zu kontaktieren!

Beitrag Teilen

Gefällt dir dieser Beitrag? Teile ihn mit deinem Netzwerk!