Qu'est-ce que les micro-frontends ?

Qu'est-ce que les micro-frontends ?

Les micro-frontends sont un style d'architecture où des applications frontend livrables indépendamment sont composées en un ensemble plus grand. C'est la formulation de l'article de Cam Jackson sur martinfowler.com. Ils transposent au navigateur l'idée des microservices : chaque équipe possède une tranche de l'interface de bout en bout, la construit et la livre sans coordonner une livraison de tout le frontend.

Fonctionnement

Une application conteneur (souvent appelée shell) décide quel micro-frontend afficher et assemble les morceaux en une seule page. L'article décrit plusieurs façons de les intégrer :

• Composition côté serveur. Le serveur assemble du HTML à partir de fragments, par exemple avec des server-side includes.
• Intégration au build. Chaque micro-frontend est publié comme paquet et empaqueté dans le conteneur. L'article la déconseille, car elle impose des livraisons synchronisées.
• Intégration à l'exécution avec des iframes. Isolation forte, mais le routage, les liens profonds et l'affichage adaptatif se compliquent.
• Intégration à l'exécution avec JavaScript. Chaque micro-frontend se charge par un script et expose une fonction que le conteneur appelle pour le monter. C'est le choix par défaut des auteurs.
• Intégration à l'exécution avec des Web Components. Chaque micro-frontend est un élément personnalisé créé par le conteneur.

Exemple

Une boutique en ligne a une équipe recherche produit, une équipe paiement et une équipe compte. Le shell affiche l'en-tête et route par URL : /search charge l'appli de recherche, /checkout celle du paiement. L'équipe paiement peut livrer un correctif l'après-midi sans toucher à la recherche. Chaque appli pourrait même utiliser un framework différent, comme React ou Vue.js, mais c'est rarement une bonne idée.

Quand c'est justifié, et erreurs courantes

Les micro-frontends résolvent un problème d'organisation : beaucoup d'équipes sur un grand frontend qui se bloquent mutuellement. Le même article en liste les coûts : des dépendances dupliquées peuvent alourdir le téléchargement, les environnements de développement peuvent se comporter autrement que le conteneur de production, et il y a plus de dépôts, de pipelines et de serveurs à exploiter. Garder une expérience cohérente entre des bases de code séparées est aussi plus difficile.

• Les adopter pour une petite équipe. Une application unique bien structurée est plus simple.
• Découper par couche technique plutôt que par domaine métier. Les équipes redeviennent dépendantes les unes des autres.
• Partager l'état par des variables globales. Le couplage caché ramène le monolithe. Préférez des événements ou l'URL.
• Laisser chaque équipe choisir un framework différent. L'utilisateur télécharge alors plusieurs runtimes.
• Aucune règle de design commune. Boutons et espacements divergent.

Micro-frontends, tests de charge et supervision

Une page dépend désormais de plusieurs bundles et de plusieurs backends : le morceau le plus lent donne le rythme. Mesurez chaque partie, pas seulement le shell. Lancez un test de charge sur les API appelées par chaque micro-frontend et suivez la disponibilité et le temps de réponse des API en production. Notre guide sur les tests de charge de microservices dans le cloud (en anglais) traite le côté backend. Le modèle de l'application monopage est la base de nombreux micro-frontends. Pour le catalogue complet des modèles, lisez l'article original (en anglais).

Questions fréquentes

Quelle différence entre micro-frontends et microservices ?

Les microservices découpent le backend en services indépendants. Les micro-frontends appliquent la même idée à l'interface, de sorte qu'une équipe peut posséder une fonctionnalité de l'écran jusqu'à son service. Ils sont souvent utilisés ensemble, mais chacun fonctionne seul.

Les micro-frontends imposent-ils un framework précis ?

Non. L'approche est indépendante de tout framework. Le conteneur et les micro-frontends ont seulement besoin d'une façon convenue de se monter, se démonter et communiquer.

Les micro-frontends nuisent-ils aux performances ?

Ils le peuvent si chacun embarque sa propre copie des bibliothèques communes. Partager les dépendances et mesurer le chargement par route maintient le coût sous contrôle.

Quand éviter les micro-frontends ?

Quand une seule équipe peut gérer confortablement tout le frontend. Les pipelines supplémentaires, le code d'intégration et le travail de cohérence ne se justifient qu'avec plusieurs équipes devant livrer indépendamment.