Gestion des versions, déploiement et orchestration

La principale valeur de Module Federation est le déploiement indépendant : une équipe peut mettre à jour, vérifier et déployer son application distante sans se coordonner avec les équipes responsables des applications hôtes ni déclencher leur redéploiement. L’application hôte récupère automatiquement les modifications la prochaine fois qu’elle charge remoteEntry.js depuis l’adresse de l’application distante.

Au lieu de servir remoteEntry.js à une adresse fixe, qui change à chaque déploiement, incluez une empreinte de contenu dans l’adresse : remoteEntry.[hash].js. Chaque déploiement devient ainsi immuable : les anciennes adresses continuent de fonctionner et l’application hôte référence la nouvelle empreinte une fois mise à jour vers le nouveau déploiement. Les adresses immuables permettent une mise en cache intensive par le CDN.

Comme l’application hôte découvre les applications distantes via leur adresse, vous pouvez mettre en place une expérimentation A/B au niveau de l’infrastructure : servez à différents utilisateurs différentes adresses remoteEntry.js, qui pointent vers différentes versions de l’application distante. Cela permet de véritables déploiements progressifs pour les microinterfaces, sans aucune logique d’indicateur de fonctionnalité dans le code de l’application.

Au lieu d’inscrire en dur les adresses des applications distantes dans la configuration Webpack, l’application hôte récupère un manifeste JSON au démarrage : GET /federation-manifest.json renvoie { buttonApp: 'https://cdn.example.com/button/remoteEntry.abc123.js' }. Pour modifier la version utilisée par l’application hôte, mettez à jour le manifeste : aucune reconstruction de l’application hôte n’est nécessaire.

Lorsqu’un déploiement de l’application distante introduit une régression, le rétablissement est immédiat : mettez à jour federation-manifest.json pour qu’il pointe vers l’ancienne adresse remoteEntry.js. L’application hôte recommence immédiatement à utiliser l’ancienne version lors du cycle de requêtes suivant. Aucune reconstruction de l’application hôte, aucun rétablissement de celle-ci et aucune coordination ne sont nécessaires.

La version 2.0 de Module Federation (le package @module-federation/enhanced) apporte des améliorations importantes : une meilleure prise en charge de TypeScript grâce à la génération automatique des types à partir des manifestes distants, une API de modules d’extension à l’exécution pour personnaliser la logique de chargement, ainsi qu’une gestion améliorée de la portée partagée pour les scénarios complexes de négociation de versions.

Le package vite-plugin-federation apporte Module Federation aux projets basés sur Vite, en utilisant une API de configuration similaire à celle de ModuleFederationPlugin de Webpack. Il est compatible à la fois avec les modules distants Vite et les hôtes Webpack, et inversement, ce qui permet aux équipes de migrer progressivement vers Vite sans abandonner Module Federation.

Pour les architectures très dynamiques, vous pouvez configurer entièrement les URL des modules distants à l’exécution : import(remoteRegistry[featureName]), où remoteRegistry est alimenté par un appel d’API. Cela permet de créer des architectures semblables à des systèmes de modules d’extension, dans lesquelles de nouveaux micro-frontends peuvent être ajoutés sans reconstruire l’application conteneur.

La mission principale de l’application conteneur est l’orchestration : elle lit le manifeste distant, initialise l’environnement d’exécution de Module Federation, enregistre les modules distants sous des routes nommées et affiche le module distant approprié selon l’URL actuelle. L’application conteneur reste volontairement légère : elle sait quoi charger, mais pas comment l’afficher.

Ajoutez une surveillance des performances au chargement des modules distants : encapsulez les importations distantes dans try/catch afin de gérer élégamment les échecs de chargement, affichez une interface de repli si le module distant est indisponible, mesurez le temps nécessaire au téléchargement de remoteEntry.js et des fragments de composants, puis déclenchez une alerte si le temps de chargement du module distant dépasse un seuil, ce qui peut indiquer des problèmes avec le CDN.

Une chaîne CI/CD Module Federation mature suit généralement ce processus : l’équipe du module distant valide ses modifications → la CI construit le module distant → le fichier immuable remoteEntry.[hash].js est téléversé vers le CDN → federation-manifest.json est mis à jour → l’hôte récupère le nouveau module distant lors de la prochaine requête utilisateur. Chaque étape est automatisée et l’équipe hôte n’intervient jamais dans les déploiements des modules distants.

Quelle est la manière la plus rapide de restaurer un déploiement défectueux d’un module distant avec Module Federation ?

Module Federation permet de véritables déploiements indépendants : les modules distants sont déployés sans reconstruire l’hôte, qui découvre automatiquement les nouvelles versions. Utilisez des URL de modules distants contenant le hachage du contenu pour permettre une mise en cache CDN immuable, ainsi qu’un manifeste dynamique pour acheminer les versions avec souplesse et effectuer des restaurations instantanées. vite-plugin-federation apporte ces fonctionnalités à Vite, tandis que les importations dynamiques de modules distants permettent de créer des architectures semblables à des systèmes de modules d’extension. L’application conteneur orchestre le chargement des modules distants et reste volontairement légère.