Un micro frontend est une interface utilisateur composée d'applications frontend autonomes et déployables. Cette approche a été officiellement mise en avant par Thoughtworks dans 2016et une 2024 le sondage a rapporté que 23.6% de répondants avaient utilisé des micro frontends dans l'année précédente, comparés à 75.4% in 2022. État des données Frontend
You may be dealing with the problem already. Three product teams share one frontend repository and wait for the same release train, even when one team is changing checkout, another is updating profiles, and the third is adjusting marketing pages. A micro frontend architecture separates those product areas so teams can own, test, and release them independently while users still experience one application.
Cette distinction compte. Les micro frontends ne sont pas des dossiers, des composants ou des bundles plus petits. indépendance organisationnelle et de publication, supported by technical boundaries that make ownership explicit. The architecture can remove a coordination bottleneck, but it also introduces runtime integration, dependency governance, testing, security, and performance responsibilities.
Table des matières
- Comprendre le Concept de Micro Frontend
- Comment fonctionne l'Architecture de Micro Frontend
- Comparer les Modèles de Micro Frontend Fondamentaux
- Avantages, Inconvénients et Risques Cachés
- Pratiques de test et de déploiement de migration
- Utilisation des micro-frontal en Capacitor et Electron
- Quand choisir les micro-frontal
Comprendre le concept de micro-frontal
De un frontend à plusieurs applications propriétaires
A un frontend traditionnel, il y a souvent un seul dépôt, une seule compilation et une seule limite de déploiement. Même si le code est divisé en dossiers de fonctionnalités propres, les équipes derrière ces dossiers peuvent toujours dépendre du même pipeline et du même calendrier de publication. Une petite modification dans une zone peut déclencher une compilation complète de l'application, des tests de régression partagés et une coordination avec chaque équipe.
Un frontend micro divise l'application de navigateur autour des capacités commerciales. L'équipe de paiement gère le paiement, l'équipe de profil gère les paramètres de compte et l'équipe de marketing gère le contenu promotionnel. Chaque morceau peut avoir son propre codebase, son processus de livraison et son rythme de publication, puis devenir partie d'une expérience plus large à travers un noyau ou un layer de composition.
Martin Fowler définit le modèle comme “un style architectural où des applications frontend indépendamment déployables sont composées en un tout plus grand” dans sa guide fondamentale sur l'architecture des micro frontends. Le mot « indépendamment déployable » porte plus d'importance que « applications frontend ». Sans une limite de déploiement indépendante, vous pouvez avoir un monolithe modulaire plutôt qu'un système de frontend micro.
Une analogie de magasin composé
Imaginez un grand magasin. Une équipe gère le magasin, une autre gère le comptoir de caisse, et une autre gère les retours. Le client voit un seul magasin, mais chaque zone a des processus, des responsabilités et du personnel différents. Un micro frontend fonctionne de la même manière : le navigateur affiche une expérience de produit unique tandis que plusieurs équipes gèrent des zones d'interface distinctes en arrière-plan.
La coque de l'application possède généralement la structure partagée, la navigation, le contexte d'authentification et les décisions de route. Un micro frontend possède la page ou la capacité à l'intérieur de cette coque. Les équipes s'accordent sur les limites entre eux, mais elles n'ont pas besoin de partager tous les détails d'implémentation.
Le terme est associé à l'extension du pensée de microservices au navigateur après que Thoughtworks l'a mis en avant dans son Radar technologique de novembre 2016. Fowler a ensuite documenté sa progression de l'Assessment à l'essai et puis à l'adoption, qui décrit le mouvement du modèle d'un technique emergente vers une option architecturale plus établie. Pour une vue d'ensemble plus large et pratique de la mise en œuvre web scalable par Nerdifyil est utile de comparer le modèl’avec des approches adjacentes telles que l'architecture de plugin, qui est discutée dans ce guide de l'architecture de plugin.
La leçon importante est que les micro frontends ne constituent pas une mise à niveau par défaut pour chaque interface. Ils ont du sens lorsque les limites de l'équipe et les limites de publication créent des douleurs réelles. Le coût est justifié uniquement lorsque cette indépendance est digne de gérer plus de contrats, d'actifs, de modes de failure runtime et d'outillage opérationnel.
Comment fonctionne l'architecture des micro frontends
La coquille et ses fragments
Un système fonctionnel commence généralement par un app shell, également appelé conteneur ou orchestrateur. La coquille affiche la disposition commune, établit la navigation, fournit le contexte d'authentification et offre des éléments d'interface partagés comme la navigation ou les notifications. Elle décide également quel micro frontend charger et où ce fragment doit s'ancrer.
Chaque fragment est une application maintenue indépendamment. Il peut vivre dans un dépôt séparé, utiliser son propre pipeline CI, publier sa propre version et exposer un bundle, un fragment, un composant web ou un module distant. La coquille compose ces pièces dans le navigateur, soit lors du chargement de la page, soit lorsqu'une route les nécessite.
Une limite n'est utile que si les équipes peuvent s'y fier. La coquille et chaque fragment ont besoin d'un contrat explicite couvrant le comportement de montage, la propriété de la route, les états de chargement, la gestion des erreurs, les jetons de conception, les attentes d'accessibilité et les versions de dépendances supportées.
Règle pratique : Partagez les contrats et les primitives visuelles de manière délibérée. N'implémentez pas les détails d'exécution en fonction des frameworks utilisés par les deux équipes actuellement.
Communication sans recréer le monolithe
Les fragments ont parfois besoin de communiquer. Un morceau de paiement peut avoir besoin de savoir que l'utilisateur s'est connecté, tandis qu'un morceau de profil peut avoir besoin de publier un événement de mise à jour de compte. Les équipes peuvent utiliser des événements personnalisés du navigateur, un magasin partagé, des paramètres URL ou des services injectés.
Tout option crée un profil de couplage différent :
- Événements personnalisés gardent la propriété séparée, mais les équipes doivent documenter les noms d'événements, les formes de charge utile et les temps.
- Magasins partagés simplifient l'état coordonné, mais ils peuvent recréer le graphique de dépendance central que l'architecture visait à réduire.
- Paramètres URL fonctionnent bien pour la navigation et l'état partageable, bien qu'ils ne soient pas adaptés à chaque interaction.
- Services injectés fournissent des capacités contrôlées, mais le shell doit maintenir les contrats de service.
Le shell devrait coordonner uniquement ce qui appartient à l'application entière. Si elle devient responsable de l'état et des règles commerciales de chaque fragment, elle est devenue un monolithe distribué avec un processus de déploiement plus compliqué.
La progression historique documentée par Fowler explique pourquoi le modèl’est souvent comparé aux microservices. Les deux approches séparent la propriété et la livraison, mais les micro frontends appliquent cette indépendance à l'interface du navigateur. Dans les outils actuels, Utilisation de Module Federation Single-spa reste une option d'orchestration pour les équipes qui souhaitent une inscription basée sur le cycle de vie des applications.
Par exemple, l'équipe de paiement peut corriger le flux de paiement sans reconstruire le fragment du catalogue. L'équipe du catalogue peut continuer sur un rythme de publication plus lent car le shell charge chaque morceau approuvé en fonction de sa configuration de runtime. Cette frontière de livraison independante, et non l'apparence visuelle de composants séparés, est le principal avantage de l'architecture.
Une équipe évaluant la plateforme environnante doit également considérer l'infrastructure d'application pour les systèmes frontend, car les seuls dépôts et frameworks ne fournissent pas une composition fiable.
Comparaison des modèles de micro frontends fondamentaux
Aucun mécanisme d'intégration unique ne résout tous les problèmes de micro frontends. Choisissez en comparant l'isolement, la communication, le partage de dépendances, le comportement du navigateur et la propriété opérationnelle plutôt que de sélectionner l'outil le plus à la mode.
| Modèle | Isolement | Modèle d'intégration | Dépendances partagées | Performances | Best Fit |
|---|---|---|---|---|---|
| Iframes | Un processus et une isolation de document solides | Document intégré avec messagerie transversale entre cadres | Par défaut, sans | Pouvez ajouter un surcoût de chargement et de communication | Expériences non fiables, obsolètes ou fortement isolées |
| Composants web | Élément encapsulé et, le cas échéant, stylage Shadow DOM | Éléments personnalisés montés par le shell | Jetons de conception partagés et API du navigateur | Souvent prévisible, mais cela dépend du poids du composant | Équipes axées sur les normes nécessitant de la flexibilité de cadre |
| Fédération de modules | Isolation de runtime modérée | Modules distants chargés et montés en temps de exécution | Dépendances explicitement négociées ou bundlées | Efficace lorsqu'on contrôle la charge et la déduplication | Applications intégrées de manière étroite avec des versions independentes |
| single-spa | Frontière d'orchestration plutôt qu'un modèle d'isolement complet | Applications enregistrées à l'aide de hooks de cycle de vie | Dépend des applications et de la configuration racine | Dépend des règles de chargement et de la composition du framework | Orchestration multi-framework avec activation basée sur les routes |
Iframes
Un iframe offre le plus fort niveau d'isolement dans cette comparaison. L'application intégrée dispose de son propre document, de ses styles et de son environnement JavaScript, elle ne mutera donc pas accidentellement le DOM de la page hôte. La messagerie entre fenêtres peut créer un chemin de communication contrôlé.
Cette isolation rend les iframes utiles pour les systèmes de legacy, les expériences de partenaires ou le contenu qui doit rester séparé. Le coût apparaît dans la mise en page réactive, la navigation, l'accessibilité, la gestion de l'accent et l'authentification partagée. Un iframe de paiement peut ressembler à une surface étrangère si l'application hôte et l'application intégrée ne coordonnent pas soigneusement.
Composants Web
Les composants Web utilisent des normes du navigateur plutôt que de nécessiter que chaque équipe adopte le même framework. Les éléments personnalisés définissent une surface de montage stable, et le Shadow DOM peut limiter la fuite de styles. Le shell doit encore gérer la routage de l'application, les états de chargement, les limites d'erreur et les jetons de conception partagés.
Cette option fonctionne bien lorsque les équipes veulent de la flexibilité de framework sans faire charger le navigateur des runtimes d'application entiers pour chaque morceau. Cela ne résout pas automatiquement la taille des dépendances, la communication de l'état ou la gouvernance. Un élément personnalisé peut toujours contenir une grande application avec sa propre complexité opérationnelle.
La Fédération de Module
Module Federation, introduit avec Webpack 5 et pris en charge par des outils comme Vite et Rspack, charge des modules compilés à partir d'entrées distantes en temps de exécution. Il offre une intégration serrée, ce qui rend les composants partagés et la navigation coordonnée plus naturels qu'ils ne le sont souvent avec les iframes.
Cette commodité crée une responsabilité. Les équipes ont besoin d'interfaces exposées compatibles, de règles pour les dépendances partagées, de gestion des versions distantes et d'un plan de récupération lorsqu'une entrée distante ne peut pas charger. La différence entre l'architecture monolithique et l'architecture en microservices provides useful context for separating deployment independence from simple code decomposition.
single-spa
single-spa agit comme un orchestrateur indépendant des frameworks. Les équipes s'inscrivent les applications et les hooks de cycle de vie, puis la configuration root active les applications selon les routes ou d'autres conditions. Il peut coordonner les applications construites avec différents frameworks, mais il n'enlève pas la nécessité de contrats, de politiques de dépendances, de budgets de performance ou de contrôles de sécurité.
Les équipes peuvent combiner ces mécanismes. Par exemple, une configuration root single-spa pourrait coordonner les routes, Module Federation pourrait fournir des modules distants, et les composants web pourraient définir la surface de montage publique. Cette combinaison peut être puissante, mais chaque couche ajoutée augmente le nombre de comportements que les développeurs doivent comprendre et tester.
Avantages Coûts et Risques cachés
Les micro frontends déplacent les décisions au-delà des frontières. Ils peuvent réduire la zone d'impact d'une mise à jour et donner aux équipes plus de contrôle, mais le système doit alors gérer plus d'artefacts, de contrats et de conditions de temps d'exécution.
| Dimension | Avantage | Coût / Risque caché |
|---|---|---|
| L'autonomie de l'équipe | Teams own a business slice end to end | Teams must maintain separate pipelines, on-call ownership, and release discipline |
| Déploiement | Un fragment peut être déployé sans reconstruire l'interface complète | Releases become non-atomic, so incompatible versions may meet in production |
| L'isolement des échecs | Un composant distant échoué peut être contenu avec un redoublement | Les mauvaises limites d'erreur peuvent toujours rendre la navigation ou les parcours critiques inutilisables |
| Performance | Chargement différé et paquets initiaux plus petits peuvent aider les flux courants | Plusieurs requêtes, duplication du framework code, et initialisation à distance peuvent nuire à la performance au runtime |
| Choix technologique | Les équipes peuvent utiliser différents frameworks où les limites le permettent | La débogage, l'accessibilité, la cohérence de design et la recrutement deviennent plus difficiles sur un mélange de stack. |
| Sécurité | Une limite peut limiter la partage d'implémentation directe | Le coeur peut exécuter des code à distance qu'il n'a pas vérifié de manière adéquate |
| Gouvernance | Des normes partagées peuvent préserver un produit cohérent | Systèmes de conception, règles de dépendance, contrats et support de plateforme nécessitent une coordination continue |
La facture de performance
Les tranches autonomes produisent généralement des actifs construits séparément. Sans règles de chargement soigneuses, le navigateur peut demander plus de fichiers, initialiser plus de code, ou télécharger des dépendances de framework dupliquées. Les conseils de performance pour les micro frontends mettent l'accent sur le chargement à la demande, la partage de dépendances soigneuse, le cache au niveau du module et l'isolement des erreurs.
Un design pratique commence par un socle pour l'application existante. Mesurez le démarrage de la route, la composition du paquet, le chargement distant, l'initialisation et les erreurs visibles par l'utilisateur. Ensuite, fixez des budgets pour le coquillage et chaque tranche à haute fréquentation. Le chargement différé n'aide que si l'application ne bloque pas le parcours critique sur une longue chaîne de modules distants.
La sécurité aux joints
Un module distant n'est pas automatiquement sûr parce qu'il a un dépôt séparé. Le coquillage peut exécuter code qu'il n'a pas vérifié, et une limite de frontend ne remplace pas l'autorisation aux API ou aux services de jeton. Analyse de micro frontend axée sur la sécurité highlights why trust, signing, integrity checks, and authorization need design attention before teams distribute runtime code.
La dérive de version crée une autre classe de risque. Une fraction peut fonctionner seule mais échouer lorsqu'elle rencontre une version de coquillage différente, une bibliothèque partagée, un ensemble de jetons de conception ou un flux d'événement. Les conseils d'architecture de Nx identifie la coordination, la configuration de l'environnement, l'efficacité de l'application et la réutilisation comme défis continus.
L'architecture ne supprime pas la coordination. Elle la transforme en réunions de contrats, en automatisation, en visibilité et en gouvernance.
Les équipes ont également besoin d'une propriété claire pour les dépendances partagées, des examens d'accessibilité, des réponses aux incidents et des décisions de retrait. Si personne ne possède la couche de plateforme, chaque équipe de produit résoudra la composition différemment, et les utilisateurs expérimenteront l'incohérence résultante comme une application brisée.
Pratiques de test de déploiement et de migration
Le test doit refléter la façon dont l'application fonctionne. Un fragment qui passe ses propres tests unitaires peut toujours échouer lorsque le shell fournit une route modifiée, un état d'authentification inattendu ou une dépendance partagée différente.
Construire un système de test en couches
Commencez par des tests isolés pour chaque fragment. Ces tests valident la mise en page, les règles commerciales, le comportement de la touche, les états de chargement et les traitements d'erreur locaux sans nécessiter la coquille complète.
Les tests de contrat se situent au-dessus d'eux. Ils vérifient l'interface entre la coquille et un fragment, y compris les entrées de montage, les modèles de route, les événements émis, les chargeurs attendus, les hypothèses d'authentification et le comportement de retrait. Les tests de contrat devraient échouer avant la production si une équipe change une interface que consomme une autre équipe.
Les tests d'intégration de shell chargent ensuite des artefacts de fragment réels dans une composition représentative. Ils devraient couvrir les routages, les transitions d'authentification, la navigation partagée, les échecs de chargement et les combinaisons de versions. Les tests end-to-end appartiennent en haut car ils valident des parcours complets comme la consultation d'un produit, la connexion et la finalisation de la commande sur plusieurs tranches livrées indépendamment.
Contrôlez la surface de mise à jour
Utilisez des manifestes versionnés afin que le shell puisse identifier l'artefact de fragment exact qu'il charge. Un manifeste donne également aux opérateurs un endroit pour fixer une version connue-bonne lorsqu'une mise à jour distante entraîne des erreurs.
Les contrôles utiles incluent :
- Les drapeaux de fonctionnalité : Activer un nouveau fragment pour un public interne ou une route sélectionnée avant une exposition large.
- La livraison canari : Diriger un public limité vers l'artefact nouveau tout en surveillant les erreurs de navigateur, les échecs de chargement et les actions commerciales clés.
- Les bundles observables : Ajoutez les identifiants de version aux journaux, aux traces et aux erreurs du client afin que l'équipe responsable puisse identifier le fragment en panne.
- Les chemins de reversion : Maintenez l'artefact compatible précédent disponible et faites de la reversion une action opérationnelle, et non une reconstruction manuelle.
Les équipes devraient tester la coquille et le fragment ensemble dans un environnement simulant la production. Un lancement local réussi ne prouve pas que le chemin de livraison de contenu, la cache, le jeton d'authentification ou le manifeste distant se comporteront correctement pour les utilisateurs. Les pratiques d'automatisation de déploiement peuvent soutenir des workflows de promotion et de reversion répétitifs, mais l'architecture nécessite encore une propriété claire.
Migrer un domaine à la fois
Une migration de strangler route une capacité du monolithe vers un nouveau fragment tout en laissant le reste inchangé. Un commutateur de fonctionnalité peut soutenir des exécutions parallèles, permettant à l'équipe de comparer le nouveau chemin avec l'implémentation existante avant de rendre le nouveau chemin le chemin par défaut.
Considérez une application de commerce avec des équipes de catalogue, de compte et de paiement séparées. La coquille possède la navigation et l'authentification, l'équipe de catalogue possède la navigation des produits, l'équipe de compte possède les paramètres de profil et l'équipe de paiement possède les flux de panier et de paiement. Chaque équipe publie son propre artefact, tandis que les tests de contrat protègent les accords de route et d'événement.
Commencez par un domaine à faible risque, publiez-le derrière un drapeau et observez-l’à travers des parcours réels. Étendez-vous uniquement après que l'équipe puisse déployer, diagnostiquer et faire rouler ce morceau sans demander à l'ensemble de l'organisation de coordonner une mise à jour.
Utiliser les Micro Frontends dans Capacitor et Electron
A Capacitor or Electron application adds another shell around the browser shell. Capacitor places web code inside a native mobile WebView, while Electron runs web code in a desktop renderer process. In both cases, the app can load a local shell that fetches selected frontend artifacts at runtime instead of embedding every interface change in the native binary.
Cette disposition crée une séparation d'édition utile. Les capacités, les permissions et les ponts code restent liés à l'application installée, tandis que les surfaces détenues par le web, telles que le compte, l'aide, le catalogue ou les paramètres, peuvent suivre un chemin de livraison séparé. La coquille doit encore décider d'où viennent les fragments, quelle version est approuvée et ce que l'application doit faire si une étape de récupération ou de vérification échoue.
Mises à jour en temps réel et annulation
Un système de mise à jour en temps réel doit traiter les artefacts frontend comme du logiciel déployable. Il doit les délivrer des ensembles signésles vérifier avant activation, supporter les canaux de mise en production pour les lancements étalés, appliquer les mises à jour à la prochaine lancement plutôt que d'interrompre une session active, et fournir une protection de retrait automatique avec réversion atomique.
Ces contrôles s'appliquent naturellement à la livraison de l'interface utilisateur micro. Une coquille mobile ou de bureau peut fixer un manifeste, récupérer un fragment compatible, vérifier sa signature et l'activer uniquement lorsque l'ensemble complet est disponible. Si la prochaine lancement détecte une erreur, l'actualiseur peut revenir à l'état connu bon avant plutôt que de laisser les utilisateurs avec une interface mise à jour partiellement.
Capgo est une option pour ce modèle de livraison. Sa plateforme de mise à jour en temps réel pour les applications CapacitorJS et Electron publie des bundles web signés, prend en charge les canaux ciblés, applique les mises à jour à la prochaine mise en ligne et fournit des journaux, une histoire de version, des métriques d'adoption et de failure, une protection de rollback, des intégrations CI/CD et un API. comment Capacitor relie les applications web et natives code.
Quels changements dans une coque native ?
Le wrapper natif introduit des contraintes que l'application uniquement en navigateur peut ne pas rencontrer :
- Connectivité : Un fragment peut être indisponible lorsque le dispositif est hors ligne, le shell a donc besoin d'artefacts en cache ou d'un fallback local.
- Compatibilité : Un bundle web peut dépendre du comportement du pont natif que le binôme installé ne prend pas en charge.
- Sécurité : Le code distant doit être authentifié, vérifié et autorisé pour le contexte de l'application.
- Rétablissement : Le shell doit être capable de rejeter un bundle non valide et de restaurer une version fonctionnelle sans nécessiter une distribution immédiate du magasin.
- La sécurité de la session : Mettre à jour pendant une transaction ou un flux de formulaire peut créer un état incohérent, donc l'activation à la prochaine lancement est plus sûre que d'interrompre un travail en cours.
Cette modélisation renforce le rollback lorsque la plateforme de livraison offre une activation atomique et des métriques de publication détaillées. Cela complique l'architecture lorsque les équipes supposent que l'indépendance web élimine la planification de la compatibilité native. Le shell natif reste une limite de contrat, et chaque fragment doit le respecter.
Quand choisir les micro frontends :
Choisissez les micro frontends lorsque le déploiement independent est une exigence réelleplusieurs équipes possèdent des surfaces de produit séparées clairement, ou les interfaces legacy et nouvelles doivent coexister pendant une longue migration. La diversité technologique peut également justifier le modèle lorsque les équipes ont besoin de limites de framework que la construction unique ne peut pas accommoder proprement.
Évitez-le lorsque une petite équipe peut confortablement posséder un frontend unique, lorsque les domaines partagent un état mutable étendu, ou lorsque votre organisation manque de procédures de CI fiables, d'observabilité, de test de contrat et de rollback. Une interface distribuée sans ces fondations ne crée pas l'autonomie. Elle crée plus de lieux pour les erreurs de se cacher.
Utilisez un test de démarrage simple :
- La propriété : Peut une équipe prendre des décisions pour la tranche proposée ?
- Frontière : La coquille et la tranche peuvent-elles communiquer par un contrat stable ?
- Besoin de mise en production : La team a-t-elle besoin de déployer indépendamment ?
- Prêt à l'exploitation : Peut-on surveiller, tester, bloquer et remonter la fragment ?
- Valeur utilisateur: Le split améliorera-t-il la livraison sans endommager les performances ou la cohérence ?
Commencez par une zone à faible risque comme le contenu d'aide ou les paramètres. Définissez le contrat de montage, la propriété des routes, les événements, les jetons de conception, le comportement de fallback et la politique de version. Envoyez derrière un drapeau de fonctionnalité, mesurez le coût ajouté du paquet et du coût de chargement, et documentez chaque nouveau canal, manifeste, règle de dépendance et chemin de remontée.
Les micro-frontends sont un outil pour l'indépendance organisationnelle et de mise en production, pas une amélioration automatique de la qualité de l'avant-plan. Si le problème de mise en production est petit, un monolithe modulaire peut être la meilleure réponse. Si le problème de coordination est grand et persistant, une architecture de micro-frontends gouvernée avec soin peut donner aux équipes l'autonomie dont elles ont besoin.
Si vous évaluez les micro-frontends pour un produit Capacitor ou Electron Capgo Vous pouvez vous aider à livrer des bundles web signés à travers des canaux contrôlés, activer les mises à jour à la prochaine lancement, et récupérer à l'aide de la protection de rollback. Visitez Capgo pour passer en revue ses options de livraison, d'observabilité et de API avant de concevoir votre processus de lancement de fragment.
