Principes de l’architecture micro-frontend

Les micro-interfaces appliquent les idées des microservices à l’interface utilisateur : une application volumineuse est divisée en parties développées et déployées indépendamment, chacune étant gérée par une équipe distincte, puis assemblées pour former une expérience unique pour l’utilisateur.

Une interface utilisateur volumineuse signifie que chaque équipe travaille dans une seule base de code, coordonne les mises en production et partage une seule génération. À mesure que l’organisation grandit, cela devient un goulot d’étranglement : générations lentes, conflits de fusion et cycles de mise en production.

L’idée centrale est la responsabilité de bout en bout. Une équipe est responsable de son segment de l’interface utilisateur, du code au déploiement — avec son propre dépôt, sa propre chaîne d’intégration et son propre environnement d’exécution — afin d’avancer sans attendre les autres.

Les équipes sont réparties selon la capacité métier (Paiement, Recherche, Profil), et non selon la couche technique. Chaque segment contient sa propre interface utilisateur, sa logique et son accès aux données pour cette capacité.

Chaque micro-frontend est livré selon son propre calendrier. L’équipe Recherche peut déployer dix fois par jour sans toucher au Paiement. Les mises en production sont découplées, ce qui réduit les risques et la coordination nécessaire.

Les équipes peuvent choisir des technologies différentes pour chaque segment. En pratique, la plupart des organisations se standardisent (par exemple, toutes sur Vue) afin de disposer d’outils communs, mais l’architecture autorise la diversité lorsqu’elle est justifiée.

Une façon de combiner les segments consiste à utiliser une intégration à la compilation : chaque micro-frontend est publié sous forme de paquet, puis l’application conteneur l’installe comme dépendance et le compile avec les autres.

L’intégration à la compilation est simple, mais elle couple les mises en production : pour livrer une nouvelle version du Paiement, le conteneur doit être recompilé et redéployé. Vous perdez ainsi le véritable déploiement indépendant.

L’intégration à l’exécution charge les micro-frontends dans le navigateur au moment de leur utilisation : le conteneur récupère le code d’une application distante lorsqu’il en a besoin. Chaque application distante est déployée indépendamment ; le conteneur obtient la dernière version sans être recompilé.

La principale technique d’intégration à l’exécution est Module Federation : une fonctionnalité de compilation qui permet à une application d’exposer des modules et à une autre de les consommer sur le réseau au moment de l’exécution, tout en partageant les dépendances communes. Vous l’utiliserez dans les prochaines leçons.

Utilisez l’intégration à la compilation pour les petites équipes qui recherchent la simplicité et un déploiement unique. Utilisez l’intégration à l’exécution (Module Federation) lorsque le déploiement indépendant et l’autonomie des équipes sont prioritaires et que vous acceptez une complexité opérationnelle accrue.

Vérifiez votre compréhension des principes des micro-frontends.

Vous avez appris les principes des micro-frontends :

• Une interface utilisateur volumineuse est divisée en segments dont la responsabilité et le déploiement sont indépendants, puis assemblés pour l’utilisateur.
• Autonomie des équipes : responsabilité de bout en bout d’un segment métier vertical.
• Déploiement indépendant : chaque segment est livré selon son propre calendrier.
• La diversité technologique est facultative ; la plupart des équipes se standardisent.
• L’intégration se fait à la compilation (simple, mises en production couplées) ou à l’exécution (Module Federation, véritable indépendance).