Zum Hauptinhalt springen

Micro Frontends

Einleitung​

Micro Frontends übertragen die Idee fachlich geschnittener Systeme auf die UI-Ebene.

Ein Frontend wird in fachlich abgegrenzte Teil-Frontends zerlegt, die von separaten Teams entwickelt, betrieben und idealerweise unabhängig deployt werden.

Ziel ist nicht technische Fragmentierung, sondern:

organisatorische Skalierung bei kontrollierter UI-Komplexität.

Einordnung

Micro Frontends sind ein Frontend-Systemstil.

Sie betreffen:

  • Struktur der UI-Landschaft
  • Team-Ownership
  • Release-Organisation
  • Integrationsstrategie im Browser

Sie sind kein reines UI-Pattern und keine Build-Technik.

Zentrale Ziele

  • Team-Autonomie im Frontend
  • Parallele Entwicklung ohne Merge-Hölle
  • Unabhängige Release-Zyklen
  • Fachlich saubere Schnitte

Strukturvarianten

1️⃣ Build-Time-Komposition​

  • Gemeinsamer Build
  • Modul-Federation / Monorepo
  • Klare Modulgrenzen

Vorteil: weniger Runtime-Komplexität
Nachteil: Releases oft gekoppelt

2️⃣ Runtime-Komposition​

  • Dynamisches Laden per Remote
  • Shell orchestriert Integration
  • Unabhängige Deployments möglich

Vorteil: echte Release-Autonomie
Nachteil: höhere Integrationskomplexität

3️⃣ Navigation-basierte Integration​

  • Separate Apps
  • Integration über URL-Navigation
  • Kein gemeinsamer Runtime-State

Vorteil: sehr geringe Kopplung
Nachteil: eingeschränkte UX-Integration

Charakteristika

Struktur​

  • Shell / Host App als Integrator
  • Fachlich geschnittene Frontend-Slices
  • Klare Ownership pro Slice

Kopplung​

  • Contracts für Navigation
  • Gemeinsame Auth-Strategie
  • Design-System als Stabilitätsanker
  • Minimierter globaler State

Deployment​

  • Optional unabhängige Deployments
  • Versionierung von Remote-Interfaces
  • Canary-Strategien möglich

Daten​

  • Backend-Integration meist über BFF oder API-Gateway
  • Kein impliziter Cross-MFE-State
  • Events oder explizite Schnittstellen für Interaktion

Vorteile

  • Skalierbare Teamstruktur
  • Reduzierte Merge-Konflikte
  • Klare Domänen-Ownership
  • Schrittweise Modernisierung möglich

Risiken / typische Fallstricke

1️⃣ Verteilte UI ohne Domänenschnitt​

Wenn Schnitte technisch statt fachlich erfolgen:

→ Distributed Monolith im Browser.

2️⃣ Technologie-Wildwuchs​

„Jedes Team wählt sein Framework“ klingt attraktiv, führt aber zu:

  • Bundle-Explosion
  • Wartungskosten
  • UX-Inkonsistenz

Technologie-Freiheit ist ein politisches, kein architektonisches Ziel.

3️⃣ Performance-Risiken​

  • Mehrere Framework-Instanzen
  • Doppelte Dependencies
  • Mehrere Initialisierungen

Performance-Budget ist Pflicht.

4️⃣ Fehlendes Design-System​

Ohne:

  • Shared Components
  • Style-Guidelines
  • UX-Governance

zerfällt die Oberfläche visuell.

5️⃣ Globaler State​

Geteilte globale Stores führen zu:

  • starker Kopplung
  • schwer nachvollziehbaren Seiteneffekten

Micro Frontends + Global Store = Architekturkonflikt.

Wann sinnvoll?

  • Mehrere Teams arbeiten parallel am Frontend
  • Große, langlebige Plattform
  • Fachliche Domänen klar abgrenzbar
  • Release-Zyklen entkoppelt

Wann nicht sinnvoll?

  • Kleines Team
  • MVP
  • Kurzlebiges Produkt
  • Kein stabiles Design-System

Praxis-Check

Szenario 1: Große Plattform​

Checkout, Search, Account, Content sind fachlich getrennt und team-owned.

Micro Frontends erhöhen hier Organisations-Skalierbarkeit.

Szenario 2: Startup​

3 Entwickler, 1 Produkt.

Micro Frontends erzeugen Overhead ohne Mehrwert.

C4-Diagramm

Strategische Perspektive

Micro Frontends sind kein Performance-Pattern. Sie sind kein UX-Pattern. Sie sind kein Framework-Feature.

Sie sind ein Organisations- und Ownership-Modell für Frontends.

Wenn Organisation nicht skaliert werden muss, skaliert man nur Komplexität.

Fazit

Micro Frontends lohnen sich, wenn:

  • Teams skalieren müssen
  • Domänen stabil geschnitten sind
  • Governance existiert

Ohne diese Voraussetzungen entsteht:

Frontend-Fragmentierung statt Autonomie.