Muss ich alle Microfrontends lokal starten?

„Für eine Änderung bitte zuerst das gesamte Produkt starten“

„Für eine Änderung an diesem Remote bitte zuerst den Host, alle weiteren Remotes und die vollständige Produktumgebung starten.“

Was danach folgt, sieht in vielen Projekten ungefähr so aus:

Host
├── Remote A
├── Remote B
├── Remote C
├── Remote D
├── Identity Provider
├── gemeinsame Testdaten
└── mehrere Backend-Dienste

Erst wenn alles läuft, kann die eigentliche Arbeit an Remote C beginnen.

Die naheliegende Frage lautet: Warum muss für eine Änderung an Remote C das gesamte Produkt auf dem Entwicklerrechner laufen?

Eine vollständige lokale Komposition kann für ausgewählte Integrationsprüfungen sinnvoll sein. Sie zeigt, wie der Host ein Remote lädt, wie sich URLs verhalten, ob die verfügbare Layoutfläche passt oder ob eine gemeinsame Anmeldung in der Produktkomposition funktioniert. Sie sollte jedoch nicht der notwendige Standard für jede fachliche Änderung sein.

Wenn ein Remote für seinen normalen Entwicklungszyklus zwingend den vollständigen Host und mehrere fremde Remotes benötigt, ist seine Auslieferung möglicherweise unabhängiger als seine tatsächliche Entwicklung.

Die entscheidende Frage ist deshalb nicht, mit welchem Werkzeug sich mehrere Anwendungen gleichzeitig starten lassen. Die interessantere Frage lautet:

Warum sollte ein autonomes Microfrontend für seine tägliche Entwicklung den Host oder andere Remotes benötigen?

Separate Deployments sind noch keine Entwicklungsautonomie

Ein eigener Build und ein eigenes Deployment sind wichtige Voraussetzungen für unabhängige Releases. Sie beweisen aber noch nicht, dass das Remote auch als eigenständige Entwicklungseinheit funktioniert.

Die behauptete Unabhängigkeit sieht häufig so aus:

behauptete Unabhängigkeit
├── eigener Build
├── eigenes Deployment
├── eigener Quellcodebereich
└── eigener Remote-Einstieg

Tatsächliche Entwicklungsautonomie geht weiter:

tatsächliche Entwicklungsautonomie
├── eigener Mountpoint
├── eigene Fachlichkeit
├── eigener Zustand
├── eigenes internes Routing
├── eigene Authentifizierungsintegration
├── eigene API-Integration
├── eigene Tests
└── eigenständiger lokaler Start

Ein Remote kann technisch separat veröffentlicht werden und trotzdem bei jeder lokalen Änderung Benutzerzustand aus dem Host, vom Host berechnete Berechtigungen, fachliche Daten aus einem Shell-Service, globale Store-Slices oder interne Navigationsdienste benötigen. Vielleicht startet es sogar nur dann sinnvoll, wenn weitere Remotes und eine vollständig vorbereitete Produktumgebung verfügbar sind.

Die Kopplung ist dann nicht verschwunden. Sie wurde vom Build in die Laufzeit und den Entwicklungsprozess verschoben.

Das ist kein rein organisatorisches Problem. Der lokale Entwicklungszyklus macht sichtbar, wer tatsächlich Verantwortung trägt. Muss der Host Zustände vorbereiten, Benutzerobjekte erzeugen oder fachliche Daten beschaffen, damit ein Remote überhaupt arbeitsfähig wird, besitzt das Remote seine Voraussetzungen nicht selbst.

Separate Deployments können damit eine Autonomie suggerieren, die im täglichen Arbeiten nicht existiert.

Warum der Host nicht zur Laufzeitvoraussetzung werden sollte

Der Host ist ein Integrationspartner. Er kennt die Produktkomposition und stellt einen möglichen Mountpoint bereit. Diese Rolle ist wichtig, aber begrenzt.

Problematisch wird es, wenn der Host nicht nur integriert, sondern versorgt:

Host
├── lädt Benutzerzustand
├── berechnet Berechtigungen
├── beschafft Fachobjekte
├── verwaltet Remote-Zustände
├── stellt interne Services bereit
└── aktiviert das Remote
        ↓
Remote
└── funktioniert nur innerhalb dieses Kontexts

Technisch lässt sich ein solcher Vertrag umsetzen. Umfangreiche Objekte können beim Mounten übergeben, zentrale Services injiziert und gemeinsame Zustände verfügbar gemacht werden. Das ist jedoch keine neutrale technische Entscheidung.

Jede Übergabe erzeugt einen Vertrag. Der Host muss wissen, welche Informationen das Remote benötigt. Er muss diese Informationen besitzen oder beschaffen, ihr Format bestimmen und Änderungen koordinieren. Das Remote wiederum funktioniert nur, solange dieser Vertrag vollständig erfüllt wird.

Je mehr Fachlichkeit und Laufzeitkontext der Host übergibt, desto weniger ist das Remote eine autonome Anwendung und desto mehr wird es zu einem ausgelagerten UI-Ausschnitt der Shell.

Eine strenge Grenze ist deshalb sinnvoll: Der Host darf das Remote aktivieren und in das Produkt einordnen. Er sollte ihm aber keine fachlichen oder operativen Voraussetzungen liefern, ohne die es nicht funktionieren kann.

Das Remote als eigenständig startbare Anwendung

Das angestrebte Modell beginnt bei der Capability selbst:

Capability
├── Fachlichkeit
├── UI
├── Zustand
├── internes Routing
├── Authentifizierungsintegration
├── API-Integration
├── Fehlerbehandlung
└── Bootstrap

Die Capability verantwortet ihren fachlichen Zustand, ihre API-Grenze, ihre internen Navigationswege und ihre Fehlerfälle. Benötigte Infrastruktur wie Authentifizierung oder Konfiguration bindet sie selbst an.

Das bedeutet nicht, dass sie ohne externe Systeme auskommt. Eine Capability kann APIs, einen Identity Provider, Feature-Konfiguration oder kontrollierte Testdaten benötigen. Entwicklungsautonomie bedeutet nicht vollständige Isolation. Sie bedeutet Unabhängigkeit vom Host als fachlichem oder technischem Versorgungsdienst.

Ein autonomes Remote darf von externen Systemen abhängen. Es sollte aber nicht vom Host als Laufzeitdienst abhängen.

Host-Mountpoint und Remote-Mountpoint

Die Capability kann über zwei technische Einstiegspunkte aktiviert werden:

Produktbetrieb
Host-Mountpoint
└── mountet das Remote

Lokale Entwicklung
Remote-Mountpoint
└── mountet dasselbe Remote

Beide Einstiegspunkte starten dieselbe Anwendung.

Die Capability selbst sollte nicht wissen müssen, ob sie durch den Host oder ihren lokalen Remote-Mountpoint aktiviert wurde. Der Host-Mountpoint ordnet sie in das zusammengesetzte Produkt ein. Der Remote-Mountpoint stellt einen kleinen, eigenständigen Anwendungseinstieg für die lokale Entwicklung bereit.

Dieser lokale Mountpoint ist keine zweite Shell. Er baut den Host nicht nach, sondern führt denselben Bootstrap aus, initialisiert den Router, setzt einen lokalen Basispfad, lädt die eigene Konfiguration, startet die Authentifizierungsintegration und mountet die Capability in ein DOM-Ziel.

Er bildet weder fachlichen Hostzustand noch einen globalen Produkt-Store nach, erfindet keine Benutzerobjekte des Hosts und kopiert keine Shell-Services. Er aktiviert dieselbe Capability lediglich in einer kleineren Laufzeitumgebung.

Der lokale Mountpoint ersetzt nicht den Host. Er beweist, dass das Remote ihn für seine Funktionsfähigkeit nicht benötigt.

Ein Mountvertrag aktiviert – er versorgt nicht

Ein Mountvertrag sollte bewusst klein bleiben:

Mountvertrag
├── Remote-Einstieg
├── Container oder Route
├── Basispfad
├── Mount
└── Unmount

Je nach Integrationsform kann er noch kleiner ausfallen. Entscheidend ist nicht die genaue technische Signatur, sondern seine Verantwortung.

Ein Mountvertrag aktiviert eine Anwendung. Er versorgt sie nicht mit ihrer Fachlichkeit.

Benutzerzustand, Berechtigungen, fachliche Entitäten, globaler Produktzustand, fremde Store-Slices, Shell-Services, fachliche Konfiguration, ein zentraler Event-Bus oder interne Router-Objekte gehören in diesem Zielbild nicht in den Mountvertrag.

Nicht jede Übergabe ist technisch unmöglich oder in jedem Kontext verboten. Eine bewusst strenge Architekturposition macht jedoch die Folgen sichtbar. Sobald der Host fachlichen Zustand übergibt, muss er diesen Zustand kennen. Sobald er Berechtigungen berechnet, besitzt er einen Teil der Autorisierungslogik. Sobald er Fachobjekte beschafft, wird er an APIs und Lebenszyklen einer fremden Capability gekoppelt.

Der Mountvertrag sollte daher die technische Aktivierung beschreiben, nicht die fachliche Versorgung.

Gemeinsame Anmeldung ohne Auth-Zustand im Host

Authentifizierung ist das häufigste Argument dafür, ein Remote nur innerhalb des Hosts zu starten. Die gemeinsame Anmeldung wird dann mit einem gemeinsamen Authentifizierungszustand im Host gleichgesetzt.

Das ist nicht zwingend.

nicht:
Host
└── übergibt Benutzer, Token und Berechtigungen
        ↓
      Remote

sondern:
Identity Provider und bestehende Browsersession
├── Host integriert sich selbst
└── Remote integriert sich selbst

Host und Remote können denselben Identity Provider, dieselbe Anmeldung und dieselbe browserseitige Session nutzen. Daraus folgt nicht, dass der Host Besitzer des Authentifizierungszustands aller Remotes sein muss.

Das Remote bleibt selbst für die Initialisierung seiner Authentifizierungsintegration, den Bezug notwendiger Tokens, abgesicherte API-Aufrufe und die Behandlung einer fehlenden oder abgelaufenen Session verantwortlich. Berechtigungsentscheidungen innerhalb der Capability verbleiben ebenfalls dort, wo ihre fachliche Bedeutung bekannt ist.

Für die lokale Entwicklung gilt damit dasselbe Prinzip:

Remote-Mountpoint
└── startet das Remote
    └── Remote verwendet seine eigene Authentifizierungsintegration

Die Authentifizierungsintegration, die im Produktbetrieb funktioniert, muss auch über den Remote-Mountpoint initialisierbar sein, ohne dass der Host Benutzerzustand oder Berechtigungen übergibt.

Gemeinsame Infrastruktur ist keine Übergabe durch den Host.

Fachliche Daten gehören zur Capability

Dasselbe gilt für fachliche Daten.

problematisch für Autonomie:
Host lädt Kundendaten
→ übergibt sie an das Remote

autonomer:
Remote lädt die benötigte Projektion
→ über seine eigene API

Der Host sollte fremde Fachlichkeit nicht kennen. Das Remote sollte die Daten seiner Capability selbst beschaffen. Seine API-Grenze gehört zu seiner Verantwortung beziehungsweise zur Verantwortung der Capability, die es repräsentiert.

Eine Datenübergabe durch den Host kann kurzfristig bequem sein. Sie spart vielleicht einen sichtbaren API-Aufruf oder nutzt bereits vorhandene Daten. Gleichzeitig koppelt sie Lebenszyklen, Zuständigkeiten und lokale Entwicklungsumgebungen.

Für den eigenständigen Start müsste der Remote-Mountpoint diese Datenübergabe nachbauen. Genau an dieser Stelle wird die Laufzeitkopplung sichtbar: Das Remote simuliert nicht seine eigene externe Abhängigkeit, sondern einen Host, der normalerweise Fachlichkeit für es vorbereitet.

Tägliche Entwicklung, lokale Integration und Produktprüfung

Nicht jede Prüfung benötigt dieselbe Laufzeitumgebung. Drei klar getrennte Modi verhindern, dass die vollständige Produktkomposition zum reflexhaften Standard wird.

1. Tägliche Entwicklung

Remote-Mountpoint
└── Remote
    ├── eigene Fachlichkeit
    ├── eigene APIs
    ├── eigene Authentifizierungsintegration
    └── eigene Testdaten

Im innersten Entwicklungszyklus werden nur das bearbeitete Remote und seine tatsächlich notwendigen externen Abhängigkeiten gestartet.

Dieser Modus eignet sich für fachliche Änderungen, UI-Arbeit, lokale Zustandsänderungen, Fehlerbehandlung, API-Integration und Tests innerhalb der Capability. Er hält Rückkopplungszeiten kurz und macht die Verantwortung des Remotes sichtbar.

2. Gezielte lokale Integrationsprüfung

Host
└── bearbeitetes Remote im Entwicklungsmodus

Hier ist nicht die Capability allein Gegenstand der Prüfung, sondern ihre konkrete Integration in das Produkt.

Geprüft werden beispielsweise das korrekte Laden und Mounten, der Einstieg über die Produkt-URL, Basispfade und Deep Links, die verfügbare Layoutfläche, technische Navigation zwischen Produktbereichen, das Verhalten der gemeinsamen Anmeldung in der Komposition oder ein Ladefehler des Remotes.

Ein Werkzeugmodus, bei dem der Host zusammen mit genau dem bearbeiteten Remote gestartet wird, ist dafür praktisch. Weitere Bereiche können aus vorhandenen Preview-Versionen geladen oder deaktiviert werden; sie müssen nicht alle als lokale Entwicklungsserver laufen.

Host plus Entwicklungs-Remote ist ein sinnvoller Integrationsmodus. Er muss nicht der normale Entwicklungsmodus sein.

3. Produktprüfung

Preview- oder Testumgebung
├── Host
├── reale Remote-Versionen
├── reale Infrastruktur
└── ausgewählte produktweite Abläufe

In diesem Modus wird die tatsächliche Produktkomposition geprüft. Hier sind reale Remote-Versionen, gemeinsame Infrastruktur und ausgewählte produktweite Abläufe relevant.

Die vollständige Produktlandschaft muss dafür nicht dauerhaft auf jedem Entwicklerrechner rekonstruiert werden. Eine Preview- oder Testumgebung ist häufig realistischer und reproduzierbarer als eine lokale Sammlung unterschiedlich konfigurierter Dienste.

Die drei Modi bilden keine Qualitätsrangfolge. Sie beantworten unterschiedliche Fragen.

Wann der Host lokal tatsächlich benötigt wird

Der Host wird lokal dann benötigt, wenn die Integration mit dem Host Gegenstand der Prüfung ist.

Das klingt selbstverständlich, wird im Alltag aber häufig umgedreht: Der Host läuft immer, also wird jede Änderung automatisch in der vollständigen Komposition entwickelt. Dadurch verschwimmt die Grenze zwischen Capability-Entwicklung und Produktintegration.

Für eine Änderung an einer Validierungsregel, einer Ergebnisdarstellung oder einem internen Zustand liefert der Host meist keinen zusätzlichen Erkenntnisgewinn. Für einen neuen Einstiegspfad, ein geändertes Mountverhalten oder die Behandlung eines Ladefehlers dagegen schon.

Der Host ist damit kein grundsätzlich unnötiger Bestandteil der lokalen Entwicklung. Er ist ein gezielt eingesetzter Integrationspartner.

Externe Abhängigkeiten sind nicht automatisch Host-Abhängigkeiten

Ein eigenständig gestartetes Remote muss nicht ohne Infrastruktur auskommen. Je nach Capability kann es seine APIs, einen Identity Provider, Feature-Konfiguration oder kontrollierte Testdaten benötigen. Die zugehörigen Services können ihrerseits Datenbanken, Object Storage oder weitere technische Infrastruktur voraussetzen.

Für die lokale Entwicklung können solche Abhängigkeiten real verfügbar sein oder gezielt ersetzt werden. API-Mocks, simulierte Fehlerantworten, ein lokaler oder gemeinsam verfügbarer Identity Provider sowie temporäre Capability-Umgebungen sind legitime Mittel.

Die entscheidende Abgrenzung lautet:

legitim:
Remote simuliert seine eigenen externen Systeme

problematisch für die behauptete Autonomie:
Remote simuliert die Shell, weil die Shell es normalerweise versorgt

Das Remote darf seine externen Systeme simulieren. Es sollte nicht den Host simulieren müssen.

Diese Unterscheidung verhindert ein Missverständnis: Entwicklungsautonomie bedeutet nicht, dass jedes Remote ein vollständig eigenständig vermarktbares Produkt sein oder jede Infrastruktur lokal nachbilden muss. Entscheidend ist, wem die Abhängigkeit fachlich und operativ gehört.

Was der lokale Start über die Architektur verrät

Die lokale Startbarkeit ist eine praktische Architekturprobe.

Wenn für eine kleine Änderung zuerst der Host, weitere Remotes und mehrere zentrale Dienste gestartet werden müssen, sollte jede einzelne Abhängigkeit hinterfragt werden:

Host starten
→ weitere Remotes starten
→ globalen Produktzustand initialisieren
→ zentrale Testdaten vorbereiten
→ vollständigen Loginpfad durchlaufen
→ Produktnavigation bis zur Capability ausführen

Mögliche Ursachen liegen selten im Startbefehl selbst. Vielleicht liegt Fachlogik im Host. Vielleicht besitzt die Shell fachlichen Zustand, berechnet Berechtigungen oder stellt interne Services bereit. Vielleicht liest das Remote fremde Store-Bereiche, besitzt keine eigene API-Grenze oder hängt von internen Navigationsobjekten des Hosts ab.

Auch ein anderer Befund ist möglich: Mehrere Remotes bilden in Wahrheit gemeinsam eine Capability. Dann ist nicht zwingend jedes Remote falsch umgesetzt, aber die behauptete fachliche Eigenständigkeit stimmt nicht mit der Laufzeitrealität überein.

Nicht jede Abhängigkeit beweist automatisch eine schlechte Grenze. Ein Remote kann allein startbar und trotzdem fachlich schlecht geschnitten sein. Lokale Startbarkeit ist ein starkes Indiz für Autonomie, aber kein alleiniger Beweis.

Umgekehrt ist ein Remote, das ohne den Host überhaupt nicht sinnvoll betrieben oder fachlich geprüft werden kann, sehr wahrscheinlich keine autonome Anwendungseinheit.

Alles, was für den lokalen Start aus dem Host nachgebaut werden müsste, sollte deshalb als potenzielle Laufzeitkopplung sichtbar und bewusst begründet werden.

Entwicklungsautonomie als Konsequenz klarer Grenzen

Lokale Entwicklungsautonomie ist kein Komfortmerkmal. Sie ist ein beobachtbares Ergebnis klarer Grenzen.

Ein eigener Remote-Mountpoint verkürzt nicht nur den Startvorgang. Er erzwingt eine ehrliche Antwort auf die Frage, welche Verantwortung tatsächlich innerhalb der Capability liegt. Besitzt sie ihren fachlichen Zustand sowie ihre API- und Authentifizierungsintegration selbst, kann sie über einen kleinen Anwendungseinstieg aktiviert werden.

Der Host bleibt wichtig: Er integriert das Remote in das Produkt und wird für gezielte Integrationsprüfungen benötigt. Er muss aber nicht an jeder täglichen Änderung innerhalb der Capability beteiligt sein. Gemeinsame Anmeldung, gemeinsame Infrastruktur und technische Standards bleiben möglich, ohne Benutzerzustand, Berechtigungen oder fachliche Entitäten durch den Host zu übergeben.

Der lokale Mountpoint baut keine zweite Shell. Er aktiviert dieselbe Capability in einer kleineren Laufzeitumgebung. Eigene externe Systeme dürfen simuliert werden; der Host sollte nicht simuliert werden müssen.

Ein Microfrontend sollte daher nicht nur separat gebaut und ausgeliefert werden können. Es sollte über einen eigenen Mountpoint als eigenständige Anwendung gestartet, entwickelt und fachlich geprüft werden können. Lokale Startbarkeit beweist noch keine gute fachliche Grenze, macht Laufzeitkopplung aber unmittelbar sichtbar.

Benötigt ein Remote für seinen normalen lokalen Start den Host, fremde Remotes und deren Zustand, sollte geprüft werden, ob tatsächlich eine autonome Capability oder nur ein technisch ausgelagerter Teil des Gesamtprodukts entstanden ist.

Der Host darf ein Remote mounten. Er sollte es nicht am Leben erhalten.