Module Federation JavaScript : Libérer la Puissance du Partage d'Exécution pour les Applications Globales

Dans le paysage numérique actuel en évolution rapide, la création d'applications web évolutives, maintenables et collaboratives est primordiale. À mesure que les équipes de développement s'agrandissent et que les applications deviennent plus complexes, le besoin d'un partage de code et d'un découplage efficaces devient de plus en plus critique. JavaScript Module Federation, une fonctionnalité révolutionnaire introduite avec Webpack 5, offre une solution puissante en permettant le partage de code à l'exécution entre des applications déployées indépendamment. Cet article de blog explore les concepts fondamentaux de Module Federation, en se concentrant sur ses capacités de partage d'exécution, et examine comment il peut révolutionner la manière dont les équipes mondiales construisent et gèrent leurs applications web.

L'Évolution du Développement Web et le Besoin de Partage

Historiquement, le développement web impliquait souvent des applications monolithiques où tout le code résidait dans une seule base de code. Bien que cette approche puisse convenir aux petits projets, elle devient rapidement ingérable à mesure que les applications évoluent. Les dépendances s'entremêlent, les temps de construction augmentent, et le déploiement des mises à jour peut être une entreprise complexe et risquée. L'essor des microservices dans le développement backend a ouvert la voie à des patrons architecturaux similaires sur le frontend, menant à l'émergence des microfrontends.

Les microfrontends visent à décomposer les grandes applications frontend complexes en unités plus petites, indépendantes et déployables. Cela permet à différentes équipes de travailler sur différentes parties de l'application de manière autonome, conduisant à des cycles de développement plus rapides et à une meilleure autonomie des équipes. Cependant, un défi majeur dans les architectures de microfrontends a toujours été le partage efficace du code. La duplication de bibliothèques communes, de composants d'interface utilisateur ou de fonctions utilitaires à travers plusieurs microfrontends entraîne :

• Augmentation de la Taille des Bundles : Chaque application transporte sa propre copie des dépendances partagées, ce qui alourdit la taille globale du téléchargement pour les utilisateurs.
• Dépendances Incohérentes : Différents microfrontends pourraient finir par utiliser différentes versions de la même bibliothèque, entraînant des problèmes de compatibilité et un comportement imprévisible.
• Surcharge de Maintenance : La mise à jour du code partagé nécessite des modifications dans plusieurs applications, ce qui augmente le risque d'erreurs et ralentit le déploiement.
• Gaspillage de Ressources : Le téléchargement multiple du même code est inefficace tant pour le client que pour le serveur.

Module Federation répond directement à ces défis en introduisant un mécanisme pour partager véritablement le code à l'exécution.

Qu'est-ce que JavaScript Module Federation ?

JavaScript Module Federation, principalement implémenté via Webpack 5, est une fonctionnalité d'outil de build qui permet aux applications JavaScript de charger dynamiquement du code depuis d'autres applications à l'exécution. Il permet la création de multiples applications indépendantes qui peuvent partager du code et des dépendances sans nécessiter un monorepo ou un processus complexe d'intégration au moment de la construction.

L'idée principale est de définir des "distants" (applications qui exposent des modules) et des "hôtes" (applications qui consomment des modules de distants). Ces distants et hôtes peuvent être déployés indépendamment, offrant une flexibilité significative dans la gestion d'applications complexes et permettant divers patrons architecturaux.

Comprendre le Partage d'Exécution : le Cœur de Module Federation

Le partage d'exécution est la pierre angulaire de la puissance de Module Federation. Contrairement aux techniques traditionnelles de division de code (code-splitting) ou de gestion des dépendances partagées qui se produisent souvent au moment de la construction, Module Federation permet aux applications de découvrir et de charger des modules d'autres applications directement dans le navigateur de l'utilisateur. Cela signifie qu'une bibliothèque commune, une bibliothèque de composants d'interface utilisateur partagée, ou même un module de fonctionnalité peut être chargé une seule fois par une application, puis mis à la disposition d'autres applications qui en ont besoin.

Voyons comment cela fonctionne :

Concepts Clés :

• Exposes : Une application peut 'exposer' certains modules (par exemple, un composant React, une fonction utilitaire) que d'autres applications peuvent consommer. Ces modules exposés sont regroupés dans un conteneur qui peut être chargé à distance.
• Remotes : Une application qui expose des modules est considérée comme un 'distant' (remote). Elle expose ses modules via une configuration partagée.
• Consumes : Une application qui a besoin d'utiliser des modules d'un distant est un 'consommateur' ou 'hôte' (host). Elle se configure pour savoir où trouver les applications distantes et quels modules charger.
• Shared Modules : Module Federation permet de définir des modules partagés. Lorsque plusieurs applications consomment le même module partagé, une seule instance de ce module est chargée et partagée entre elles. C'est un aspect essentiel pour optimiser la taille des bundles et prévenir les conflits de dépendances.

Le Mécanisme :

Lorsqu'une application hôte a besoin d'un module d'un distant, elle le demande au conteneur du distant. Le conteneur distant charge alors dynamiquement le module demandé. Si le module est déjà chargé par une autre application consommatrice, il sera partagé. Ce chargement et ce partage dynamiques se produisent de manière transparente à l'exécution, offrant un moyen très efficace de gérer les dépendances.

Avantages de Module Federation pour le Développement Global

Les avantages de l'adoption de Module Federation pour la création d'applications globales sont substantiels et étendus :

1. Évolutivité et Maintenabilité Améliorées :

En décomposant une grande application en microfrontends plus petits et indépendants, Module Federation favorise intrinsèquement l'évolutivité. Les équipes peuvent travailler sur des microfrontends individuels sans impacter les autres, ce qui permet un développement parallèle et des déploiements indépendants. Cela réduit la charge cognitive associée à la gestion d'une base de code massive et rend l'application plus maintenable sur le long terme.

2. Optimisation de la Taille des Bundles et des Performances :

L'avantage le plus significatif du partage d'exécution est la réduction de la taille globale du téléchargement. Au lieu que chaque application duplique les bibliothèques communes (comme React, Lodash ou une bibliothèque de composants d'interface utilisateur personnalisée), ces dépendances sont chargées une seule fois et partagées. Cela conduit à :

• Temps de Chargement Initial Plus Rapides : Les utilisateurs téléchargent moins de code, ce qui se traduit par un rendu initial plus rapide de l'application.
• Navigation Ultérieure Améliorée : Lors de la navigation entre des microfrontends qui partagent des dépendances, les modules déjà chargés sont réutilisés, ce qui offre une expérience utilisateur plus réactive.
• Charge Serveur Réduite : Moins de données sont transférées depuis le serveur, ce qui peut potentiellement réduire les coûts d'hébergement.

Imaginez une plateforme de commerce électronique mondiale avec des sections distinctes pour les listes de produits, les comptes utilisateurs et le paiement. Si chaque section est un microfrontend séparé, mais qu'elles reposent toutes sur une bibliothèque de composants d'interface utilisateur commune pour les boutons, les formulaires et la navigation, Module Federation garantit que cette bibliothèque n'est chargée qu'une seule fois, quelle que soit la section que l'utilisateur visite en premier.

3. Autonomie et Collaboration Accrues des Équipes :

Module Federation permet à différentes équipes, potentiellement situées dans diverses régions du monde, de travailler indépendamment sur leurs microfrontends respectifs. Elles peuvent choisir leurs propres piles technologiques (dans une certaine mesure, pour maintenir un certain niveau de cohérence) et leurs calendriers de déploiement. Cette autonomie favorise une innovation plus rapide et réduit les frais de communication. Cependant, la capacité à partager du code commun encourage également la collaboration, car les équipes peuvent contribuer et bénéficier de bibliothèques et de composants partagés.

Imaginez une institution financière mondiale avec des équipes distinctes en Europe, en Asie et en Amérique du Nord responsables de différentes offres de produits. Module Federation permet à chaque équipe de développer ses fonctionnalités spécifiques tout en tirant parti d'un service d'authentification commun ou d'une bibliothèque de graphiques partagée développée par une équipe centrale. Cela favorise la réutilisabilité et assure la cohérence entre les différentes lignes de produits.

4. Agnosticisme Technologique (avec des réserves) :

Bien que Module Federation soit construit sur Webpack, il permet un certain degré d'agnosticisme technologique entre les différents microfrontends. Un microfrontend pourrait être construit avec React, un autre avec Vue.js, et un autre avec Angular, tant qu'ils s'accordent sur la manière d'exposer et de consommer les modules. Cependant, pour un véritable partage d'exécution de frameworks complexes comme React ou Vue, une attention particulière doit être portée à la manière dont ces frameworks sont initialisés et partagés pour éviter que plusieurs instances ne soient chargées et ne provoquent des conflits.

Une entreprise SaaS mondiale pourrait avoir une plateforme principale développée avec un framework, puis lancer des modules de fonctionnalités spécialisés développés par différentes équipes régionales utilisant d'autres frameworks. Module Federation peut faciliter l'intégration de ces parties disparates, à condition que les dépendances partagées soient gérées avec soin.

5. Gestion des Versions Simplifiée :

Lorsqu'une dépendance partagée doit être mise à jour, seul le distant qui l'expose doit être mis à jour et redéployé. Toutes les applications consommatrices récupéreront automatiquement la nouvelle version lors de leur prochain chargement. Cela simplifie le processus de gestion et de mise à jour du code partagé dans l'ensemble du paysage applicatif.

Mise en Œuvre de Module Federation : Exemples Pratiques et Stratégies

Voyons comment configurer et utiliser Module Federation en pratique. Nous utiliserons des configurations Webpack simplifiées pour illustrer les concepts de base.

Scénario : Partager une Bibliothèque de Composants d'Interface Utilisateur

Supposons que nous ayons deux applications : un 'Catalogue de Produits' (distant) et un 'Tableau de Bord Utilisateur' (hôte). Toutes deux doivent utiliser un composant 'Button' partagé provenant d'une bibliothèque dédiée 'Shared UI'.

1. La Bibliothèque 'Shared UI' (Distant) :

Cette application exposera son composant 'Button'.

            
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 où le distant sera servi
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'sharedUI',
      filename: 'remoteEntry.js',
      exposes: {
        './Button': './src/components/Button.js', // Expose le composant Button
      },
      shared: {
        // Définit les dépendances partagées
        react: {
          singleton: true, // S'assure qu'une seule instance de React est chargée
        },
        'react-dom': {
          singleton: true,
        },
      },
    }),
  ],
  // ... autres configurations webpack (babel, devServer, etc.)
};

            

              
                Copy
              
            
          

src/components/Button.js :

            
import React from 'react';

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

export default Button;

            

              
                Copy
              
            
          

Dans cette configuration, 'Shared UI' expose son composant Button et déclare react et react-dom comme dépendances partagées avec singleton: true pour s'assurer qu'elles sont traitées comme des instances uniques à travers les applications consommatrices.

2. L'Application 'Catalogue de Produits' (Distant) :

Cette application devra également consommer le composant Button partagé et partager ses propres dépendances.

            
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 où ce distant sera servi
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'productCatalog',
      filename: 'remoteEntry.js',
      exposes: {
        './ProductList': './src/components/ProductList.js', // Expose ProductList
      },
      remotes: {
        // Définit un distant qu'il doit consommer
        sharedUI: 'sharedUI@http://localhost:3001/dist/remoteEntry.js',
      },
      shared: {
        // Dépendances partagées avec la même version et singleton: true
        react: {
          singleton: true,
        },
        'react-dom': {
          singleton: true,
        },
      },
    }),
  ],
  // ... autres configurations webpack
};

            

              
                Copy
              
            
          

Le 'Catalogue de Produits' expose maintenant son composant ProductList et déclare ses propres distants, en pointant spécifiquement vers l'application 'Shared UI'. Il déclare également les mêmes dépendances partagées.

3. L'Application 'Tableau de Bord Utilisateur' (Hôte) :

Cette application consommera le composant Button de 'Shared UI' et le ProductList de 'Catalogue de Produits'.

            
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 où les bundles de cette application sont servis
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'userDashboard',
      remotes: {
        // Définit les distants dont cette application hôte a besoin
        sharedUI: 'sharedUI@http://localhost:3001/dist/remoteEntry.js',
        productCatalog: 'productCatalog@http://localhost:3002/dist/remoteEntry.js',
      },
      shared: {
        // Dépendances partagées qui doivent correspondre aux distants
        react: {
          singleton: true,
          import: 'react', // Spécifie le nom du module pour l'importation
        },
        'react-dom': {
          singleton: true,
          import: 'react-dom',
        },
      },
    }),
  ],
  // ... autres configurations webpack
};

            

              
                Copy
              
            
          

src/index.js pour 'Tableau de Bord Utilisateur' :

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

// Importe dynamiquement le composant Button partagé
const RemoteButton = React.lazy(() => import('sharedUI/Button'));

// Importe dynamiquement le composant ProductList
const RemoteProductList = React.lazy(() => import('productCatalog/ProductList'));

const App = () => {
  const handleClick = () => {
    alert('Bouton cliqué depuis l'UI partagée !');
  };

  return (
    

      
Tableau de Bord Utilisateur
      Chargement du bouton...
}>
        Cliquez-moi
      

      
Produits
      Chargement des produits...