JavaScript Module Federation: Die Leistungsfähigkeit des Runtime Sharings für globale Anwendungen freisetzen

In der heutigen, sich schnell entwickelnden digitalen Landschaft ist der Aufbau skalierbarer, wartbarer und kollaborativer Webanwendungen von größter Bedeutung. Da Entwicklungsteams wachsen und Anwendungen komplexer werden, wird der Bedarf an effizienter Code-Teilung und Entkopplung immer wichtiger. JavaScript Module Federation, ein bahnbrechendes Feature, das mit Webpack 5 eingeführt wurde, bietet eine leistungsstarke Lösung, indem es das Teilen von Code zur Laufzeit zwischen unabhängig voneinander bereitgestellten Anwendungen ermöglicht. Dieser Blogbeitrag befasst sich mit den Kernkonzepten der Module Federation, konzentriert sich auf ihre Runtime-Sharing-Fähigkeiten und untersucht, wie sie die Art und Weise revolutionieren kann, wie globale Teams ihre Webanwendungen erstellen und verwalten.

Die sich wandelnde Landschaft der Webentwicklung und die Notwendigkeit des Teilens

In der Vergangenheit umfasste die Webentwicklung oft monolithische Anwendungen, bei denen sich der gesamte Code in einer einzigen Codebasis befand. Obwohl dieser Ansatz für kleinere Projekte geeignet sein kann, wird er bei der Skalierung von Anwendungen schnell unhandlich. Abhängigkeiten verflechten sich, die Build-Zeiten erhöhen sich, und die Bereitstellung von Updates kann ein komplexes und riskantes Unterfangen sein. Der Aufstieg von Microservices in der Backend-Entwicklung ebnete den Weg für ähnliche Architekturmuster im Frontend, was zur Entstehung von Microfrontends führte.

Microfrontends zielen darauf ab, große, komplexe Frontend-Anwendungen in kleinere, unabhängige und bereitstellbare Einheiten zu zerlegen. Dies ermöglicht es verschiedenen Teams, autonom an verschiedenen Teilen der Anwendung zu arbeiten, was zu schnelleren Entwicklungszyklen und einer verbesserten Teamautonomie führt. Eine wesentliche Herausforderung bei Microfrontend-Architekturen war jedoch schon immer das effiziente Teilen von Code. Die Duplizierung gemeinsamer Bibliotheken, UI-Komponenten oder Hilfsfunktionen über mehrere Microfrontends hinweg führt zu:

• Erhöhte Bundle-Größen: Jede Anwendung enthält ihre eigene Kopie gemeinsamer Abhängigkeiten, was die gesamte Downloadgröße für Benutzer aufbläht.
• Inkonsistente Abhängigkeiten: Verschiedene Microfrontends könnten unterschiedliche Versionen derselben Bibliothek verwenden, was zu Kompatibilitätsproblemen und unvorhersehbarem Verhalten führt.
• Wartungsaufwand: Die Aktualisierung von gemeinsam genutztem Code erfordert Änderungen in mehreren Anwendungen, was das Fehlerrisiko erhöht und die Bereitstellung verlangsamt.
• Verschwendete Ressourcen: Das mehrfache Herunterladen desselben Codes ist sowohl für den Client als auch für den Server ineffizient.

Module Federation geht diese Herausforderungen direkt an, indem sie einen Mechanismus für das echte Teilen von Code zur Laufzeit einführt.

Was ist JavaScript Module Federation?

JavaScript Module Federation, hauptsächlich durch Webpack 5 implementiert, ist ein Build-Tool-Feature, das es JavaScript-Anwendungen ermöglicht, zur Laufzeit dynamisch Code aus anderen Anwendungen zu laden. Es ermöglicht die Erstellung mehrerer unabhängiger Anwendungen, die Code und Abhängigkeiten teilen können, ohne dass ein Monorepo oder ein komplexer Integrationsprozess zur Build-Zeit erforderlich ist.

Die Kernidee besteht darin, „Remotes“ (Anwendungen, die Module bereitstellen) und „Hosts“ (Anwendungen, die Module von Remotes konsumieren) zu definieren. Diese Remotes und Hosts können unabhängig voneinander bereitgestellt werden, was eine erhebliche Flexibilität bei der Verwaltung komplexer Anwendungen bietet und vielfältige Architekturmuster ermöglicht.

Runtime Sharing verstehen: Der Kern von Module Federation

Runtime Sharing ist der Grundpfeiler der Leistungsfähigkeit von Module Federation. Im Gegensatz zu herkömmlichen Code-Splitting- oder Shared-Dependency-Management-Techniken, die oft zur Build-Zeit stattfinden, ermöglicht Module Federation Anwendungen, Module direkt im Browser des Benutzers von anderen Anwendungen zu entdecken und zu laden. Das bedeutet, dass eine gemeinsame Bibliothek, eine geteilte UI-Komponentenbibliothek oder sogar ein Feature-Modul einmal von einer Anwendung geladen und dann anderen Anwendungen, die es benötigen, zur Verfügung gestellt werden kann.

Lassen Sie uns aufschlüsseln, wie das funktioniert:

Schlüsselkonzepte:

• Exposes: Eine Anwendung kann bestimmte Module (z. B. eine React-Komponente, eine Hilfsfunktion) „exposen“ (bereitstellen), die andere Anwendungen konsumieren können. Diese bereitgestellten Module werden in einem Container gebündelt, der remote geladen werden kann.
• Remotes: Eine Anwendung, die Module bereitstellt, wird als „Remote“ betrachtet. Sie stellt ihre Module über eine gemeinsame Konfiguration zur Verfügung.
• Consumes: Eine Anwendung, die Module von einem Remote verwenden muss, ist ein „Consumer“ oder „Host“. Sie konfiguriert sich selbst so, dass sie weiß, wo sie die Remote-Anwendungen findet und welche Module sie laden muss.
• Shared Modules: Module Federation ermöglicht die Definition von gemeinsam genutzten Modulen. Wenn mehrere Anwendungen dasselbe gemeinsam genutzte Modul konsumieren, wird nur eine Instanz dieses Moduls geladen und zwischen ihnen geteilt. Dies ist ein entscheidender Aspekt zur Optimierung der Bundle-Größen und zur Vermeidung von Abhängigkeitskonflikten.

Der Mechanismus:

Wenn eine Host-Anwendung ein Modul von einem Remote benötigt, fordert sie es vom Container des Remotes an. Der Remote-Container lädt dann dynamisch das angeforderte Modul. Wenn das Modul bereits von einer anderen konsumierenden Anwendung geladen wurde, wird es geteilt. Dieses dynamische Laden und Teilen geschieht nahtlos zur Laufzeit und bietet eine hocheffiziente Möglichkeit, Abhängigkeiten zu verwalten.

Vorteile von Module Federation für die globale Entwicklung

Die Vorteile der Einführung von Module Federation für den Aufbau globaler Anwendungen sind erheblich und weitreichend:

1. Verbesserte Skalierbarkeit und Wartbarkeit:

Durch die Aufteilung einer großen Anwendung in kleinere, unabhängige Microfrontends fördert Module Federation von Natur aus die Skalierbarkeit. Teams können an einzelnen Microfrontends arbeiten, ohne andere zu beeinträchtigen, was parallele Entwicklung und unabhängige Bereitstellungen ermöglicht. Dies reduziert die kognitive Belastung bei der Verwaltung einer massiven Codebasis und macht die Anwendung im Laufe der Zeit wartbarer.

2. Optimierte Bundle-Größen und Leistung:

Der bedeutendste Vorteil des Runtime Sharings ist die Reduzierung der gesamten Downloadgröße. Anstatt dass jede Anwendung gängige Bibliotheken (wie React, Lodash oder eine benutzerdefinierte UI-Komponentenbibliothek) dupliziert, werden diese Abhängigkeiten einmal geladen und geteilt. Dies führt zu:

• Schnellere anfängliche Ladezeiten: Benutzer laden weniger Code herunter, was zu einem schnelleren anfänglichen Rendern der Anwendung führt.
• Verbesserte nachfolgende Navigation: Beim Navigieren zwischen Microfrontends, die Abhängigkeiten teilen, werden die bereits geladenen Module wiederverwendet, was zu einer reaktionsschnelleren Benutzererfahrung führt.
• Reduzierte Serverlast: Es werden weniger Daten vom Server übertragen, was potenziell die Hosting-Kosten senkt.

Stellen Sie sich eine globale E-Commerce-Plattform mit verschiedenen Bereichen für Produktlisten, Benutzerkonten und den Checkout vor. Wenn jeder Bereich ein separates Microfrontend ist, aber alle auf eine gemeinsame UI-Komponentenbibliothek für Schaltflächen, Formulare und Navigation angewiesen sind, stellt Module Federation sicher, dass diese Bibliothek nur einmal geladen wird, unabhängig davon, welchen Bereich der Benutzer zuerst besucht.

3. Gesteigerte Teamautonomie und Zusammenarbeit:

Module Federation ermöglicht es verschiedenen Teams, die sich potenziell in verschiedenen globalen Regionen befinden, unabhängig an ihren jeweiligen Microfrontends zu arbeiten. Sie können ihre eigenen Technologiestacks (in vernünftigem Rahmen, um ein gewisses Maß an Konsistenz zu wahren) und Bereitstellungspläne wählen. Diese Autonomie fördert schnellere Innovation und reduziert den Kommunikationsaufwand. Die Möglichkeit, gemeinsamen Code zu teilen, fördert jedoch auch die Zusammenarbeit, da Teams zu gemeinsamen Bibliotheken und Komponenten beitragen und davon profitieren können.

Stellen Sie sich ein globales Finanzinstitut mit separaten Teams in Europa, Asien und Nordamerika vor, die für verschiedene Produktangebote verantwortlich sind. Module Federation ermöglicht es jedem Team, seine spezifischen Funktionen zu entwickeln, während es einen gemeinsamen Authentifizierungsdienst oder eine geteilte Diagrammbibliothek nutzt, die von einem zentralen Team entwickelt wurde. Dies fördert die Wiederverwendbarkeit und stellt die Konsistenz über verschiedene Produktlinien hinweg sicher.

4. Technologie-Agnostizismus (mit Vorbehalten):

Obwohl Module Federation auf Webpack aufbaut, ermöglicht es ein gewisses Maß an Technologie-Agnostizismus zwischen verschiedenen Microfrontends. Ein Microfrontend könnte mit React erstellt werden, ein anderes mit Vue.js und ein weiteres mit Angular, solange sie sich darauf einigen, wie Module bereitgestellt und konsumiert werden. Für das echte Runtime Sharing komplexer Frameworks wie React oder Vue muss jedoch besonders darauf geachtet werden, wie diese Frameworks initialisiert und geteilt werden, um zu vermeiden, dass mehrere Instanzen geladen werden und Konflikte verursachen.

Ein globales SaaS-Unternehmen könnte eine Kernplattform haben, die mit einem Framework entwickelt wurde, und dann spezialisierte Funktionsmodule ausgliedern, die von verschiedenen regionalen Teams mit anderen Frameworks entwickelt werden. Module Federation kann die Integration dieser unterschiedlichen Teile erleichtern, vorausgesetzt, die gemeinsam genutzten Abhängigkeiten werden sorgfältig verwaltet.

5. Einfachere Versionsverwaltung:

Wenn eine gemeinsam genutzte Abhängigkeit aktualisiert werden muss, muss nur der Remote, der sie bereitstellt, aktualisiert und erneut bereitgestellt werden. Alle konsumierenden Anwendungen übernehmen automatisch die neue Version bei ihrem nächsten Ladevorgang. Dies vereinfacht den Prozess der Verwaltung und Aktualisierung von gemeinsam genutztem Code in der gesamten Anwendungslandschaft.

Implementierung von Module Federation: Praktische Beispiele und Strategien

Schauen wir uns an, wie man Module Federation in der Praxis einrichtet und nutzt. Wir werden vereinfachte Webpack-Konfigurationen verwenden, um die Kernkonzepte zu veranschaulichen.

Szenario: Teilen einer UI-Komponentenbibliothek

Angenommen, wir haben zwei Anwendungen: einen „Produktkatalog“ (Remote) und ein „Benutzer-Dashboard“ (Host). Beide müssen eine gemeinsame „Button“-Komponente aus einer dedizierten „Shared UI“-Bibliothek verwenden.

1. Die „Shared UI“-Bibliothek (Remote):

Diese Anwendung wird ihre „Button“-Komponente bereitstellen.

            
const { ModuleFederationPlugin } = require('webpack');
const path = require('path');

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'remoteEntry.js',
    path: path.resolve(__dirname, 'dist'),
    publicPath: 'http://localhost:3001/dist/', // URL, unter der der Remote bereitgestellt wird
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'sharedUI',
      filename: 'remoteEntry.js',
      exposes: {
        './Button': './src/components/Button.js', // Button-Komponente bereitstellen
      },
      shared: {
        // Gemeinsame Abhängigkeiten definieren
        react: {
          singleton: true, // Sicherstellen, dass nur eine Instanz von React geladen wird
        },
        'react-dom': {
          singleton: true,
        },
      },
    }),
  ],
  // ... andere Webpack-Konfigurationen (Babel, DevServer usw.)
};

            

              
                Copy
              
            
          

src/components/Button.js:

            
import React from 'react';

const Button = ({ onClick, children }) => (
  
    {children}
  
);

export default Button;

            

              
                Copy
              
            
          

In diesem Setup stellt „Shared UI“ seine Button-Komponente bereit und deklariert react und react-dom als gemeinsam genutzte Abhängigkeiten mit singleton: true, um sicherzustellen, dass sie als einzelne Instanzen über alle konsumierenden Anwendungen hinweg behandelt werden.

2. Die „Produktkatalog“-Anwendung (Remote):

Diese Anwendung muss ebenfalls die gemeinsame Button-Komponente konsumieren und ihre eigenen Abhängigkeiten teilen.

            
const { ModuleFederationPlugin } = require('webpack');
const path = require('path');

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'remoteEntry.js',
    path: path.resolve(__dirname, 'dist'),
    publicPath: 'http://localhost:3002/dist/', // URL, unter der dieser Remote bereitgestellt wird
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'productCatalog',
      filename: 'remoteEntry.js',
      exposes: {
        './ProductList': './src/components/ProductList.js', // ProductList bereitstellen
      },
      remotes: {
        // Einen Remote definieren, von dem konsumiert werden soll
        sharedUI: 'sharedUI@http://localhost:3001/dist/remoteEntry.js',
      },
      shared: {
        // Geteilte Abhängigkeiten mit derselben Version und singleton: true
        react: {
          singleton: true,
        },
        'react-dom': {
          singleton: true,
        },
      },
    }),
  ],
  // ... andere Webpack-Konfigurationen
};

            

              
                Copy
              
            
          

Der „Produktkatalog“ stellt nun seine ProductList-Komponente bereit und deklariert seine eigenen Remotes, die speziell auf die „Shared UI“-Anwendung verweisen. Er deklariert auch dieselben gemeinsam genutzten Abhängigkeiten.

3. Die „Benutzer-Dashboard“-Anwendung (Host):

Diese Anwendung wird die Button-Komponente von „Shared UI“ und die ProductList vom „Produktkatalog“ konsumieren.

            
const { ModuleFederationPlugin } = require('webpack');
const path = require('path');

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist'),
    publicPath: 'http://localhost:3000/dist/', // URL, unter der die Bundles dieser App bereitgestellt werden
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'userDashboard',
      remotes: {
        // Die Remotes definieren, die diese Host-Anwendung benötigt
        sharedUI: 'sharedUI@http://localhost:3001/dist/remoteEntry.js',
        productCatalog: 'productCatalog@http://localhost:3002/dist/remoteEntry.js',
      },
      shared: {
        // Geteilte Abhängigkeiten, die mit den Remotes übereinstimmen müssen
        react: {
          singleton: true,
          import: 'react', // Den Modulnamen für den Import angeben
        },
        'react-dom': {
          singleton: true,
          import: 'react-dom',
        },
      },
    }),
  ],
  // ... andere Webpack-Konfigurationen
};

            

              
                Copy
              
            
          

src/index.js für „Benutzer-Dashboard“:

            
import React, { Suspense } from 'react';
import ReactDOM from 'react-dom';

// Die geteilte Button-Komponente dynamisch importieren
const RemoteButton = React.lazy(() => import('sharedUI/Button'));

// Die ProductList-Komponente dynamisch importieren
const RemoteProductList = React.lazy(() => import('productCatalog/ProductList'));

const App = () => {
  const handleClick = () => {
    alert('Button aus Shared UI geklickt!');
  };

  return (
    

      
Benutzer-Dashboard
      Lade Button...
}>
        Klick mich
      

      
Produkte
      Lade Produkte...