Module Federation : Le guide définitif du partage de modules à l'exécution dans les micro-frontends

Dans le paysage en constante évolution du développement web, nous avons assisté à un changement architectural majeur. Nous sommes passés des architectures monolithiques aux microservices backend, en quête de scalabilité et d'autonomie des équipes. Aujourd'hui, cette même révolution transforme le frontend. L'ère des micro-frontends est arrivée, et au cœur de celle-ci se trouve une technologie puissante qui rend tout cela possible : Module Federation.

Le défi principal des micro-frontends a toujours été simple à énoncer mais difficile à résoudre : comment construire une expérience utilisateur unique et cohérente à partir de multiples applications déployées indépendamment, sans créer un désordre lent, lourd et ingérable ? Comment partager du code commun, comme des bibliothèques de composants ou des frameworks comme React, sans créer des cauchemars de versionnage ou forcer des lancements coordonnés ?

C'est le problème que Module Federation résout avec élégance. Introduit dans Webpack 5, ce n'est pas juste une autre fonctionnalité ; c'est un changement de paradigme dans notre façon de concevoir et de déployer des applications web. Ce guide complet explorera le quoi, le pourquoi et le comment de Module Federation, en se concentrant sur sa capacité la plus transformatrice : le partage de modules à l'exécution.

Un bref rappel : que sont les micro-frontends ?

Avant de plonger dans les mécanismes de Module Federation, mettons-nous d'accord sur ce que nous entendons par micro-frontends. Imaginez un grand site de commerce électronique. Dans un monde monolithique, l'ensemble du frontend — la recherche de produits, les détails des produits, le panier d'achat et le paiement — est une seule et grande application. Un changement sur le bouton de paiement pourrait nécessiter de tester et de redéployer l'application entière.

Une architecture micro-frontend décompose ce monolithe en domaines métier. Vous pourriez avoir :

• Une équipe Recherche qui gère la barre de recherche et la page de résultats.
• Une équipe Produit qui gère les détails des produits et les recommandations.
• Une équipe Paiement qui gère le panier d'achat et le processus de paiement.

Chaque équipe peut construire, tester et déployer sa partie de l'application indépendamment. Cela conduit à plusieurs avantages clés :

• Équipes autonomes : Les équipes peuvent travailler et livrer selon leurs propres calendriers, accélérant ainsi le développement.
• Déploiements indépendants : Un bug dans le moteur de recommandations ne bloque pas une mise à jour critique du flux de paiement.
• Flexibilité technologique : L'équipe de recherche pourrait utiliser Vue.js tandis que l'équipe produit utilise React, permettant aux équipes de choisir le meilleur outil pour leur domaine spécifique (bien que cela nécessite une gestion minutieuse).

Cependant, cette approche introduit ses propres défis, principalement autour du partage et de la cohérence, ce qui nous amène aux anciennes méthodes.

Les anciennes méthodes de partage de code (et pourquoi elles sont insuffisantes)

Historiquement, les équipes ont essayé plusieurs méthodes pour partager du code entre différentes applications frontend, chacune avec des inconvénients majeurs dans un contexte de micro-frontend.

Paquets NPM

L'approche la plus courante est de publier des composants ou des utilitaires partagés sous forme de paquet NPM versionné. Une bibliothèque de composants partagée en est un exemple classique.

• Le problème : Il s'agit d'une dépendance de build-time (au moment de la compilation). Si l'équipe A met à jour le composant partagé `Button` dans `my-ui-library` de la version 1.1 à 1.2, les équipes B et C ne recevront pas cette mise à jour tant qu'elles n'auront pas mis à jour manuellement leur `package.json`, exécuté `npm install` et redéployé l'ensemble de leur micro-frontend. Cela crée un couplage fort et va à l'encontre de l'objectif des déploiements indépendants. Cela conduit également au chargement de multiples versions du même composant dans le navigateur, alourdissant le bundle final.

Monorepos avec des espaces de travail partagés

Les monorepos (utilisant des outils comme Lerna ou les workspaces Yarn/NPM) conservent tous les micro-frontends dans un seul dépôt. Cela simplifie la gestion des paquets partagés.

• Le problème : Bien que les monorepos améliorent l'expérience des développeurs, ils ne résolvent pas le problème fondamental à l'exécution. Vous dépendez toujours de dépendances de build-time. Une modification d'une bibliothèque partagée nécessite toujours que toutes les applications consommatrices soient reconstruites et redéployées pour refléter le changement.

Scripts externes via les balises <script>

La méthode à l'ancienne consistant à inclure des bibliothèques comme jQuery ou React via une balise `