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 2016, et un 2024 Enquête a rapporté que 23.6% des répondants avaient utilisé des micro frontends dans l'année précédente, comparé à 75.4% sur 2022. État de Frontend
Vous pouvez déjà vous trouver face à ce problème. Trois équipes de produits partagent un référentiel frontend unique et attendent le même train de lancement, même lorsque l'une des équipes modifie le panier, une autre met à jour les profils et la troisième ajuste les pages de marketing. Une architecture de micro frontends sépare ces zones de produits de sorte que les équipes puissent les posséder, les tester et les lancer indépendamment tout en offrant toujours une expérience d'application unique.
Cette distinction compte. Les micro frontends ne sont pas des dossiers, des composants ou des ensembles plus petits. Leur but central est l'indépendance organisationnelle et de lancement, soutenue par des limites techniques qui rendent l'ownership explicite. L'architecture peut supprimer une bouteille à goutte de coordination, mais elle introduit également des responsabilités de gestion de dépendances, de test, de sécurité et de performance.
Sommaire
- context : Page/zone : Site web de marketing Capgo. Rôle : Étiquette de navigation ou élément UI court. Vu dans : page blog/[slug].astro. Clé de message `table_of_contents` (Sommaire)
- Comment fonctionne l'architecture Micro Frontend
- Comparaison des modèles de Micro Frontend de base
- Avantages, compromis et risques cachés
- Pratiques de test, de déploiement et de migration
- Utiliser les Micro Frontends dans Capacitor et Electron
- Quand choisir les Micro Frontends
Comprendre le concept de Micro Frontends
Passer d'un frontend unique à plusieurs applications propriétaires
Un frontend traditionnel 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 mise en production. 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 micro frontend divise l'application de navigateur autour des capacités commercialesL’équipe de paiement est responsable de la page de paiement, l'équipe de profil est responsable des paramètres de compte, et l'équipe de marketing est responsable du contenu promotionnel.
Martin Fowler définit le modèle comme “un style architectural où des applications frontend autonomes et délivrables sont composées pour former un tout plus grand” dans sa guide fondamentale sur l'architecture des micro frontends . Le mot « autonomes et délivrables » a 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 micro frontends.Des employés stressés assis à leur bureau tenant des papiers représentant différentes équipes de développement de micro frontends dans un bureau.
Imaginez un grand magasin de détail. Une équipe gère l'entrée du magasin, une autre gère le comptoir de paiement, et une autre gère les retours. Le client voit un seul magasin, mais chaque zone a des processus, des responsabilités et des employés 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 derrière les scenes.
L'interface shell gère généralement la fenêtre partagée, la navigation, le contexte d'authentification et les décisions de route. Un micro frontend gère la page ou la capacité à l'intérieur de cette fenêtre. Les équipes s'entendent sur les limites entre elles, mais elles n'ont pas besoin de partager tous les détails d'implémentation.
Un grand magasin de détail est une bonne analogie pour comprendre les micro frontends.
Le terme est devenu associé à l'extension pensée de microservices vers le navigateur après que Thoughtworks l'a mis en avant dans son Radar technologique de novembre 2016. Fowler a documenté ensuite sa progression de l'Assessment à l'essai et enfin à l'adoption, ce qui décrit le mouvement du modèle d'une technique émergente vers une option architecturale plus établie. Pour une vue d'ensemble plus large et pratique de la développement 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.
L'important 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 d'être gérée plus de contrats, d'actifs, de modes de failure runtime et d'outillage opérationnel.
Comment fonctionne l'architecture de Micro Frontend
Le coquillage et ses fragments
Un système fonctionnel commence généralement par un coquillage d'applicationégalement appelé conteneur ou orchestrateur. Le coquillage rend la disposition commune, établit la navigation, fournit le contexte d'authentification, et fournit des éléments d'interface partagés tels que la navigation ou les notifications. Il 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. Le shell 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'appuyer dessus. Le shell et chaque fragment ont besoin d'un contrat explicite couvrant le comportement de montage, la propriété de route, les états de chargement, la gestion des erreurs, les jetons de conception, les attentes d'accessibilité et les versions de dépendances prises en charge.
Règle pratique : Partager des contrats et des primitives visuels de manière délibérée. Ne partagez pas les détails d'implémentation en temps de cours que deux équipes utilisent actuellement le même framework.
La communication sans recréer le monolithe
Les fragments ont parfois besoin de communiquer. Une tranche de paiement peut avoir besoin de savoir que l'utilisateur est connecté, tandis qu'une tranche 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 de URL ou des services injectés.
Chaque 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 de l'URL Ils fonctionnent bien pour la navigation et l'état partageable, bien qu'ils ne soient pas adaptés à chaque interaction.
- Fournir des services injectés Fournissent des capacités contrôlées, mais le shell doit maintenir ces contrats de service.
Le shell devrait coordonner uniquement ce qui appartient à l'application entière. Si il devient responsable de l'état et des règles commerciales de chaque fragment, il est devenu un monolithe distribué avec un processus de déploiement plus complexe.
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 la fédération de modules S'est avérée être une option d'orchestration pour les équipes qui veulent une inscription d'application basée sur le cycle de vie.
Par exemple, l'équipe de paiement peut corriger le flux de paiement sans recompiler le fragment du catalogue. L'équipe du catalogue peut continuer sur un rythme de déploiement plus lent car le shell charge chaque morceau approuvé selon 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 dépôts et les frameworks ne fournissent pas seuls une composition fiable.
Comparaison des modèles de micro front-end de base
Pas de mécanisme d'intégration unique résout tous les problèmes de micro front-end. Choisissez en comparant l'isolement, la communication, le partage de dépendances, le comportement du navigateur et la propriété d'exploitation plutôt que de sélectionner l'outil le plus à la mode.
| Modèle | Isolement | Modèle d'intégration | Partage de dépendances | Performances | Meilleur ajustement |
|---|---|---|---|---|---|
| Iframes | Un processus et une isolation documentaire solides | Un document intégré avec messagerie transversale entre les cadres | Par défaut, aucun | Peut ajouter un surcoût de chargement et de communication | Expériences non fiables, légendaires ou fortement isolées |
| Composants Web | Éléments encapsulés et, lorsqu'ils sont utilisés, stylage Shadow DOM | Éléments personnalisés montés par le shell | Jetons de conception partagés et API du navigateur | Souvent prévisibles, mais cela dépend de la charge du composant | Équipes axées sur les normes nécessitant de la flexibilité de cadre |
| Fédération de modules | Isolement de runtime modéré | Modules distants chargés et montés en temps de exécution | Dépendances explicitement négociées ou regroupées | Efficient lors du chargement et de la déduplication contrôlés | Applications étroitement intégrées avec des versions independents |
| single-spa | Un modèle de limites d'orchestration plutôt qu'un modèle d'isolement complet | Applications enregistrées à travers des appels 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 la limite la plus forte dans cette comparaison. L'application intégrée a son propre document, styles et 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é.
Ce niveau d'isolement 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 les normes du navigateur plutôt que de faire adopter à chaque équipe 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 une flexibilité de framework sans faire charger le navigateur tout le runtime d'application pour chaque morceau. Cela ne résout pas automatiquement la taille des dépendances, la communication d'é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 modules
La fédération de modules, introduite avec Webpack 5 et supportée par des outils comme Vite et Rspack, charge les modules compilés à partir d'entrées distantes en temps de exécution. Elle 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 fournit un contexte utile pour séparer l'indépendance de déploiement de la simple décomposition code.
single-spa
single-spa agit comme un orchestrateur indépendant des frameworks. Les équipes enregistrent les applications et les appels de cycle de vie, puis la configuration racine active les applications en fonction des 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 performances ou de contrôles de sécurité.
Les équipes peuvent combiner ces mécanismes. Par exemple, une racine 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 Compensations et Risques cachés
Frontends micro
| Avantage | Compensation / Risque caché | L'autonomie de l'équipe |
|---|---|---|
| Les équipes possèdent une partie commerciale de bout en bout | Les équipes doivent maintenir des pipelines séparés, une responsabilité de permanence et une discipline de mise en production | Déploiement |
| Un fragment peut être déployé sans reconstruire l'interface complète | Dimension | Les versions deviennent non atomiques, de sorte que des versions incompatibles peuvent se rencontrer en production |
| Isolation de l'échec | Un serveur distant échoué peut être contenu avec un fallback | Les limites d'erreur médiocres peuvent toujours rendre la navigation ou les parcours critiques inutilisables |
| Performances | context : Page/zone : Section ou page d'accueil problème/solution. Rôle : En-tête de section ou de page. Vu dans : page premium-support.astro. Message clé `ps_help_performance_title` (Ps Help Performance Title). | More requests, duplicated framework code, and remote initialization can hurt runtime performance |
| Plus de requêtes, du framework dupliqué __CAPGO_KEEP_0__ et d'initialisation de serveur distant peuvent nuire aux performances en temps de cours | Choix de technologie | Les équipes peuvent utiliser différents frameworks où les limites le permettent |
| La débogage, l'accessibilité, la cohérence de la conception et la recherche de personnel deviennent plus difficiles dans un mélange de stack | Sécurité : Page/zone : Page produit/prix entreprise. Rôle : Étiquette UI. Vu dans : page enterprise.astro. Message clé `enterprise_hero_security_label` (Enterprise Hero Security Label). | Le shell peut exécuter des code à distance qu'il n'a pas vérifiés de manière suffisante |
| Gouvernance | Les normes partagées peuvent préserver un produit cohérent | Les systèmes de conception, les règles de dépendance, les contrats et le support de plateforme nécessitent une coordination continue |
Le facture de performance
Les tranches independantes 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 bundle, le chargement à distance, l'initialisation et les erreurs visibles pour l'utilisateur. Ensuite, fixez des budgets pour le shell et chaque tranche à haute circulation. Le chargement différé n'aide que si l'application ne bloque pas le parcours critique sur une chaîne longue de modules à distance.
Sécurité aux joints
Un module à distance n'est pas automatiquement sûr parce qu'il a un dépôt séparé. Le shell peut exécuter des code qu'il n'a pas vérifiés, et une limite de frontend n'annule pas l'autorisation aux API ou aux services de jeton. Analyse de micro frontend axée sur la sécurité met en évidence pourquoi la confiance, la signature, les vérifications d'intégrité et l'autorisation nécessitent une attention de conception avant que les équipes distribuent des code de runtime.
Le décalage de version crée une autre classe de risque. Une fraction peut fonctionner seule mais échouer lorsqu'elle rencontre une version de shell différente, une bibliothèque partagée, un ensemble de jetons de conception ou un flux d'événement. La guidance d'architecture de Nx identifie la coordination, la configuration de l'environnement, l'efficacité de l'application et la réutilisabilité comme défis qui persistent.
La structure d'architecture n'efface pas la coordination. Elle change la coordination des réunions de lancement en 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 coquillage 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 rendu, les règles commerciales, le comportement du clavier, les états de chargement et les erreurs locales sans nécessiter le coquillage complet.
Les tests de contrat se trouvent au-dessus d'eux. Ils vérifient l'interface entre le coquillage 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.
Intégration de l'interface de shell puis chargement d'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 navigation d'un produit, la connexion et la finalisation du paiement à travers plusieurs tranches livrées indépendamment.
Contrôler la surface de mise à jour
Utilisez des manifestes versionnés afin que l'interface de shell puisse identifier l'artefact de fragment exact qu'elle charge. Un manifeste donne également aux opérateurs un endroit pour fixer une version connue-bonne lorsque la mise à jour distante provoque 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 des identificateurs de mise à jour aux journaux, aux traces et aux erreurs du client afin que l'équipe responsable puisse identifier le fragment en cause.
- Les chemins de reversion : Maintenez l'artifact 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 exécution locale réussie ne prouve pas que le chemin de livraison de contenu, le 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 type 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 artifact, 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 annuler ce morceau sans demander à l'ensemble de l'organisation de coordonner une mise à jour.
Utilisation de Micro Frontends dans Capacitor et Electron
A Capacitor ou une application Electron ajoute une autre coquille autour de la coquille de navigateur. Capacitor place des web code à l'intérieur d'une vue native mobile WebView, tandis qu'Electron exécute des web code dans un processus de rendu de bureau.
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.
Actualisations en direct et reversion
Un système d'actualisation en direct doit traiter les artefacts de l'interface comme du logiciel susceptible d'être mis à jour. Il doit livrer des paquets signésles vérifier avant activation, proposer des canaux de mise à jour pour des déploiements étalés, appliquer les mises à jour à la prochaine lancement plutôt que d'interrompre une session active, et fournir une protection de reversion automatique avec réversion atomique.
Ces contrôles s'appliquent naturellement à la livraison de l'interface de micro-frontend. 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 le paquet complet est disponible. Si la prochaine lancement détecte une erreur, l'actualiseur peut revenir à l'état connu-good précédent plutôt que de laisser les utilisateurs avec une interface partiellement mise à jour.
Capgo est une option pour ce modèle de livraison. Sa plateforme d'actualisation 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 route, et fournit des journaux, une histoire de versions, des métriques d'adoption et de failure, une protection de rollback, des intégrations CI/CD, et un API. how Capacitor connects web and native code.
Un diagramme illustrant comment utiliser les micro frontends avec __CAPGO_KEEP_0__ ou les coques d'applications natives Electron.
Quels changements dans une coque native
- La coque native 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, donc la coque a 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. Remote code must be authenticated, integrity-checked, and authorized for the application context.
- Le __CAPGO_KEEP_0__ distant doit être authentifié, vérifié par intégrité et autorisé pour le contexte d'application. 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 un flux de paiement ou 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 légataires 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 l'ensemble de construction unique ne peut pas accommoder proprement.
Évitez-le lorsque l'é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 tests 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 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 pour l'utilisateur : La division améliorera-t-elle 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 frontières sont un outil pour l'indépendance organisationnelle et de mise en production, pas une amélioration automatique de la qualité de la frontière. 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 frontières gérée avec soin peut donner aux équipes l'autonomie dont elles ont besoin.
Si vous évaluez les micro frontières 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 mise en route, 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.
