Module Federation
Module Federation klingt in Präsentationen elegant. In der Praxis ist es ein permanentes Versionsmanagement-Problem.
Was gut funktioniert
Abschnitt betitelt „Was gut funktioniert“- Unabhängige Deployments: Remote X kann deployen, ohne auf Remote Y zu warten.
- Technologie-Heterogenität: Angular-Shell lädt React-Remote. Das funktioniert.
- Klare Bounded-Context-Grenzen: Module Federation erzwingt Konversationen über Domänengrenzen.
Was schmerzt
Abschnitt betitelt „Was schmerzt“Shared Dependencies: Wer Angular 21 als Singleton teilt, hat ein Problem, sobald ein Remote auf 22 will. Versionskonflikte sind nicht theoretisch — sie passieren.
Fehlerdiagnose: Laufzeitfehler durch falsch konfigurierte Remote-Entries sind schwer zu debuggen. Stack-Traces helfen wenig.
Build-Konfiguration: Webpack Federation Config ist nicht intuitiv. shared, eager, singleton — falsch gesetzt, und ein Remote lädt zwei Instanzen von Zone.js.
Type-Safety: Cross-Remote-Typen teilen bedeutet: gemeinsame Type-Libraries in Nx, Versionierung dieser Libraries, mögliche Breaking Changes.
Lessons Learned aus Taskly
Abschnitt betitelt „Lessons Learned aus Taskly“- Nx managed alles: Ohne Nx wäre die Verwaltung von 6+ Remotes nicht skalierbar.
- Shared Libraries müssen stabil sein: Brechen sie, brechen alle.
- Preview-Deployments pro Remote: Jedes Remote hat eigene CI/CD-Pipeline und Preview-URL.
- Affected-basierte Deployments: Nur geänderte Remotes werden neu deployed — das spart Zeit und Risiko.
Module Federation ist das richtige Werkzeug — aber es hat seinen Preis. Wer ihn nicht einkalkuliert, zahlt ihn trotzdem.