Microservices for Front Ends: Micro-Frontends richtig denken – unsere Learnings aus dem Talk von Michael Eder (Objectbay)

Warum das Frontend den nächsten Evolutionsschritt braucht

Bei klassischen Backend-Architekturen hat die Branche die Reise von Monolithen über serviceorientierte Architekturen hin zu Microservices längst angetreten. Im Browser dagegen blieb vieles erstaunlich konstant: ein großer, eng gekoppelter Frontend-Monolith. Genau hier setzt der Tech Talk „Microservices for Front Ends“ von Michael Eder (Objectbay) an. Sein Ziel: die Prinzipien von Microservices konsequent auf die Benutzeroberfläche übertragen – mit Micro-Frontends.

Eder erinnerte eingangs an die Herkunft des Begriffs: ThoughtWorks führte Micro-Frontends 2016 im Technology Radar ein, während Unternehmen wie Amazon das Konzept bereits früh praktisch genutzt haben. Weitere prominente Namen, die er nannte: Zalando, Spotify, HelloFresh und Datsen – alle mit sichtbarer Vielfalt an Einzelsegmenten innerhalb einer Anwendung, die beim Nutzer dennoch als ein nahtloses Produkt ankommen.

Die Quintessenz des Vortrags: Frontends verdienen dieselbe entkoppelte, teamautonome Architektur wie Backends. Und das erfordert technologie- wie organisationsseitig ein paar klare Entscheidungen.

Wer spricht und wofür er steht

Michael Eder ist Full-Stack-Software-Ingenieur bei Objectbay. Das Unternehmen existiert seit 2006, hat drei Standorte (Traun als Hauptquartier, dazu Wien und Salzburg), beschäftigt rund 50+ Mitarbeitende und hat über 160 Projekte erfolgreich umgesetzt. Technologisch ist Objectbay im JVM-Stack (Kotlin, Java) zu Hause, arbeitet mit Spring und Quarkus, setzt aber je nach Projekt auch auf andere Welten – etwa Python, beispielsweise in einem Projekt für Flughafensicherheit. Die Quintessenz: heterogene Technologien, vielfältige Branchen, der passende Stack für die Domäne.

Zum Einstieg bedankte sich Eder bei Michael Gerst für die Erlaubnis, Grafiken aus dem Buch „Micro Front Ends in Action“ zu verwenden – eine inhaltliche Grundlage, die in seinem Talk mehrfach sichtbar wurde, etwa beim „Tractor Store“-Beispiel.

Der Ausgangspunkt: Backend evolviert, Frontend bleibt zurück

Eder zeichnet die bekannte Evolution: Monolith → SOA → Microservices. Mit jedem Schritt wurden Services feingranularer, Datenbanken separiert, Verantwortlichkeiten klarer. Doch eines stach für ihn sofort ins Auge: das Frontend blieb monolithisch. Seine These: Dieser Versatz bremst Delivery-Geschwindigkeit, Teamautonomie und letztlich die Nutzererfahrung – und er ist vermeidbar.

Die Antwort darauf sind Micro-Frontends: domänenorientierte, unabhängig lieferbare Teile einer UI, die am Ende zu einem Produkt zusammengesetzt werden, ohne dass der Nutzer einen Bruch spürt. Das Idealbild: autonome Teams, unabhängige CI/CD-Pipelines, unterschiedliche Technologien, aber ein gemeinsames, konsistentes Erlebnis.

Das Bild im Kopf: Page Ownership, Fragmente, Gesamterlebnis

Anhand des „Tractor Store“-Beispiels (aus „Micro Front Ends in Action“) verdeutlichte Eder die Aufteilung:

• Page Ownership: Jedes Team verantwortet eine Seite oder Domäne vollständig.
• Fragmente: Innerhalb einer Page können fremde Bausteine eingebettet werden (z. B. Recommendations, Buy-Button, Banner).
• Zusammensetzen: Viele kleine Puzzleteile ergeben ein kohärentes Ganzes.

Das Entscheidende: Teams liefern eigenständig – und doch bleibt die Anwendung für den Endnutzer „aus einem Guss“.

Organisation vor Technik: Cross-funktional statt geschichtet

Die Architektur ist nur so gut wie die Organisation, die sie trägt. Eder betont, dass Micro-Frontends mit cross-funktionalen Teams am besten funktionieren – also mit Einheiten, die von der Datenbank bis zum Design Verantwortung übernehmen, inklusive Architektur und Monitoring. Ein DevOps-Mindset ist dabei gesetzt.

Wovor er ausdrücklich warnte: zentrale, geteilte Teams, die große Querschnittsaufgaben übernehmen (etwa zentrale Infrastruktur). Das erzeugt Kopplung und Abhängigkeiten zwischen Produktteams – und konterkariert die Vorteile von Micro-Frontends.

Stattdessen: Verantwortlichkeiten pro Team zuschneiden und nur dort gemeinsame Bereiche definieren, wo es wirklich nötig ist.

Drei Querschnittsthemen, die jedes Team mitdenken muss

• Web-Performance: Jedes Fragment kann eine Seite spürbar verlangsamen – Performance ist Teamverantwortung.
• Design-System: Ein einheitliches Look-and-Feel verhindert Brüche in der User Experience.
• Wissensaustausch: In cross-funktionalen Teams muss Wissen laufend fließen, etwa via Chapter/Gilden oder Fokusgruppen (DevOps, Architektur, Clean Code, Test/Integration u. a.).

Die drei Säulen der Micro-Frontend-Architektur

Bevor man Micro-Frontends einführt, müssen laut Eder drei Grundfragen gelöst werden:

1) Routing zwischen Anwendungen: Wie gelingen Seitenübergänge ohne Brüche?

2) Zusammensetzung der Seite (Composition): Wie werden Micro-Frontends eingebettet?

3) Messaging: Wie kommunizieren Seite und Fragmente miteinander?

In seinem Talk strukturierte Eder diese drei Säulen klar und zeigte in jedem Bereich mehrere praktikable Optionen – vom trivialen Einstieg bis zur hochperformanten E-Commerce-Lösung.

Säule 1: Routing-Strategien – vom simplen Link bis zur Application Shell

Hyperlinks: simpel, aber mit UX-Kompromissen

Der naheliegendste Startpunkt sind schlicht Hyperlinks zwischen separaten Anwendungen. Vorteil: sehr einfach. Nachteil: Der Wechsel ist sichtbar (z. B. geänderte URL), die User Experience leidet. Für ernsthafte Integrationen ist das oft zu grob.

Reverse Proxy (z. B. Nginx): einheitliche Domäne, weniger CORS-Stress

Ein eleganterer Ansatz: ein Reverse Proxy zwischen Client und Anwendungen. Eder nannte beispielhaft Nginx. Vorteile:

• Einheitliche Domäne, die Anwendung wirkt wie „aus einem Guss“.
• CORS-Probleme werden reduziert – auch für CSS/JavaScript-Assets.

Dieser Ansatz ist schnell umsetzbar und hebt die UX gegenüber reinen Hyperlinks spürbar an.

Application Shell: die Meta-Schicht für Single-Page-Applications

Wenn ohnehin Frameworks wie Angular, Vue oder React genutzt werden, lohnt sich eine Application Shell. Sie dient als Meta-Framework, das mehrere SPAs lädt und den dokumentinternen Wechsel orchestriert. Vorteile:

• Der Browser bleibt im gleichen Dokument; nur Inhalte werden ausgetauscht.
• Clientseitige Navigation reduziert Server Round-Trips und kann spürbar schneller wirken.

Eder’s Empfehlung ist pragmatisch: die Vorteile von SPAs in einer Shell bündeln und so Übergänge geschmeidig halten.

Säule 2: Composition – wie Micro-Frontends in die Seite kommen

iFrames: starke Isolation mit Kosten

„Oh Gott, iFrames“ – Eder nimmt den Reflex mit Humor, ordnet ihn aber ein: iFrames sind ein relevanter Baustein. Vorteile:

• Hohe Isolation: CSS „leakt“ nicht, Kollisionen werden minimiert.

Nachteile:

• Jeder iFrame erzeugt einen neuen Web-Kontext – das kostet CPU und Speicher.
• Größenmanagement (Höhe/Breite) wird zur Aufgabe.

AJAX: direkte Einbettung in den DOM, besser für Accessibility

AJAX kann Nachteile von iFrames kompensieren. Durch direkte DOM-Einbettung:

• Verstehen Screenreader den Kontext besser (Accessibility).
• Erübrigt sich manuelles Größenmanagement, da das Element „natürlich“ fließt.

Klarer Trade-off: Ist der Server nicht erreichbar, bleibt das Fragment leer. Dennoch ist AJAX ein bewährter Weg, Komponenten elegant einzubetten.

Client- und serverseitige Integration: Web Components, SSI/ESI

Eder nannte die Kombination aus client- und serverseitiger Integration – unter anderem mit Web Components:

• Shadow DOM sorgt für hohe Isolation (ähnlich dem Vorteil von iFrames, aber in der DOM-Welt).
• Templates ermöglichen wiederverwendbare Bausteine, die als HTML-Tags und via JavaScript bereitgestellt werden.

Auf der Serverseite verwies Eder auf altbewährte Techniken wie Server-Side Includes (SSI) oder Edge-Side Includes (ESI), die von Reverse Proxys wie Nginx oder Varnish unterstützt werden. Die Idee: Platzhalter im Template, die am Server mit Fragmenten gefüllt werden. Vorteile:

• Der Nutzer erhält eine fertig gerenderte HTML-Seite.

Er warnte aber auch, dass serverseitige Includes theoretisch unerwünschten Code ausführen könnten – ein Aspekt, den es organisatorisch und sicherheitstechnisch sauber zu regeln gilt.

Taylor (Zalando, Project Mosaic): Streaming-Composition für E‑Commerce-Tempo

Besonders ausführlich ging Eder auf Taylor ein – ein Teilprojekt von Zalandos „Project Mosaic“. Motivation: Im E-Commerce zählt jede Millisekunde. Nutzer sollen „sofort etwas sehen“, sonst wechseln sie zur Konkurrenz. Taylor adressiert das mit einer Streaming-API und einem flexiblen Template-/Fragment-Modell.

Die Kernideen, wie Eder sie zusammenfasst:

• Platzhalter im Template, die mit Fragmenten gefüllt werden.
• Streaming: Der Server beginnt sofort mit dem Senden, der Browser rendert unmittelbar; Fragmente folgen parallel und werden eingefügt.
• Retry-Logik: Wie oft soll ein fehlendes Fragment neu abgefragt werden?
• Fallbacks/Redundanz: Fällt ein Server aus, liefert ein zweiter dasselbe Fragment aus.

Das Resultat: sehr frühe Sichtbarkeit im Browser bei gleichzeitig robuster Auslieferung der Fragmente.

Säule 3: Messaging – wer redet mit wem und wie?

Micro-Frontends erfordern klare Kommunikationsmuster. Eder unterscheidet drei Richtungen:

1) Parent → Fragment: Daten ins Fragment reichen

2) Fragment → Parent: Ereignisse nach oben signalisieren

3) Fragment ↔ Fragment: Kommunikation zwischen Kontexten

Parent zu Fragment: Properties und Attribute

Im Kontext von Web Components lassen sich Daten über Properties/Attribute übergeben. Der Parent konfiguriert das Fragment, indem er Werte direkt setzt – ein einfaches, robustes Muster.

Fragment zu Parent: JavaScript-Events, die nach oben „bubblen“

Fragmente können Events feuern. Diese blubbern nach oben und jedes Element, das darauf registriert ist, kann sie verarbeiten. Dieses seit Langem bewährte Web-Paradigma passt sehr gut zur Micro-Frontend-Kommunikation.

Fragment zu Fragment: Broadcast-Channel-API als nativer Message-Bus

Als drittes nannte Eder die Broadcast-Channel-API. Sie erlaubt es, auf demselben Origin einen Message-Pass zwischen Kontexten zu öffnen – etwa zwischen Fenstern, Tabs oder iFrames. Praktisch: Fragmente können wie über Topics Daten austauschen, ohne harte direkte Abhängigkeiten eingehen zu müssen.

Qualitätsmerkmale: Performance, Konsistenz, Autonomie – in dieser Reihenfolge

Eder ordnet die Prioritäten klar:

• Performance: Jedes Fragment muss so performant wie möglich sein, um die Seite nicht auszubremsen.
• Konsistenz: Ein Design-System sorgt dafür, dass sich die Anwendung wie „eine“ anfühlt – unabhängig davon, welches Team welches Fragment liefert.
• Autonomie: Teams müssen Ende-zu-Ende arbeiten können (Datenbank bis Design, inklusive Monitoring) und unabhängig deployen dürfen.

Diese drei Ziele bedingen einander. Sie sind nur erreichbar, wenn Organisation und Technik zusammenspielen – ohne neue zentrale Bottlenecks zu schaffen.

Entscheidungsleitfaden: Wie wählt man den passenden Ansatz?

Aus Eders Perspektive hängt die Wahl des Ansatzes von wenigen Leitfragen ab, die man ehrlich für die eigene Domäne beantworten sollte:

• Wie wichtig ist eine einheitliche URL und das Verbergen von Kontextwechseln? Wenn „sehr wichtig“, dann Reverse Proxy oder Application Shell in Betracht ziehen.
• Wie hoch ist der Bedarf an Isolation? iFrames bieten maximale Trennung (CSS, Kontext), aber zu CPU-/Speicherkosten.
• Wie kritisch ist die erste Wahrnehmungsgeschwindigkeit? Bei „sofort etwas sehen“ lohnt sich ein Streaming-Ansatz wie Taylor.
• Wie stark müssen Fragmente miteinander sprechen? Wenn häufig, dann früh ein Messaging-Konzept festlegen – etwa Events und Broadcast-Channel-API.
• Wie sichern wir Konsistenz? Ein Design-System und klare Performance-Budgets sind Pflicht.

Die Optionen sind nicht exklusiv: Viele erfolgreiche Setups kombinieren mehrere der beschriebenen Bausteine – etwa eine Application Shell für clientseitige Navigation und serverseitige Platzhalter für initiale Renderzeiten.

Was wir aus „Microservices for Front Ends“ konkret mitnehmen

• Micro-Frontends sind eine pragmatische Antwort auf den Frontend-Monolithen. Sie übertragen die Microservice-Ideen ins UI – mit echter Teamautonomie und unabhängigen Deployments.
• Die Einführung ist weniger eine Technologie-, sondern vor allem eine Organisationsfrage: Cross-funktionale Teams, DevOps-Mindset, klare Verantwortlichkeiten.
• Drei Architektursäulen strukturieren die Entscheidung: Routing, Composition, Messaging. Für jede gibt es mehrere etablierte Muster – vom Hyperlink bis zum Streaming.
• Performance und Konsistenz stehen an erster Stelle. Jedes Fragment trägt Verantwortung für die Gesamt-UX.
• Bewährte Bausteine existieren längst: Reverse Proxy (z. B. Nginx), Application Shells, iFrames, AJAX, Web Components, SSI/ESI – und für anspruchsvolle Streaming-Szenarien Taylor (Zalando/Project Mosaic) inklusive Retry und Fallbacks.
• Für die fragmentübergreifende Kommunikation lohnt sich ein Blick auf die Broadcast-Channel-API als nativen Message-Bus.

Fazit: Micro-Frontends sind kein Selbstzweck – sie sind ein Organisationsversprechen

„Microservices for Front Ends“ zeigte klar: Micro-Frontends sind weniger ein Framework-Feuerwerk, sondern ein Versprechen an die Organisation. Wenn Teams Ende-zu-Ende Verantwortung übernehmen, unabhängig liefern und dennoch eine konsistente UX sicherstellen, entsteht der eigentliche Nutzen: schneller Mehrwert für Nutzerinnen und Nutzer – ohne, dass sie merken, wie viele Puzzleteile dafür zusammenspielen.

Oder, wie Eder es zusammenfasste: Am Ende wird „ein gesamtes Produkt“ ausgeliefert, „sodass [der Nutzer] keine Ahnung davon hat, was dahinter steckt und das Gefühl hat, es ist eine Applikation.“

Für uns ist das die wichtigste Messlatte. Die Bausteine liegen auf dem Tisch – von Hyperlinks bis Taylor. Entscheidend ist, sie mit Bedacht zu kombinieren, Verantwortung richtig zu schneiden und Performance und Konsistenz als nicht verhandelbare Kriterien zu verankern. Dann wird aus Micro-Frontends nicht nur eine Architektur, sondern ein Wettbewerbsvorteil.

• 

  

  Serverless Applications with AWS Lambda

  Thomas Jäger von Objectbay geht in seinem devjobs.at TechTalk zu dem Thema Serverless Applications in die Tiefe und überprüft, ob die Marketing Slides von Amazon auch halten was sie versprechen.

  Jetzt ansehen
• 

  

  Die Wahl der richtigen Software Architektur

  Alexander Knapp von Objectbay beschäftigt sich in seinem devjobs.at TechTalk mit der Herangehensweise, wie man aus einer Vielzahl an verschiedenen Software Architekturen die passende auswählt.

  Jetzt ansehen
• 

  

  Mutation Testing

  Alexander Knapp von Objectbay widmet sich in seinem devjobs.at TechTalk dem Thema Mutation Testing – was es ist und wie jedes Software Projekt davon profitieren kann.

  Jetzt ansehen

• 

  

  Alexander Knapp, Full Stack Software Engineer bei Objectbay

  Alexander Knapp von Objectbay schildert im Interview seinen Werdegang bis hin zu seiner aktuellen Rolle im Full Stack Engineering und was seiner Meinung nach für Beginner wichtig ist.

  Jetzt ansehen