~/sph.sh
March 23, 2025
react
tutorial
typescript

Micro-Frontend-Architektur-Grundlagen: Vom Monolithen zu verteilten Systemen

Vollständiger Leitfaden zu Micro-Frontend-Architekturen mit realen Implementierungsmustern, Debugging-Geschichten und Performance-Überlegungen für Engineering-Teams.

Während Frontend-Anwendungen in Komplexität und Teamgröße wachsen, beginnt der monolithische Ansatz, der uns in der Vergangenheit gut gedient hat, seine Grenzen zu zeigen. Teams treten sich gegenseitig auf die Füße, Deployment wird zu einem Koordinationsalptraum, und Technologieentscheidungen werden für Jahre eingefroren. Kommt Ihnen das bekannt vor?

Micro-Frontends bieten eine überzeugende Lösung für diese Probleme, aber sie sind kein Allheilmittel. Nachdem ich Micro-Frontend-Architekturen in großem Maßstab in mehreren Organisationen implementiert habe, habe ich gelernt, dass der Erfolg stark davon abhängt, die grundlegenden Muster und ihre Kompromisse zu verstehen.

Vollständige Micro-Frontend-Serie#

Dies ist Teil 1 einer umfassenden 3-teiligen Serie. Hier ist dein vollständiger Lernpfad:

Neu bei Micro-Frontends? Fang mit diesem Beitrag an, um die grundlegenden Konzepte zu verstehen, und folge dann der Serie in der Reihenfolge.

Bereit zur Implementierung? Spring zu Teil 2 für praktische Module Federation-Beispiele.

In der Produktion laufen? Geh direkt zu Teil 3 für erweiterte Debugging- und Optimierungstechniken.

Was sind Micro-Frontends?#

Micro-Frontends erweitern das Microservices-Konzept auf die Frontend-Entwicklung. Anstatt einer einzigen monolithischen Frontend-Anwendung komponierst du mehrere kleinere, unabhängig bereitstellbare Frontend-Anwendungen zu einer kohärenten Benutzererfahrung.

Die Schlüsselprinzipien sind:

  • Technologie-agnostisch: Teams können ihre eigenen Frameworks und Tools wählen
  • Unabhängige Bereitstellung: Jedes Micro-Frontend kann unabhängig bereitgestellt werden
  • Team-Autonomie: Verschiedene Teams können verschiedene Teile der Anwendung besitzen
  • Schrittweise Migration: Schrittweise Migration von Monolithen ist möglich

Typen von Micro-Frontend-Architekturen#

Basierend auf meiner Erfahrung bei der Implementierung verschiedener Ansätze sind hier die vier Haupt-Architekturmuster:

1. Server-Side Template Composition#

Der einfachste Ansatz, bei dem verschiedene Services HTML-Fragmente rendern, die auf dem Server zusammengesetzt werden.

TypeScript
// Gateway-Service, der mehrere Micro-Frontends zusammensetzt
import express from 'express';
import fetch from 'node-fetch';

const app = express();

app.get('/', async (req, res) => {
  try {
    // Fragmente von verschiedenen Services abrufen
    const [header, navigation, content, footer] = await Promise.all([
      fetch('http://header-service/fragment').then(r => r.text()),
      fetch('http://nav-service/fragment').then(r => r.text()),
      fetch('http://content-service/fragment').then(r => r.text()),
      fetch('http://footer-service/fragment').then(r => r.text())
    ]);

    const html = `
      <!DOCTYPE html>
      <html>
        <head>
          <title>Zusammengesetzte Anwendung</title>
        </head>
        <body>
          ${header}
          ${navigation}
          <main>${content}</main>
          ${footer}
        </body>
      </html>
    `;

    res.send(html);
  } catch (error) {
    res.status(500).send('Fehler beim Zusammensetzen der Seite');
  }
});

Vorteile: Einfach zu verstehen, gute SEO, funktioniert ohne JavaScript Nachteile: Begrenzte Interaktivität, Seitenneuladungen für Navigation, Herausforderungen mit geteiltem State

Wann verwenden: Inhaltslastige Websites, wenn SEO kritisch ist, Teams, die mit serverseitiger Entwicklung vertraut sind

2. Build-Time Integration#

Micro-Frontends werden als npm-Pakete veröffentlicht und zur Build-Zeit zusammengesetzt.

TypeScript
// Package.json der Shell-Anwendung
{
  "dependencies": {
    "@company/header-mf": "^1.2.0",
    "@company/product-catalog-mf": "^2.1.5",
    "@company/checkout-mf": "^1.8.2"
  }
}

// Shell-Anwendung
import React from 'react';
import { Header } from '@company/header-mf';
import { ProductCatalog } from '@company/product-catalog-mf';
import { Checkout } from '@company/checkout-mf';

const App: React.FC = () => {
  return (
    <div>
      <Header />
      <main>
        <ProductCatalog />
        <Checkout />
      </main>
    </div>
  );
};

export default App;
TypeScript
// Micro-Frontend-Paket (header-mf)
import React from 'react';

export interface HeaderProps {
  user?: {
    name: string;
    avatar: string;
  };
  onLogout?: () => void;
}

export const Header: React.FC<HeaderProps> = ({ user, onLogout }) => {
  return (
    <header className="bg-blue-600 text-white p-4">
      <div className="flex justify-between items-center">
        <h1>Meine App</h1>
        {user && (
          <div className="flex items-center gap-2">
            <img src={user.avatar} alt={user.name} className="w-8 h-8 rounded-full" />
            <span>{user.name}</span>
            <button onClick={onLogout}>Abmelden</button>
          </div>
        )}
      </div>
    </header>
  );
};

Vorteile: Typsicherheit, Optimierung geteilter Abhängigkeiten, vertraute Entwicklungserfahrung Nachteile: Koordinierte Bereitstellungen, Komplexität des Versionsmanagements, nicht wirklich unabhängig

Wann verwenden: Wenn du Micro-Frontend-Vorteile willst, aber koordinierte Bereitstellungen tolerieren kannst

3. Runtime Integration via JavaScript#

Der flexibelste Ansatz, bei dem Micro-Frontends zur Laufzeit geladen und integriert werden.

TypeScript
// Micro-Frontend-Registry
interface MicroFrontendConfig {
  name: string;
  url: string;
  scope: string;
  module: string;
}

class MicroFrontendRegistry {
  private configs: Map<string, MicroFrontendConfig> = new Map();
  private loadedModules: Map<string, any> = new Map();

  register(config: MicroFrontendConfig) {
    this.configs.set(config.name, config);
  }

  async load(name: string): Promise<any> {
    if (this.loadedModules.has(name)) {
      return this.loadedModules.get(name);
    }

    const config = this.configs.get(name);
    if (!config) {
      throw new Error(`Micro-Frontend ${name} nicht registriert`);
    }

    // Dynamischer Import mit Fehlerbehandlung
    try {
      await this.loadScript(config.url);
      const container = (window as any)[config.scope];

      if (!container) {
        throw new Error(`Container ${config.scope} nicht gefunden`);
      }

      await container.init({
        react: () => Promise.resolve(React),
        'react-dom': () => Promise.resolve(ReactDOM),
      });

      const factory = await container.get(config.module);
      const Module = factory();

      this.loadedModules.set(name, Module);
      return Module;
    } catch (error) {
      console.error(`Fehler beim Laden von Micro-Frontend ${name}:`, error);
      throw error;
    }
  }

  private loadScript(url: string): Promise<void> {
    return new Promise((resolve, reject) => {
      const script = document.createElement('script');
      script.src = url;
      script.onload = () => resolve();
      script.onerror = () => reject(new Error(`Fehler beim Laden des Skripts: ${url}`));
      document.head.appendChild(script);
    });
  }
}

// Verwendung in der Shell-Anwendung
const registry = new MicroFrontendRegistry();

registry.register({
  name: 'product-catalog',
  url: 'http://localhost:3001/remoteEntry.js',
  scope: 'productCatalog',
  module: './ProductCatalog'
});

const DynamicMicroFrontend: React.FC<{ name: string }> = ({ name }) => {
  const [Component, setComponent] = useState<React.ComponentType | null>(null);
  const [error, setError] = useState<string | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    registry.load(name)
      .then(Module => {
        setComponent(() => Module.default || Module);
        setError(null);
      })
      .catch(err => {
        setError(err.message);
        setComponent(null);
      })
      .finally(() => setLoading(false));
  }, [name]);

  if (loading) return <div>{name} wird geladen...</div>;
  if (error) return <div>Fehler beim Laden von {name}: {error}</div>;
  if (!Component) return <div>Komponente {name} nicht gefunden</div>;

  return <Component />;
};

Vorteile: Echte Unabhängigkeit, verschiedene Technologie-Stacks möglich, Laufzeit-Flexibilität Nachteile: Komplexität, Laufzeitfehler, Performance-Overhead, Debugging-Herausforderungen

Wann verwenden: Große Organisationen mit mehreren Teams, Bedarf an Technologie-Vielfalt

4. Iframe-basierte Integration#

Der am stärksten isolierte Ansatz mit iframes für vollständige Trennung.

TypeScript
// Iframe-Micro-Frontend-Wrapper mit postMessage-Kommunikation
interface IframeMicroFrontendProps {
  src: string;
  name: string;
  onMessage?: (data: any) => void;
}

const IframeMicroFrontend: React.FC<IframeMicroFrontendProps> = ({
  src,
  name,
  onMessage
}) => {
  const iframeRef = useRef<HTMLIFrameElement>(null);
  const [isLoaded, setIsLoaded] = useState(false);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    const handleMessage = (event: MessageEvent) => {
      // Origin für Sicherheit verifizieren
      if (event.origin !== new URL(src).origin) {
        return;
      }

      if (event.data.source === name) {
        onMessage?.(event.data.payload);
      }
    };

    window.addEventListener('message', handleMessage);
    return () => window.removeEventListener('message', handleMessage);
  }, [src, name, onMessage]);

  const sendMessage = (data: any) => {
    if (iframeRef.current?.contentWindow) {
      iframeRef.current.contentWindow.postMessage({
        source: 'shell',
        target: name,
        payload: data
      }, new URL(src).origin);
    }
  };

  return (
    <div className="micro-frontend-container">
      {!isLoaded && <div>{name} wird geladen...</div>}
      {error && <div>Fehler: {error}</div>}
      <iframe
        ref={iframeRef}
        src={src}
        onLoad={() => setIsLoaded(true)}
        onError={() => setError(`Fehler beim Laden von ${name}`)}
        style={{
          width: '100%',
          border: 'none',
          minHeight: '400px'
        }}
        title={name}
        sandbox="allow-scripts allow-same-origin allow-forms"
      />
    </div>
  );
};

// Im Micro-Frontend (iframe-Inhalt)
const MicroFrontendApp: React.FC = () => {
  const [data, setData] = useState<any>(null);

  useEffect(() => {
    const handleMessage = (event: MessageEvent) => {
      if (event.data.target === 'product-catalog') {
        setData(event.data.payload);
      }
    };

    window.addEventListener('message', handleMessage);
    return () => window.removeEventListener('message', handleMessage);
  }, []);

  const sendDataToShell = (payload: any) => {
    window.parent.postMessage({
      source: 'product-catalog',
      payload
    }, '*');
  };

  return (
    <div>
      <h2>Produktkatalog Micro-Frontend</h2>
      {/* Dein Micro-Frontend-Inhalt */}
    </div>
  );
};

Vorteile: Vollständige Isolation, Sicherheit, verschiedene Domains möglich, CSS-Isolation Nachteile: Begrenzte Kommunikation, SEO-Herausforderungen, Performance-Overhead, UX-Überlegungen

Wann verwenden: Sicherheit ist vorrangig, Legacy-Integration, Drittanbieter-Inhalte

Eine echte Debugging-Geschichte: Der Fall der verschwindenden Stile#

Lass mich eine Debugging-Geschichte teilen, die häufige Micro-Frontend-Fallstricke veranschaulicht. Wir hatten ein Runtime-Integrationssystem ähnlich dem oben beschriebenen implementiert, und alles funktionierte perfekt in der Entwicklung. In der Produktion begannen wir jedoch Berichte über fehlende Stile in unserem Produktkatalog-Micro-Frontend zu erhalten.

Die Symptome waren verwirrend:

  • Stile funktionierten gut, wenn das Micro-Frontend eigenständig lief
  • Das Problem trat nur in der Produktion auf, nicht in der Entwicklung
  • Es war intermittierend - manchmal luden Stile, manchmal nicht

Nach stundenlanger Untersuchung entdeckten wir die Grundursache: CSS-Lade-Race-Conditions.

TypeScript
// Der problematische Code
const ProductCatalogMF: React.FC = () => {
  useEffect(() => {
    // Dies lud CSS nach dem Komponenten-Mount
    import('./styles.css');
  }, []);

  return <div className="product-grid">...</div>;
};

Das Problem war, dass in der Produktion mit aggressiverer Minifizierung und CDN-Caching der CSS-Import nach dem Rendern der Komponente abgeschlossen wurde. Die Lösung erforderte eine robustere Ladestrategie:

TypeScript
// Korrigierte Version mit ordnungsgemäßem CSS-Laden
const MicroFrontendLoader = {
  async loadWithStyles(name: string, cssUrls: string[] = []) {
    // CSS zuerst laden
    await Promise.all(
      cssUrls.map(url => this.loadStylesheet(url))
    );

    // Dann die Komponente laden
    return await registry.load(name);
  },

  loadStylesheet(url: string): Promise<void> {
    return new Promise((resolve, reject) => {
      // Prüfen, ob bereits geladen
      if (document.querySelector(`link[href="${url}"]`)) {
        resolve();
        return;
      }

      const link = document.createElement('link');
      link.rel = 'stylesheet';
      link.href = url;
      link.onload = () => resolve();
      link.onerror = () => reject(new Error(`Fehler beim Laden von CSS: ${url}`));
      document.head.appendChild(link);
    });
  }
};

Diese Erfahrung lehrte uns die Wichtigkeit von:

  1. Ordnungsgemäße Ladesequenzen in Micro-Frontend-Architekturen
  2. Umgebungsparität - Produktionsprobleme manifestieren sich oft nicht in der Entwicklung
  3. Überwachung und Beobachtbarkeit - wir fügten CSS-Lade-Tracking hinzu, um diese Probleme früh zu erkennen

Performance-Überlegungen#

Micro-Frontends bringen einzigartige Performance-Herausforderungen mit sich:

Bundle-Größe und Duplikation#

Mehrere Micro-Frontends liefern oft dieselben Abhängigkeiten aus, was zu aufgeblähten Bundles führt.

TypeScript
// Webpack-Konfiguration für geteilte Abhängigkeiten
const ModuleFederationPlugin = require('@module-federation/webpack');

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'shell',
      remotes: {
        productCatalog: 'productCatalog@http://localhost:3001/remoteEntry.js',
      },
      shared: {
        react: {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
        // Gemeinsame Utilities teilen
        lodash: {
          singleton: false, // Mehrere Versionen erlauben, falls nötig
        }
      },
    }),
  ],
};

Lade-Performance#

Implementiere progressive Ladestrategien:

TypeScript
// Progressives Micro-Frontend-Laden
const ProgressiveMicroFrontend: React.FC<{
  name: string;
  priority: 'high' | 'medium' | 'low';
}> = ({ name, priority }) => {
  const [shouldLoad, setShouldLoad] = useState(priority === 'high');
  const isVisible = useIntersectionObserver();

  useEffect(() => {
    if (priority === 'medium' && isVisible) {
      setShouldLoad(true);
    } else if (priority === 'low') {
      // Nach Bereitschaft des Hauptinhalts laden
      const timer = setTimeout(() => setShouldLoad(true), 2000);
      return () => clearTimeout(timer);
    }
  }, [isVisible, priority]);

  if (!shouldLoad) {
    return <div>{name} wird geladen...</div>;
  }

  return <DynamicMicroFrontend name={name} />;
};

Die richtige Architektur wählen#

Die Wahl hängt von deinen spezifischen Einschränkungen ab:

FaktorServer-SideBuild-TimeRuntimeIframe
Team-UnabhängigkeitNiedrigMittelHochHoch
Technologie-VielfaltMittelNiedrigHochHoch
PerformanceHochHochMittelNiedrig
KomplexitätNiedrigMittelHochMittel
SEOExzellentGutSchlechtSchlecht
EntwicklungserfahrungGutExzellentMittelSchlecht

Was kommt als Nächstes?#

Nachdem du nun die grundlegenden Micro-Frontend-Muster verstehst, bist du bereit, tiefer in die praktische Implementierung einzutauchen.

Mach weiter mit Teil 2: Module Federation und Implementierungsmuster, wo wir behandeln werden:

  • Produktionsbereite Module Federation-Konfigurationen
  • Robuste Fehlerbehandlung und Fallback-Strategien
  • Cross-Micro-Frontend-Kommunikationsmuster
  • Routing-Koordination zwischen Anwendungen
  • Entwicklungsworkflows und Tooling
  • Echte Debugging-Geschichten aus Produktionssystemen

Wichtige Erkenntnis: Micro-Frontends sind nicht nur ein technisches Muster - sie sind ein organisatorisches Muster, das sorgfältige Überlegungen zu deiner Teamstruktur, Geschäftsanforderungen und technischen Einschränkungen erfordert.

Die hier behandelten grundlegenden Muster werden deine architektonischen Entscheidungen leiten, aber die echte Komplexität entsteht in der Integrationsschicht, die wir im nächsten Beitrag angehen werden.

Seriennavigation

  • Teil 1 (Aktuell): Architektur-Grundlagen
  • Teil 2: Implementierungsmuster
  • Teil 3: Erweiterte Muster & Debugging
Loading...

Kommentare (0)

An der Unterhaltung teilnehmen

Melde dich an, um deine Gedanken zu teilen und mit der Community zu interagieren

Noch keine Kommentare

Sei der erste, der deine Gedanken zu diesem Beitrag teilt!

Related Posts