Micro-Frontends Architektur in der Praxis

Der Moment, bevor alles anfing

Ich stand backstage in Andalusien. Die Lights waren bereits an, auch wenn ich noch nicht auf der Bühne war. Ich konnte die Scheinwerfer sehen, lange Lichtstrahlen, die über die Tribüne gingen. Das Mikrofon war irgendwo dort draußen, bereit, meine Worte in den Saal zu tragen. Und der Saal selbst, gut, der Saal war voller als erwartet.

Dreihundert Menschen.

Das ist eine abstrakte Zahl, bis du vor ihnen stehen musst.

Ich war 25 Jahre alt. Es war Oktober 2019. Meine Bachelorarbeit lag noch nicht so lange hinter mir. Drei Monate vielleicht. Noch frisch, noch neu, noch ein bisschen unwirklich, dass jemand außer meinen Professoren sich dafür interessieren könnte.

Und jetzt sollte ich vor dreihundert Menschen darüber sprechen.

Die Angst war physisch. Mein Herz war schnell. Meine Hände schwitzten. Ich hatte tausend Mal diese Präsentation geübt, aber jetzt, wo die Scheinwerfer bereits brannten, wo ich die Stimmen des Publikums hören konnte, wurde mir bewusst: Das ist echt. Das ist jetzt.

Ich erinnere mich, dass ich dachte: Was passiert, wenn ich die Worte vergesse? Was passiert, wenn der Saal merkt, dass ich nicht bereit bin? Was passiert, wenn ich anfangen zu stottern beginne?

Dann wurde ich aufgerufen.

Der Saal, der zu klein war

300 Zuschauern sind im Saal in Andalusien versammelt. Verschwommen aus Datenschutzgründen.

Ich trat auf die Bühne. Die Scheinwerfer trafen mein Gesicht. Die Welt wurde weiß.

Und dann sah ich es. Der Saal war nicht voll. Der Saal war übervoller als voll.

Es gab 250 Stühle. Das war die Kapazität. Und alle 250 Stühle waren besetzt. Aber das war nicht das Verrückte. Das Verrückte war, dass überall Menschen standen. An den Wänden, zwischen den Reihen, überall. Der Saal war nicht nur voller als erwartet, er war physikalisch überfordert.

Dreihundert Menschen. Im Saal für 250.

Das macht man nicht in diesem Moment bewusst. Man nimmt es auf, man absorbert es, aber man verarbeitet es nicht. Man hat zu viel andere Dinge im Kopf. Das Mikrofon in der Hand. Die Präsentation, die gleich beginnt. Die Scheinwerfer, die in den Augen brennen.

Aber später, während des Vortrags, während ich sprach, merkte ich: Das ist nicht normal. Menschen interessieren sich wirklich dafür. So viele Menschen, dass der Saal sie nicht halten kann. Sie stehen, weil sie hier sein wollen. Nicht weil sie müssen.

Das hat mir alles verändert.

Die Aufregen verging schnell

Ich hätte erwartet, dass die Aufregung das ganze Ding durchzieht.

Aber es passierte etwas Seltsames.

Ich fing an zu sprechen. Nicht über die Aufregung. Nicht über die Scheinwerfer oder die 300 Menschen oder den überforderten Saal. Ich fing an zu sprechen über meine Bachelorarbeit. Über Micro-Frontends.

Und in dem Moment, in dem ich in die erste Folie einstieg, in dem ich beschrieb, was ein monolithisches Frontend ist, warum es ein Problem wird, wenn Anwendungen wachsen, verschwand die Aufregung.

Nicht plötzlich. Nicht dramatisch. Es verschwand einfach, so wie Nebel verschwindet, wenn die Sonne aufgeht. Es war da, aber es war nicht mehr in meinem Fokus.

Das war eine Offenbarung.

Die Aufregung war nicht das Problem. Die Aufregung war nur Energie, die ich nicht kanalisiert hatte. Aber sobald ich anfing zu sprechen, sobald ich Inhalt in diese Energie goss, wurde sie zu etwas anderem. Es wurde zu Leidenschaft. Es wurde zu Klarheit.

Ich war immer noch aufgeregt. Aber ich war aufgeregt, weil der Inhalt mich aufregte. Weil ich wusste, dass das, was ich zu sagen hatte, wichtig war.

Das Micro-Frontends Problem

Lassen Sie mich zurückgehen. Lassen Sie mich erklären, warum ich überhaupt auf dieser Bühne stand.

Meine Bachelorarbeit war keine akademische Spielerei. Sie war eine Reaktion auf ein echtes Problem, das ich sah:

Frontend-Monolithen.

Wenn Anwendungen groß werden, wenn Teams wachsen, wenn die Komplexität zunimmt, dann tritt ein klassisches Problem auf. Alles sitzt in einem Repository. Alles teilt sich eine Codebasis. Alles läuft in einer gemeinsamen Laufzeitumgebung. Das funktioniert am Anfang. Es ist schnell, es ist einfach, es ist Monokultur.

Aber je größer die Anwendung wird, desto mehr beginnen die Teams, sich gegenseitig zu blockieren. Sie können nicht unabhängig voneinander arbeiten. Ein Bug in einer Komponente kann die ganze Anwendung zum Crashen bringen. Ein Performance-Problem in einer Feature zieht die ganze Seite runter.

Und dann gibt es noch die organisatorische Seite. Teams sind organisiert nach technischen Aspekten. Ein Team kümmert sich um das UI-Framework. Ein anderes um die Datenebene. Ein drittes um die API-Integration. Das ist das alte Modell.

Das Backend hatte das Problem gelöst. Microservices. Das Backend fragmentiert sich in kleine, unabhängige Services. Jeder Service hat seine eigene Verantwortlichkeit. Jedes Team kann autonom arbeiten.

Aber das Frontend? Das Frontend war immer noch ein Monolith.

Das Paradigmenwechsel: Micro-Frontends

Das ist, wo Micro-Frontends ankommen.

Die Idee ist radikal einfach: Wende den gleichen Gedanken auf das Frontend an. Fragmentiere das Frontend in kleine, unabhängige Einheiten. Nicht nach technischen Aspekten, sondern nach Geschäftsfeldern. Ein Team ist verantwortlich für die Checkout-Experience. Ein anderes für das Product Listing. Ein drittes für die Benutzerprofile.

Jedes Team arbeitet autonom. Jedes Team deployt seine eigene Version. Jedes Team kann seine eigene Technologie-Entscheidungen treffen. JavaScript hier, Vue dort, React anderswo. Es ist keine Monokultur mehr.

Aber das ist auch komplex. Das ist nicht einfach so umzusetzen.

Das war der Kern meiner Bachelorarbeit. Ich habe alle verschiedenen Möglichkeiten untersucht, Micro-Frontends zu implementieren. Und ich habe herausgefunden, dass es nicht eine Lösung gibt, sondern viele.

Die Umsetzungsmöglichkeiten

Im Saal in Andalusien, während 300 Menschen zuhörten, während viele von ihnen standen, erklärte ich die drei großen Ansätze:

Build-Time-Integration: Du fragmentierst das Frontend in separate Packages. Jedes Team veröffentlicht sein Micro-Frontend als NPM-Modul. Die Host-App installiert alle Module und baut sie zusammen. Das ist schnell, das ist einfach, aber es bedeutet auch, dass du für jede Change neu bauen und deployen musst. Alle Teams sind gekoppelt an den Build-Prozess.

Server-Side-Integration: Der Server orchestriert. Jedes Micro-Frontend hat seinen eigenen Endpoint. Der Server kombiniert die HTML-Antworten. Es ist wie ein klassisches Fragment-basiertes System, nur moderner. Das gibt dir viel Freiheit, aber es bedeutet auch, dass der Server komplexer wird.

Runtime-Integration: Die Anwendung lädt die Micro-Frontends dynamisch zur Laufzeit. Jedes Micro-Frontend ist eine eigenständige Anwendung, die in den Container injiziert wird. Das ist das flexibelste Modell, aber auch das komplexeste. Du musst eine Kommunikations-Schicht bauen. Du musst Fehlerbehandlung haben.

Das sind nicht einfach nur technische Unterschiede. Das sind unterschiedliche Philosophien über Autonomie, Kopplung, und Komplexität.

Die Fallstudie, die alles zusammenbrachte

Das, was ich in Andalusien zeigte, war nicht nur theoretisch. Ich hatte eine Fallstudie. Ein echtes Projekt, bei dem ich alle drei Ansätze kombiniert hatte.

Unterschiedliche Teile der Anwendung nutzten unterschiedliche Strategien. Manche Fragments waren Build-Time-integriert. Andere waren Runtime-integriert. Einige waren Server-Side.

Das war der Punkt. Das war die Erkenntnis, die ich teilen wollte: Es gibt nicht den einen richtigen Weg. Es gibt den richtigen Weg für dein Projekt, für dein Team, für deine Anforderungen.

Das war nicht akademisch. Das war praktisch. Das war ehrlich.

Und ich sah im Publikum, dass das klick-machte. Die Menschen merkten, dass ich nicht nur Theorie präsentierte. Ich präsentierte etwas, das ich selbst gebaut hatte. Etwas, das funktioniert hatte. Etwas, das real war.

Die Entscheidungsmatrix

Was die Bachelorarbeit zusammenfasste, was ich im Saal projizierte, war eine Matrix. Ein Vergleich aller Ansätze.

Build-Time-Integration ist schnell und einfach, aber die Teams sind gekoppelt.

Server-Side-Integration gibt dir mehr Autonomie, aber der Server wird komplexer.

Runtime-Integration ist die autonomste, aber auch die komplexeste in der Implementierung.

Es gibt kein Richtig oder Falsch. Es gibt nur Trade-offs. Und je nachdem, was dir wichtig ist, wählst du einen Weg.

Das ist die Lektion, die ich lernte, während ich meine Bachelorarbeit schrieb. Und das ist, was ich in Andalusien kommunizierte. Dass Architektur nicht dogmatisch ist. Dass die beste Lösung die Lösung ist, die für dein Kontext passt.

Die größere Wahrheit

Aber während ich redete, während ich sah, dass Menschen standen, weil der Saal zu klein war, merkte ich etwas anderes.

Das tiefere Problem, das ich in meiner Arbeit angegriffen habe, war nicht technisch. Es war organisatorisch.

Monolithische Frontends sind nicht nur ein Frontend-Problem. Sie sind ein Team-Problem. Sie sind ein Organisationsproblem. Sie sind ein Problem der Skalierbarkeit. Wenn du ein großes Team hast, wenn du viele Features entwickelst, wenn du schnell iterieren brauchst, dann kannst du nicht alle in einer Codebasis haben.

Micro-Frontends sind nicht nur eine Architektur. Sie sind eine Organisationsstruktur. Sie sind die Erlaubnis, dass Teams autonom arbeiten können. Dass sie nicht warten müssen, bis ein anderes Team mit ihrer Änderung fertig ist. Dass sie ihren eigenen Rhythmus haben können.

Das war, was ich wirklich sagen wollte. Und das war, was die 300 Menschen in Andalusien verstanden haben.

Die größte Überraschung

Was mich am meisten überraschte, war das, was nach dem Vortrag passierte.

Menschen kamen zu mir. Sie wollten über Micro-Frontends sprechen. Sie wollten über ihre eigenen Projekte sprechen. Sie wollten meine Arbeit verstehen. Sie wollten wissen, wie sie das in ihrer Anwendung implementieren könnten.

Das war nicht Höflichkeit. Das war echtes Interesse.

Ich war 25 Jahre alt. Ich hatte gerade meine Bachelorzeugnis bekommen. Und ich war auf der Bühne in Andalusien vor 300 Menschen gewesen. Nicht weil ich ein berühmter Entwickler war. Nicht weil ich ein Buch geschrieben hatte. Sondern weil ich ein echtes Problem untersucht hatte, und Lösungen gefunden hatte.

Monolithen verschwinden nicht über Nacht

Heute, sechs Jahre später, sind Micro-Frontends immer noch nicht die Standard-Architektur. Viele Unternehmen nutzen noch Frontend-Monolithen. Das ist nicht falsch. Das ist nur ein anderer Kontext.

Aber der Gedanke ist verbreitet. Immer mehr Teams fragmentieren ihre Frontends. Immer mehr Unternehmen adoptieren Micro-Frontends-Architekturen. Nicht weil es Mode ist, sondern weil es funktioniert.

Die Probleme, die ich in meiner Bachelorarbeit identifizierte, sind nicht weg. Sie sind größer geworden. Web-Anwendungen sind komplexer. Teams sind größer. Die Nachfrage nach Autonomie ist lauter.

Und Micro-Frontends bieten eine Antwort.

Nicht die Antwort. Eine Antwort. Mit Trade-offs, mit Komplexitäten, mit neuen Herausforderungen.

Aber eine Antwort.

Hinweis: Wenn du eine nüchterne, messbare Bewertung für eure aktuelle Frontend-Struktur brauchst – inkl. Audit, Risikoanalyse und möglicher Migrationspfade – melde dich gern. Ich arbeite ausschließlich mit transparenten Trade-offs, nicht mit Architektur-Versprechen.

Beitrag Teilen

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