Globale Events zwischen unterschiedlichen Frameworks

Globale Events entkoppeln Microfrontends nicht automatisch. Browser-native Events können als Transport für wenige, flüchtige und frameworkneutrale Plattform-Intents sinnvoll sein. Sobald Remotes darüber fachliche Ereignisse verteilen, Zustand synchronisieren oder Reaktionen anderer Remotes steuern, entsteht jedoch versteckte horizontale Kopplung.

Ein Remote darf die Plattform um eine globale Darstellung oder technische Reaktion bitten. Über einen globalen Event-Bus sollte es jedoch nicht die Fachlogik anderer Remotes koordinieren.

Globale Events dürfen die Plattform koordinieren – nicht die Facharchitektur

Eine Anwendung besteht aus einem Angular-Host, einem Angular-Remote und einem React-Remote. Beide Remotes können Daten bearbeiten. Nach einem erfolgreichen Speichervorgang soll eine globale Erfolgsmeldung erscheinen.

Das Notification-System gehört dem Host. Er besitzt die globale Darstellung, kennt das Theme, berücksichtigt Fokusführung und Barrierefreiheit und entscheidet, wo und wie lange eine Meldung sichtbar bleibt. Das React-Remote kann diese Angular-Komponente nicht verwenden. Es sollte aber auch keinen Angular-Service, keinen Host-Store und keinen NgRx-Dispatcher kennen.

Dasselbe gilt für das Angular-Remote. Es könnte technisch leichter auf Angular-Interna des Hosts zugreifen. Daraus folgt jedoch nicht, dass es das tun sollte. Dass beide Seiten dasselbe Framework verwenden, ist lediglich ein technischer Umstand. Der Plattformvertrag bleibt eine Anwendungsgrenze.

Beide Remotes müssen nur ausdrücken können, was der Nutzer erfahren soll:

type NotificationSeverity = 'success' | 'info' | 'warning' | 'error';

interface NotificationIntent {
  severity: NotificationSeverity;
  message: string;
}

Dieser Vertrag beschreibt keine Angular-Komponente und keine React-Komponente. Er enthält weder einen Store noch einen Service. Er sagt lediglich: Die Plattform soll den Nutzer mit einer Nachricht einer bestimmten Dringlichkeit informieren.

Das ist die erste wichtige Unterscheidung: NotificationIntent beschreibt die semantische Bedeutung der Nachricht. Er ist noch keine Aussage darüber, wie sie die technische Grenze überquert und wie der Host sie verarbeitet.

Intent, Transport und Verarbeitung sind drei Ebenen

Bei frameworkübergreifender Kommunikation werden häufig drei verschiedene Fragen vermischt:

1. Was bedeutet die Nachricht?
2. Wie gelangt sie über die Anwendungsgrenze?
3. Was macht der Empfänger intern daraus?

Im Notification-Beispiel lautet die Bedeutung: Der Nutzer soll über den erfolgreichen Abschluss informiert werden. Der Transport kann ein direkter Funktionsaufruf oder ein CustomEvent auf einem EventTarget sein. Hinter der Grenze kann der Angular-Host einen Service aufrufen, ein Signal aktualisieren, eine Queue bedienen, einen Signal Store verändern oder ein internes NgRx-Event auslösen.

Diese Entscheidungen gehören nicht in denselben Vertrag.

Der Intent ist nicht das Browser-Event. Das Browser-Event ist lediglich eine mögliche Transportform des Intents. Ebenso ist ein internes NgRx-Event nicht der frameworkübergreifende Vertrag. Es ist eine Implementierungsentscheidung des Hosts.

Der Plattformvertrag endet am Host-Adapter. Dahinter beginnt die interne Architektur des Hosts.

Derselbe Vertrag für Angular und React

Der Host kann einen kleinen frameworkneutralen Plattformkontext bereitstellen:

interface PlatformNotifications {
  show(intent: NotificationIntent): void;
}

interface PlatformContext {
  notifications: PlatformNotifications;
}

Das Angular-Remote verwendet diesen Vertrag:

platform.notifications.show({
  severity: 'success',
  message: 'Die Planung wurde gespeichert.',
});

Das React-Remote verwendet denselben Vertrag:

platform.notifications.show({
  severity: 'success',
  message: 'Changes saved.',
});

Beide Anwendungen sehen dieselbe Plattformfähigkeit. Keine von ihnen kennt die konkrete Notification-Komponente des Hosts. Das Angular-Remote injiziert keinen Host-Service, verändert keinen fremden Store und importiert keinen internen Event-Creator. Das React-Remote kennt weder Angular Dependency Injection noch NgRx.

Der Host stellt lediglich den Adapter bereit:

const platformContext: PlatformContext = {
  notifications: {
    show: (intent) => {
      notificationAdapter.show(intent);
    },
  },
};

Der Adapter übersetzt den stabilen Plattformvertrag in die aktuelle interne Lösung. Heute kann er einen Notification-Service aufrufen. Später kann er eine Queue einführen oder den Intent in ein hostinternes Event übersetzen. Solange der äußere Vertrag bestehen bleibt, müssen die Remotes diese Änderung nicht nachvollziehen.

NgRx, Signals oder ein interner Event-Dispatcher sind dabei nicht das Problem. Problematisch wäre nur, sie über die Host-Grenze hinaus zum Integrationsvertrag zu machen.

Ein Remote sendet kein NgRx-Event an Angular. Es äußert einen frameworkneutralen Intent, den der Angular-Host in seine eigene Architektur übersetzt.

Ein direkter Plattformvertrag ist oft die einfachere Leitung

Wenn der Host ein Remote selbst mountet, besitzt er bereits eine direkte technische Beziehung zu dieser Anwendung. Er kann den Plattformkontext beim Mount übergeben:

interface RemoteApplication {
  mount(container: HTMLElement, context: PlatformContext): void;

  unmount(): void;
}

Der Host startet das React-Remote dann beispielsweise so:

reactRemote.mount(container, platformContext);

Das ist kein Angular- und kein React-Mechanismus. Es ist ein normaler JavaScript-Vertrag zwischen zwei Anwendungen.

Diese Variante hat einen sichtbaren Owner und einen erwarteten Empfänger. Der Aufruf ist typisierbar, leicht zu testen und an den Lebenszyklus des Remotes gebunden. Es gibt keine globale Suche nach Listenern und keine unbekannte Zahl möglicher Reaktionen.

Deshalb ist ein direkter Plattformvertrag häufig verständlicher, wenn der Host den Plattformkontext ohnehin bereitstellen kann. Frameworkübergreifende Kommunikation benötigt nicht automatisch browser-native Events.

Das macht den Funktionsaufruf nicht grundsätzlich überlegen. Es beschreibt nur eine andere technische Adressierung. Auch ein Callback kann einen schlechten fachlichen Vertrag transportieren. Umgekehrt kann ein Browser-Event einen klar begrenzten Plattform-Intent transportieren.

Callback und CustomEvent sind unterschiedliche Leitungen für dieselbe Nachricht. Keine der beiden Leitungen entscheidet, ob die Nachricht architektonisch sauber ist.

Wann ein browser-natives Event sinnvoll sein kann

Nicht jede Integration besitzt eine direkte Mount-Beziehung. Anwendungen können unabhängig geladen werden. Der Plattformkontext ist möglicherweise nicht direkt verfügbar, oder ein bewusst definierter technischer Kanal ist Teil der Produktplattform.

Dann kann ein browser-natives Event eine passende Transportform sein:

platformEvents.dispatchEvent(
  new CustomEvent('platform:notification-requested', {
    detail: {
      severity: 'success',
      message: 'Changes saved.',
    },
  }),
);

Der Angular-Host registriert einen Listener auf diesem Kanal und übergibt die Payload anschließend an seinen Adapter. Erst dort beginnt wieder die interne Angular-Architektur.

Wichtig ist die Begrenzung des Kanals. Ein produktbezogenes EventTarget, das über den Plattformkontext bereitgestellt wird, ist kontrollierbarer als ein unkontrollierter Event-Bus auf window:

interface PlatformContext {
  events: EventTarget;
}

Global für das Produkt muss nicht global auf window bedeuten.

Ein EventTarget kann sinnvoll sein, wenn bewusst keine direkte Referenz bestehen soll oder mehrere ausdrücklich vorgesehene technische Beobachter existieren. Unabhängige Ladezeitpunkte löst er allerdings nicht: Wer beim Dispatch nicht registriert ist, verpasst die Nachricht. Er ist deshalb nicht automatisch die bessere Lösung, nur weil Angular und React beteiligt sind.

Die Beteiligung unterschiedlicher Frameworks begründet lediglich die Notwendigkeit eines frameworkneutralen Vertrags. Sie schreibt dessen Transport nicht vor.

Event, Intent und State sind nicht dasselbe

Die technische Klasse CustomEvent sagt nichts darüber aus, welche architektonische Bedeutung ihre Payload besitzt. Sie kann ein Ereignis, einen Intent, eine Zustandsänderung oder einen problematischen Steuerbefehl transportieren.

Eine knappe semantische Unterscheidung hilft:

Event
└── etwas ist geschehen

Intent
└── die Plattform soll etwas tun

State
└── etwas gilt aktuell

OrderCreated beschreibt eine abgeschlossene fachliche Tatsache. NotificationRequested bittet die Plattform um eine Darstellung. CurrentLocale beschreibt einen aktuell geltenden Zustand.

Diese Begriffe müssen nicht akademisch bis in jede Grenzfrage aufgelöst werden. Entscheidend ist, dass der Transport nicht mit der Bedeutung verwechselt wird. Ein CustomEvent namens refreshRemoteB bleibt ein problematisches Remote-to-Remote-Kommando. Ein direkter Funktionsaufruf kann dagegen einen legitimen Plattform-Intent übergeben.

Die Browser-API klassifiziert nicht die Architektur. Entscheidend ist, was die Nachricht bedeutet, wem die Reaktion gehört und wer von ihrem Auftreten abhängig wird.

Notifications passen zu einer Plattformfähigkeit

Globale Notifications sind ein brauchbares Beispiel, weil sie einen klaren UI-Owner besitzen. Der Host kontrolliert die gemeinsame Produktoberfläche. Er kann Darstellung, Theme, Positionierung, Fokus und Accessibility konsistent behandeln.

Der Intent ist außerdem flüchtig. Ein später gestartetes Remote muss eine alte Erfolgsmeldung nicht rekonstruieren. Die Notification ist keine autoritative fachliche Zustandsquelle. Normalerweise erwartet das sendende Remote keine Antwort, und kein anderes Remote muss fachlich auf die Meldung reagieren.

Genau diese Eigenschaften begrenzen die Abhängigkeit:

• ein klarer Owner im Host,
• eine einfache frameworkneutrale Payload,
• eine kurzlebige Wirkung,
• keine fachliche Reaktionskette zwischen Remotes,
• kein Anspruch, dauerhaft aktuellen Zustand zu repräsentieren.

Ähnliche Plattformfähigkeiten können etwa globale Hilfe, Navigation, eine Command Palette oder Telemetrie betreffen. Auch dort bleibt zu prüfen, ob eine direkte Plattformfunktion verständlicher ist als ein Event. Der globale Kanal ist kein Sammelplatz für alles, was mehr als eine Anwendung betrifft.

Zustand darf nicht nur als Event existieren

Bei flüchtigen Notifications ist es unproblematisch, wenn ein später geladenes Remote eine frühere Nachricht nicht kennt. Für Plattformzustand gilt das nicht.

Ein Ereignis wie localeChanged kann mitteilen, dass sich die Sprache geändert hat. Ein Remote, das erst danach startet, hat dieses Ereignis jedoch verpasst. Ohne weitere Quelle kennt es den aktuellen Wert nicht.

Ein Plattformzustand benötigt deshalb eine aktuell abfragbare Repräsentation und optional eine Benachrichtigung über Änderungen:

interface LocaleSource {
  current(): string;

  subscribe(listener: (locale: string) => void): () => void;
}

Dasselbe Prinzip gilt für Theme, Session, aktuellen Benutzer, Berechtigungen, Feature-Konfiguration, Mandant oder Netzwerkstatus. Ein Event kann eine Zustandsänderung ankündigen. Es darf nicht die einzige Quelle des aktuellen Zustands sein.

Flüchtige Nachrichten dürfen keinen Zustand ersetzen, den ein später gestartetes Remote rekonstruieren können muss.

Diese Grenze ist besonders wichtig, weil globale Event-Kanäle leicht wie ein einfacher Synchronisierungsmechanismus wirken. Zunächst wird nur localeChanged verteilt. Danach folgen sessionUpdated, permissionsChanged und featureFlagsLoaded. Mit jedem weiteren Ereignis wächst die Annahme, dass alle relevanten Anwendungen zum richtigen Zeitpunkt zuhören und jede Nachricht genau in der erwarteten Reihenfolge erhalten.

Das ist keine belastbare Zustandsarchitektur. Es ist zeitliche Kopplung.

Fachliche Events zwischen Remotes bleiben horizontale Kommunikation

Problematisch wird der globale Kanal, sobald ein Remote fachliche Nachrichten veröffentlicht, damit andere Remotes darauf reagieren.

Ein Angular-Remote meldet beispielsweise:

planningSaved

Daraufhin lädt ein React-Remote Daten neu, ein Vue-Remote aktualisiert ein Badge und der Host verändert die Navigation.

Der Sender importiert keine Funktion aus den anderen Remotes. Er kennt vielleicht nicht einmal ihre Namen. Trotzdem hängen alle Consumer von seiner Nachricht ab: vom Event-Namen, von der Payload, vom Zeitpunkt, von der Reihenfolge, vom Ausbleiben oder mehrfachen Auftreten und von der jeweiligen Vertragsversion.

Aus einer sichtbaren Verbindung

Remote A ─────────▶ Remote B

wird eine indirekte Struktur:

Remote A
└── planningSaved
        │
        ▼
globaler Event-Bus
        │
        ├── Remote B lädt Daten neu
        ├── Remote C aktualisiert ein Badge
        └── Host verändert die Navigation

Der Abhängigkeitsgraph ist nicht kleiner geworden. Er ist nur schwerer sichtbar.

Der Sender kennt seine Empfänger nicht mehr. Ihre Abhängigkeit von seiner Nachricht bleibt jedoch bestehen.

Das widerspricht nicht der Forderung, dass Remotes nicht direkt miteinander kommunizieren sollen. Es präzisiert sie: Eine indirekte fachliche Reaktionskette über einen globalen Bus ist weiterhin horizontale Kommunikation. Sie wird nicht dadurch vertikal, dass der Browser zwischen Sender und Empfänger steht.

Keine direkte Referenz bedeutet noch keine Unabhängigkeit

Direkte Kopplung ist leicht zu erkennen:

remoteB.reload();

Eventbasierte Kopplung wirkt diffuser:

events.dispatchEvent(new CustomEvent('planning:saved'));

Wenn Remote B fachlich darauf angewiesen ist, nach planning:saved neu zu laden, bleibt die Abhängigkeit real. Sie liegt nur nicht mehr an der Stelle, an der das Ereignis ausgelöst wird. Stattdessen verteilt sie sich über Listener, Registrierungen und Reaktionslogik.

Ein Event-Bus kann technische Referenzen reduzieren. Er garantiert keine fachliche Unabhängigkeit. Im ungünstigen Fall verschleiert er sogar, welche Anwendungen gemeinsam geändert und getestet werden müssen.

Lose Adressierung ist nicht dasselbe wie lose fachliche Kopplung.

Der Mythos lautet: Weil der Sender seine Consumer nicht kennt, seien die Anwendungen entkoppelt. Tatsächlich wurde nur die Richtung der statischen Referenz entfernt. Die Verhaltensabhängigkeit bleibt bestehen. Ändert sich die Bedeutung von planningSaved, reagieren mehrere unbekannte Stellen möglicherweise falsch. Wird das Ereignis nicht ausgelöst, bleiben Projektionen veraltet. Wird es zweimal ausgelöst, entstehen doppelte Ladevorgänge. Startet ein Consumer zu spät, verpasst er die Nachricht.

Ein globaler Event-Bus beseitigt die Kopplung nicht. Er entfernt sie häufig nur aus dem sichtbaren Abhängigkeitsgraphen.

Der Event-Bus wird zur versteckten Anwendungsarchitektur

Ein globaler Kanal beginnt selten als umfassende fachliche Infrastruktur. Zunächst enthält er eine Notification und vielleicht ein technisches remoteReady. Dann kommen planningSaved, customerChanged, selectionChanged, refreshRequested und dataReloaded hinzu.

Nach einiger Zeit entstehen Reaktionsketten:

planningSaved
└── refreshRequested
    └── dataReloaded
        └── selectionChanged
            └── badgeUpdated

Jede einzelne Nachricht kann lokal plausibel wirken. Gemeinsam bilden sie jedoch einen verteilten Ablauf, dessen Kontrolle an keiner Stelle mehr vollständig sichtbar ist.

Dann werden Reihenfolge und Ladezeitpunkt relevant. Ereignisse können verloren gehen oder mehrfach verarbeitet werden. Listener bleiben nach dem Unmount aktiv. Ein erneuter Mount registriert denselben Handler ein zweites Mal. Notifications erscheinen doppelt, Daten werden mehrfach geladen und Tests hängen davon ab, welche Anwendung zuerst gestartet wurde.

Auch die Ownership wird unklar. Wer darf selectionChanged auslösen? Welche Payload ist verbindlich? Muss ein neuer Consumer alle historischen Sonderfälle verstehen? Wer entscheidet, wann ein Event entfernt werden darf? Welche Reaktion markiert den Abschluss der Kette?

Der Event-Bus wird zur versteckten Anwendungsarchitektur, sobald fachliche Abläufe von seinen Reaktionsketten abhängen.

Das Problem ist nicht die Browser-API. Dasselbe könnte mit einem selbst geschriebenen Dispatcher oder einer geteilten Bibliothek entstehen. Problematisch ist der globale, implizite Verhaltensvertrag zwischen fachlich eigenständigen Anwendungen.

Vertikal zur Plattform, nicht horizontal zwischen Remotes

Der Notification-Intent besitzt eine klare Richtung:

Remote
└── Notification-Intent
        │
        ▼
Host-Plattform
└── besitzt Darstellung und Reaktion

Der Host ist der definierte Owner der globalen UI. Andere Remotes müssen auf die Nachricht nicht fachlich reagieren. Der Vertrag bleibt frameworkneutral und beschreibt eine Plattformfähigkeit.

Ein fachliches Event zwischen Remotes besitzt eine andere Struktur:

Remote A
└── fachliches Event
        │
        ▼
globaler Event-Bus
        │
        ▼
Remote B und Remote C
└── müssen darauf reagieren

Hier entstehen mehrere implizite Consumer und fachliche Reaktionsketten. Der Abschluss ist unklar, der Abhängigkeitsgraph verteilt sich über die Anwendung und eine Änderung kann mehrere Remotes gleichzeitig betreffen.

Vertikale Kommunikation mit der Plattform kann sinnvoll sein. Horizontale Koordination zwischen Remotes bleibt problematisch.

Diese Unterscheidung hängt nicht am Event-Namen allein. Auch notificationRequested wäre schlecht geschnitten, wenn mehrere Remotes daraus eigene fachliche Abläufe ableiteten. Umgekehrt kann ein Host intern beliebige Mechanismen verwenden, solange sie hinter seiner Grenze bleiben und nicht zum Vertrag aller Remotes werden.

Die Bedeutung, Richtung und Ownership der Nachricht entscheiden darüber, ob sie eine Plattformfähigkeit oder eine versteckte horizontale Abhängigkeit beschreibt.

Auch kleine Plattformverträge brauchen Pflege

Ein legitimer Plattform-Intent ist kein rechtsfreier Raum. Der Vertrag benötigt einen klaren Owner, eine dokumentierte Payload und einen eindeutigen Namen.

platform:notification-requested beschreibt die Absicht besser als update, changed oder showSuccess. Der Name verweist auf die Plattformfähigkeit, nicht auf eine konkrete Snackbar-Komponente. Die Payload sollte aus einfachen frameworkneutralen Daten bestehen.

Komponenteninstanzen, Angular-Services, React Nodes, Stores oder fachliche Aggregate gehören nicht in einen globalen Transportvertrag. Ebenso wenig sollten Framework-Callbacks in Event-Payloads die Grenzen wieder indirekt durchlöchern.

Änderungen müssen bewusst erfolgen. Neue optionale Felder sind leichter rückwärtskompatibel einzuführen als eine vollständig veränderte Bedeutung. Bei größeren Brüchen kann ein neuer Name oder eine neue Vertragsversion klarer sein. Dafür ist keine umfangreiche Schema-Registry erforderlich. Notwendig ist zunächst nur die Einsicht, dass auch ein kleiner Browser-Event einen gepflegten Plattformvertrag darstellt.

Listener gehören zum Lifecycle

Wer einen globalen Event-Kanal anbietet, muss auch dessen Lifecycle besitzen.

Ein Listener wird beim Mount registriert und beim Unmount entfernt. Diese Symmetrie ist Teil des Integrationsvertrags, keine nachträgliche Aufräumarbeit.

mount
└── Listener registrieren

unmount
└── Listener entfernen

Ohne klares Cleanup bleiben veraltete Handler aktiv. Erneutes Mounten erzeugt doppelte Registrierungen. Nicht mehr sichtbare Anwendungen reagieren weiter, Tests beeinflussen sich gegenseitig und kurzlebige technische Nachrichten hinterlassen globalen Restzustand.

Ein globales Event ohne klares Cleanup ist keine lose Kopplung, sondern globaler Restzustand.

Auch hier spricht nichts grundsätzlich gegen Browser-Events. Der Lifecycle muss nur ebenso bewusst gestaltet werden wie der Kanal selbst.

Ein kleiner Event-Kanal ist ein Qualitätsmerkmal

Ein sinnvoller globaler Kanal enthält wenige, bewusst ausgewählte Plattformverträge. Sie besitzen einen klaren Owner, transportieren einfache Daten und lösen keine fachlichen Reaktionsketten zwischen Remotes aus.

Geeignet sind flüchtige technische oder UI-bezogene Plattform-Intents, bei denen keine Antwort erforderlich ist und die Nachricht keinen dauerhaft rekonstruierbaren Zustand ersetzen soll.

Nicht auf diesen Kanal gehören die Synchronisierung fachlichen Zustands, Remote-to-Remote-Kommandos wie refreshRemoteB, globale CRUD-Ereignisse, die Orchestrierung von Geschäftsprozessen, fremde Stores oder ein Ersatz für eine autoritative Datenquelle.

Die Größe des Kanals ist deshalb mehr als eine Geschmacksfrage. Sie zeigt, ob die Produktplattform wenige klar besessene Fähigkeiten anbietet oder ob der Bus bereits die fachliche Integration der Remotes übernommen hat.

Ein guter globaler Event-Kanal bleibt klein, flüchtig und langweilig.

Fazit

Angular- und React-Remotes können denselben frameworkneutralen Notification-Intent an einen Angular-Host übergeben. Ob dafür ein direkter Plattformvertrag oder ein browser-natives Event verwendet wird, ist eine technische Transportentscheidung. Erst der Host-Adapter übersetzt den Intent in einen Service-Aufruf, ein Signal, einen Store, eine Queue oder ein internes NgRx-Event.

Der Transport ist nicht mit der semantischen Bedeutung der Nachricht gleichzusetzen. Eine Notification ist ein flüchtiger Plattform-Intent mit einem klaren UI-Owner. Ein aktueller Plattformzustand benötigt dagegen zusätzlich eine abfragbare Quelle, damit später gestartete Remotes ihn rekonstruieren können.

Fachlicher Zustand und fachliche Ereignisse gehören nicht auf einen globalen Kanal, wenn andere Remotes davon abhängig werden. Der Event-Bus entfernt dann lediglich die direkte Referenz, nicht die horizontale Kopplung. Seine technische Eleganz ändert nichts an den gemeinsamen Namen, Payloads, Reihenfolgen, Ladezeitpunkten und Reaktionsketten.

Keine direkte Referenz bedeutet noch keine unabhängige Veränderbarkeit.

Ein guter globaler Event-Kanal bleibt klein, flüchtig und langweilig: Er koordiniert die Plattform, nicht die Fachlichkeit.