Micro Frontends

Ein Micro Frontend ist ein Stück UI, das ein Team unabhängig baut, testet und ausliefert und das dann mit den anderen zur Laufzeit im Browser zusammengesetzt wird. Das entscheidende Wort ist „unabhängig“: Wenn zwei Teile zusammen ausgeliefert werden müssen, sind sie keine Micro Frontends, sondern Module derselben Anwendung — egal, wie getrennt ihre Ordner sind.

Die Architektur löst ein organisatorisches Problem, kein technisches: mehrere autonome Teams, die in unterschiedlichem Rhythmus ausliefern wollen, ohne sich gegenseitig zu blockieren. Der Preis ist Komplexität zur Laufzeit: Versionen von Abhängigkeiten, Integrationsfehler, visuelle Konsistenz, Testing, Observability.

Was es ist und was nicht

Ein Micro-Frontend-System hat drei Eigenschaften, alle drei sind Pflicht:

• Separater Build — jeder Teil hat seine eigene Pipeline und seine eigene package.json (oder zumindest sein eigenes Build-Target).
• Separates Deployment — das Catalog-Team veröffentlicht eine neue Version, ohne dass die Shell oder das Cart-Team etwas tun müssen.
• Komposition zur Laufzeit — eine Shell (Host) erfährt erst im Browser, welche Version jedes Remotes sie laden soll, meist aus einem Manifest.

BUILD-TIME — KEIN Micro Frontend
  libs/catalog ─┐
  libs/cart    ─┼─► ng build shell ─► ein einziges Deployment
  libs/reviews ─┘
  eine Version, ein Release, Verträge vom Compiler geprüft

RUNTIME — Micro Frontends
  catalog → build → deploy → catalog…/remoteEntry.json ─┐
  cart    → build → deploy → cart…/remoteEntry.json    ─┼─► die Shell komponiert sie
  reviews → build → deploy → reviews…/remoteEntry.json ─┘   im Browser
  N Versionen, N Releases, Verträge erst zur Laufzeit geprüft

Echte Gründe, falsche Gründe

Die Gründe, die den Preis rechtfertigen, drehen sich fast alle um Menschen und Auslieferung:

• Autonome Teams mit unterschiedlicher Taktung. Das Checkout-Team liefert mehrmals täglich aus, das Catalog-Team einmal pro Woche, und ein gemeinsames Release blockiert beide: Eine Regression im Katalog stoppt einen dringenden Payment-Fix.
• Sehr große Organisationen. Dutzende Frontend-Entwickler am selben Produkt, mehrere Fachdomänen, jede mit klarer Verantwortung (Conways Gesetz: Die Architektur bildet am Ende ohnehin die Organisation ab).
• Schrittweise Migration (Strangler Fig). Eine neue Shell „umhüllt“ die alte Anwendung (AngularJS, ein älteres Angular, ein anderes Framework); Screens werden einer nach dem anderen migriert, und der alte Code schrumpft, bis er verschwindet — ohne einen „Big-Bang“-Rewrite.
• Getrennte Produkte unter einer Erfahrung: Übernahmen, Geschäftsbereiche, Portale, die bestehende Anwendungen zusammenführen.

Falsche Gründe klingen in Präsentationen gut, haben aber günstigere Lösungen:

Der Preis

Jeder der folgenden Kosten taucht in der Praxis auf; der Unterschied zwischen einem gesunden und einem fragilen System ist, ob du von Anfang an einen Plan dafür hast.

Native Federation Schritt für Schritt

Native Federation setzt das Module-Federation-Modell auf Webstandards um: Remotes sind gewöhnliche ES-Module, verbunden über eine Import Map. Für Angular 22 ist das Paket @angular-architects/native-federation 22.x — die Version folgt dem Angular-Major.Minor — und es bleibt beim esbuild-Builder der CLI (@angular/build:application), den es umhüllt. Das Projekt ist in die Organisation github.com/native-federation umgezogen. Der Mechanismus, Schritt für Schritt:

1. Build. Jedes Remote erzeugt ES-Module und eine remoteEntry.json: was es exponiert (./routes → die erzeugte Datei) und welche Abhängigkeiten es teilt, mit version, requiredVersion, singleton, strictVersion.
2. Start der Shell. main.ts ruft initFederation() vor Angular auf: Es liest das Manifest (Name → URL), lädt die Metadaten jedes Remotes, verhandelt die Versionen und schreibt die Import Map (mit es-module-shims).
3. Bootstrap. Erst dann startet import('./bootstrap') Angular. Deshalb verschiebt das Schematic das Bootstrap in eine eigene Datei: @angular/core muss über die Import Map aufgelöst werden, also muss sie zuerst existieren.
4. Navigation. loadRemoteModule('catalog', './routes') ist im Kern ein dynamisches import() einer URL auf dem Server des Catalog-Teams. Wenn der Code des Remotes import '@angular/core' ausführt, leitet die Import Map ihn zur Kopie der Shell: ein Angular, ein Root-Injector.

# die Version des Adapters folgt dem Angular-Major.Minor (22.2.x für Angular 22.2)
npm i -D @angular-architects/native-federation

ng g @angular-architects/native-federation:init \
  --project catalog --port 4201 --type remote
ng g @angular-architects/native-federation:init \
  --project shell --port 4200 --type dynamic-host

# Was das Schematic ändert:
#  • build/serve → @angular-architects/native-federation:build,
#    das an @angular/build:application (esbuild) delegiert
#  • main.ts → initFederation(...), danach import('./bootstrap');
#    das alte Bootstrap landet in bootstrap.ts
#  • erzeugt federation.config.mjs (+ public/federation.manifest.json beim dynamic-host)
#  • fügt es-module-shims zu den Polyfills hinzu (Import Maps mit Scopes)
#  • mit --webcomponent: Bootstrap als Custom Element (createApplication + define)

// catalog/federation.config.mjs — ein Remote, so wie 22.x es erzeugt
import {
  withNativeFederation,
  fromPackageJson,
} from '@angular-architects/native-federation/config';

export default withNativeFederation({
  name: 'catalog',

  exposes: {
    // die öffentliche API des Remotes
    './routes': './projects/catalog/src/app/catalog.routes.ts',
  },

  shared: fromPackageJson({
    singleton: true,
    strictVersion: true,
    requiredVersion: 'auto',
    build: 'package',
  })
    // ganz @angular/core, inklusive der Secondary Entry Points → eine einzige Kopie
    .patch(['@angular/core'], { includeSecondaries: { keepAll: true } }),

  skip: ['rxjs/ajax', 'rxjs/fetch', 'rxjs/testing', 'rxjs/webSocket'],

  features: { denseChunking: true },
});

// shell/src/main.ts — läuft VOR Angular:
// liest das Manifest, lädt die remoteEntry.json-Dateien, verhandelt die Versionen,
// schreibt die Import Map — erst dann wird bootstrap.ts (und @angular/core) geladen
import { initFederation } from '@angular-architects/native-federation';

initFederation('federation.manifest.json')
  .then((nf) => import('./bootstrap').then((m) => m.bootstrap(nf)))
  .catch((err) => console.error(err));

// Die Kurzform aus älteren Tutorials gibt es in 22.x noch,
// sie ist aber als @deprecated markiert:
import { loadRemoteModule } from '@angular-architects/native-federation';

const route = {
  path: 'catalog',
  loadChildren: () =>
    loadRemoteModule('catalog', './routes').then((m) => m.CATALOG_ROUTES),
};

// Der Grund, laut d.ts: Sie hängt von einer globalen Instanz und vom LETZTEN initFederation ab,
// ist also in Tests und mit mehreren Hosts fragil.
// Empfohlen: loadRemoteModule aus dem Ergebnis von initFederation (siehe app.routes.ts).

Die Demo unten bildet genau diesen Ablauf nach. Die Server sind simuliert, aber jedes „Remote“ ist eine echte Angular-Komponente, liegt in einem eigenen Chunk und wird mit einem dynamischen import() geladen — derselbe Mechanismus, den loadRemoteModule darunter verwendet. Catalog und Cart sprechen nur über Events auf window miteinander; die Reviews sprechen mit niemandem.

Geteilte Abhängigkeiten und Versionen

Für jedes Paket in shared deklariert ein Remote vier Dinge: version (womit es gebaut wurde), requiredVersion (was es akzeptiert; 'auto' = der Bereich aus der package.json, zum Beispiel ^22.2.0), singleton (eine einzige Instanz für alle) und strictVersion (lehnt eine Version außerhalb des Bereichs ab).

Warum Angular ein Singleton sein muss. @angular/core ist keine Bibliothek aus reinen Funktionen: Es ist die Runtime, die rendert, der Injector, die Change Detection. Kompilierte Templates rufen die Runtime-Instruktionen des Builds auf, mit dem sie kompiliert wurden, daher kann eine Komponente aus einer Kopie nicht von einer anderen gerendert werden. Selbst bei einer gewöhnlichen Bibliothek bedeuten zwei Kopien zwei verschiedene Klassen: inject(AuthService) im Remote fragt ein anderes Token an als das, das die Shell registriert hat, und dein „Singleton“ hat plötzlich zwei Instanzen.

Was passiert, wenn die Versionen nicht zusammenpassen, hängt vom Tool ab:

Bei Angular rettet „eine eigene Kopie“ die Lage nicht: Das Remote hätte eine andere Runtime, seine Komponenten können also nicht in den Baum der Shell eintreten. Ein Remote mit einem anderen Major wird nur isoliert eingebunden — als Web Component mit eigenem Bootstrap oder in einem iframe. Wenn du es lieber beim Start als bei der Navigation herausfinden willst, hat der Orchestrator die Option strict.strictExternalCompatibility, die bei der Initialisierung einen Fehler wirft, statt Scopes anzulegen.

// Drei Wege, `shared` in federation.config.mjs zu schreiben

// 1. der Standard in 22.x: alles aus den dependencies der package.json, dieselben Regeln
shared: fromPackageJson({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),

// 2. der klassische Stil (wird weiterhin exportiert)
shared: { ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }) },

// 3. explizit, Paket für Paket
shared: share({
  '@angular/core': { singleton: true, strictVersion: true, requiredVersion: 'auto' },
  // hat Zustand → Singleton
  '@ngrx/signals': { singleton: true, strictVersion: true, requiredVersion: 'auto' },
  // zustandsloses Hilfspaket: jedes Remote darf seine eigene Kopie haben
  'date-fns': { singleton: false },
}),

// requiredVersion: 'auto' → der Bereich aus der package.json (z. B. "^22.2.0")
// autoShareScope({ level: 'minor' }) → teilt nur zwischen Remotes
//   auf derselben Versionslinie (z. B. "ng22.2")

{
  "imports": {
    "@angular/core": "https://shell.example/core-22.2.2.js"
  },
  "scopes": {
    "https://cart.example/": {
      "@angular/core": "https://cart.example/core-22.1.4.js"
    }
  }
}

• Ideal: dieselbe exakte Angular-Version in der Shell und in allen Remotes. ^ gibt dir Toleranz zwischen Minor-Versionen, aber AOT-kompilierter Code nutzt interne Runtime-Instruktionen — teste die Kombination, verlass dich nicht auf semver.
• Der Host gewinnt, daher kann die Shell bei einer neuen Minor-Version vorangehen, solange die Bereiche der Remotes sie akzeptieren. Ein neues Major erfordert ein synchronisiertes Upgrade oder die Isolation des Remotes, das zurückgefallen ist.
• Singleton + strictVersion für das Framework und für alles mit Zustand: Angular, Router, Stores, Design-System, die Auth-Bibliothek. Zustandslose Hilfspakete dürfen Nicht-Singletons bleiben.
• autoShareScope() bindet das Teilen an eine Versionslinie (zum Beispiel ng22.2), damit du nicht versehentlich inkompatible Builds mischst.

Module Federation, Web Components, iframes

Module Federation (webpack)

@angular-architects/module-federation hat eine Version für Angular 22, aber es ist die „klassische“ Variante auf webpack: ng add stellt das Projekt vom esbuild-Builder auf @angular-builders/custom-webpack um (ab Angular 22; bis 21 nutzte es ngx-build-plus) und warnt ausdrücklich, dass für neue Projekte die Alternative Native Federation ist. Es gibt außerdem einen rspack-Builder, der als experimentell markiert ist. Wähle es nur, wenn du ein bestehendes Module-Federation-System erweiterst oder die Runtime mit Remotes teilen musst, die bereits auf webpack gebaut sind.

// Klassisches Module Federation (webpack) — @angular-architects/module-federation 22.x
const {
  shareAll,
  withModuleFederationPlugin,
} = require('@angular-architects/module-federation/webpack');

module.exports = withModuleFederationPlugin({
  name: 'catalog',
  exposes: {
    './routes': './projects/catalog/src/app/catalog.routes.ts',
  },
  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
  },
});

Web Components

Jedes Remote startet mit createApplication() seine eigene Anwendung und definiert ein Tag; die Shell setzt es nur auf die Seite. Es funktioniert über verschiedene Angular-Majors und über Frameworks hinweg, weil nichts geteilt wird. Genau das ist sein Preis: Jedes Bundle bringt seine eigene Runtime mit (≈ 33 kB übertragen für ein einfaches Element, gemessen auf der Angular-Elements-Seite), es gibt kein gemeinsames DI, und die Kommunikation läuft über Attribute und Events. Es lässt sich gut mit Federation kombinieren: Ein Remote auf einem anderen Major wird als Web Component exponiert und trotzdem über loadRemoteModule geladen.

// Ein Remote auf einem ANDEREN Angular-Major (oder einem anderen Framework): isoliert eingebunden,
// als Web Component mit eigener Runtime.
//
// Remote — federation.config.mjs:  exposes: { './Bootstrap': './src/bootstrap.ts' }
// Remote — bootstrap.ts:
//   createApplication(appConfig).then(({ injector }) =>
//     customElements.define('mfe-legacy', createCustomElement(App, { injector })));
//
// Shell — eine Seite, die das Bundle lädt (sein Effekt: define) und dann das Tag verwendet
import { CUSTOM_ELEMENTS_SCHEMA, Component, inject, input, resource } from '@angular/core';
import { NATIVE_FEDERATION } from '../app.config';

@Component({
  selector: 'app-legacy-page',
  schemas: [CUSTOM_ELEMENTS_SCHEMA],
  template: `
    @if (bundle.hasValue()) {
      <mfe-legacy [attr.customer-id]="customerId()"></mfe-legacy>
    } @else if (bundle.error()) {
      <p role="alert">
        Das Legacy-Modul ist nicht verfügbar.
        <button (click)="bundle.reload()">Wiederholen</button>
      </p>
    }
  `,
})
export class LegacyPage {
  private readonly nf = inject(NATIVE_FEDERATION);
  readonly customerId = input.required<string>();

  protected readonly bundle = resource({
    loader: () => this.nf.loadRemoteModule('legacy', './Bootstrap'),
  });
}

iframes

Die stärkste Isolation: anderes Dokument, anderes JavaScript, anderes CSS; Fehler, Memory Leaks und Styles bleiben im Frame, und mit sandbox kannst du Code ausführen, dem du nicht vertraust. Du zahlst mit der Integration: Die Höhe wird über postMessage synchronisiert, ein Dialog kann den Frame nicht verlassen, Deep Links und Browser-Verlauf müssen von Hand verknüpft werden, Fokus und Barrierefreiheit werden kompliziert, und jeder Frame lädt die ganze Anwendung. Geeignet für Fremdcode, Legacy-Anwendungen, die du nicht ändern kannst, und interne Tools.

<!-- Die stärkste Isolation: anderes Dokument, anderes JS, anderes CSS;
     Fehler bleiben im Frame -->
<iframe
  src="https://billing.exemplu.ro/embed?customer=42"
  title="Abrechnung"
  sandbox="allow-scripts allow-same-origin allow-forms"
  loading="lazy"
  style="width: 100%; border: 0"
></iframe>

<!-- Der Preis: Die Höhe wird per postMessage übermittelt, ein Dialog kann den
     Frame nicht verlassen, Deep Links und Browser-Verlauf werden von Hand synchronisiert,
     und jeder Frame lädt die ganze Anwendung. -->

Verträge, Kommunikation, Fallback

Der Vertrag eines Remotes ist alles, was von außen von ihm abhängt: die Schlüssel in exposes, was sie exportieren, die Routenparameter, die sie lesen, die Events, die sie senden, und die geteilten Abhängigkeiten. Behandle ihn wie eine öffentliche API mit semver: Eine inkompatible Änderung bedeutet einen neuen Schlüssel (./routes-v2), und der alte bleibt, bis die Shell migriert ist.

Kommunikation, in der Reihenfolge, in der es sich lohnt, sie auszuprobieren:

1. Die URL — Routenparameter und Query-Parameter. Kostenlos, verlinkbar, übersteht einen Refresh, und das Remote importiert nichts aus einem anderen Remote.
2. Typisierte Events auf window, aus einem winzigen contracts-Paket (Typen + emit/listen). Vergiss nicht das Remote, das spät startet: Es muss den Zustand erfragen.
3. Ein paar kleine Services, als Singletons geteilt — Auth, aktueller Benutzer, Feature-Flags — aus einer Bibliothek, die in shared enthalten ist.

Was du vermeiden solltest: einen gemeinsamen globalen Store (derselbe NgRx-Store oder derselbe Service, der den gesamten Zustand hält und von jedem Remote verwendet wird). Jede Änderung an der Form des Zustands wird zu einer koordinierten Änderung zwischen Teams — genau die Kopplung, die du entfernen wolltest. Jedes Remote behält seinen eigenen Zustand; zwischen ihnen reisen nur Events und URLs (siehe auch State Management).

// 1. Die URL ist der erste Kanal: kostenlos, verlinkbar, übersteht einen Refresh.
//    /catalog/audio?sort=price → das Remote liest aus der URL, nicht aus einem gemeinsamen Store.
//    (withComponentInputBinding() gehört in die SHELL: die Routen des Remotes
//    laufen im Router der Shell)
export class ProductList {
  readonly category = input<string>();                 // aus :category
  readonly sort = input<'price' | 'rating'>('rating'); // aus ?sort=
}

// 2. Auch die Navigation zwischen Remotes läuft über die URL:
//    das Remote importiert nichts aus einem anderen Remote.
this.router.navigate(['/cart'], { queryParams: { added: product.id } });

Fallback. Jedes Remote kann fehlen: ein fehlgeschlagenes Deployment, ein CDN, das ausgefallen ist, ein Fehler im Manifest einer Umgebung. Zwei Situationen, zwei Lösungen:

• Eine ganze Route: Lass loadChildren scheitern und wandle den Fehler mit withNavigationErrorHandler in einen Redirect um. Ein abgelehnter Loader wird vom Router nicht gecacht, daher versucht die nächste Navigation das Remote erneut.
• Ein Remote innerhalb einer Seite (ein Widget, ein Slot): Eine Shell-Komponente lädt das Remote mit resource, mit Timeout, Fallback und reload() für „Wiederholen“ — wie in der ersten Demo.

// Eine FEHLGESCHLAGENE Remote-ROUTE: lass loadChildren scheitern und leite um.
// Ein abgelehnter Loader wird vom Router NICHT gecacht → die nächste Navigation versucht es erneut.
import { ApplicationConfig, inject } from '@angular/core';
import {
  NavigationError,
  RedirectCommand,
  Router,
  provideRouter,
  withNavigationErrorHandler,
} from '@angular/router';
import type { NativeFederationResult } from '@angular-architects/native-federation';
import { routes } from './app.routes';

export const appConfig = (nf: NativeFederationResult): ApplicationConfig => ({
  providers: [
    provideRouter(
      routes(nf),
      withNavigationErrorHandler((e: NavigationError) => {
        const router = inject(Router);
        const target = `/indisponibil?url=${encodeURIComponent(e.url)}`;
        return new RedirectCommand(router.parseUrl(target));
      }),
    ),
  ],
});

// ✗ Die Falle: Ein Fallback, den der Loader zurückgibt, ist für den Router ein ERFOLG.
//   Er wird an der Route gecacht, bis die Seite neu lädt, sodass „Wiederholen“
//   das Remote nie wieder erreicht:
//   loadComponent: () => nf.loadRemoteModule(...).then(...).catch(() => RemoteDown)

Wann ja, wann nein

Die Entscheidung hängt mehr von der Organisation ab als vom Code. Der Score unten wendet die Regeln dieser Seite an: Er ist keine Zauberformel, zwingt dich aber, die Fragen zu beantworten, auf die es ankommt, und zeigt dir, warum eine Empfehlung zustande kommt.

Häufige Stolperfallen

• Die „geteilte“ Bibliothek, die nicht in shared steht → jedes Remote bündelt sie separat, sodass providedIn: 'root' zwei Instanzen erzeugt (zwei Klassen, zwei Tokens). Nimm die Bibliotheken mit Zustand in shared auf und prüfe die remoteEntry.json.
• singleton: false bei @angular/core oder ein Remote auf einem anderen Major → zwei Angular-Runtimes. Überall dieselbe Version; für Ausnahmen Isolation (Web Component, iframe).
• strictVersion: false, damit es „durchgeht“ → die Meldung verschwindet aus der Konsole, das Problem bleibt und zeigt sich in Produktion. Repariere die Versionen, nicht das Flag.
• Ein Fallback, der aus loadComponent zurückgegeben wird (.catch(() => RemoteDown)) → der Router cacht ihn an der Route bis zu einem Refresh, und „Wiederholen“ erreicht das Remote nie. Lass den Loader scheitern oder nutze eine Host-Komponente mit reload().
• Kein Timeout → eine remoteEntry.json, die nicht antwortet, hält die Seite für immer im Zustand „loading“. Setze bei jedem Laden eines Remotes ein Timeout.
• Ein Manifest für alle Umgebungen → Staging lädt die Produktions-Remotes (oder umgekehrt). Ein Manifest pro Umgebung, beim Deployment erzeugt.
• Ein gemeinsamer globaler Store zwischen Remotes → Releases im Gleichschritt, ein verteilter Monolith. Lokaler Zustand + Events + URL.
• Ein Remote, das Code direkt aus einem anderen Remote importiert → eine versteckte Abhängigkeit zwischen Deployments. Alles läuft über libs/contracts oder über die URL.
• Absolute Routen, die in einem Remote geschrieben sind (/products/42) → sie brechen, wenn die Shell es unter einem anderen Präfix einhängt. Navigiere relativ zur aktiven Route.
• Globales CSS aus Remotes → die Styles eines Teams zerstören die eines anderen. Keine globalen Styles in Remotes; CSS-Tokens aus dem Design-System; ShadowDom für Web Components.
• Fehler ohne Kontext → du weißt nicht, welches Remote in welcher Version abgestürzt ist. Hänge Name und Version des Remotes an jeden gemeldeten Fehler (siehe Fehlerbehandlung).

Spickzettel

// REMOTE — federation.config.mjs
withNativeFederation({
  name: 'catalog',
  exposes: { './routes': './src/app/catalog.routes.ts' }, // öffentliche API, versioniert
  shared: fromPackageJson({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
});

// SHELL — public/federation.manifest.json (eine pro Umgebung: dev / staging / prod)
// { "catalog": "https://catalog.exemplu.ro/remoteEntry.json" }

// SHELL — main.ts
initFederation('federation.manifest.json')
  .then((nf) => import('./bootstrap').then((m) => m.bootstrap(nf)));

// SHELL — Routen
const catalog = {
  path: 'catalog',
  loadChildren: () =>
    nf.loadRemoteModule<{ CATALOG_ROUTES: Routes }>('catalog', './routes')
      .then((m) => m.CATALOG_ROUTES),
};

// VERSIONEN: überall dieselbe Angular-Version; der Host hat Vorrang.
//   inkompatibel + strictVersion    → eigene Kopie in scopes (NF)
//                                     "Unsatisfied version …" (webpack MF)
//   inkompatibel, ohne strictVersion → nutzt die geteilte Version + Warnung
// KOMMUNIKATION: URL → typisierte Events (libs/contracts) → kleine geteilte Services.
//   Keine gemeinsamen Stores.
// AUSFALL: Route → withNavigationErrorHandler + Redirect
//          Slot → Host-Komponente mit Timeout + resource.reload()
// ANDERER MAJOR / ANDERES FRAMEWORK → Web Component mit eigener Runtime oder iframe