Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Découverte de service
Le modèle de découverte du frontend améliore l'expérience de développement lors du développement, du test et de la fourniture de micro-frontends. Le modèle utilise une configuration partageable qui décrit le point d'entrée des micro-frontends. La configuration partageable inclut également des métadonnées supplémentaires qui sont utilisées pour des déploiements sécurisés dans chaque environnement à l'aide des versions de Canary.
Le développement de frontend modernes implique l'utilisation d'une grande variété d'outils et de bibliothèques pour prendre en charge la modularité pendant le développement. Traditionnellement, ce processus consistait à regrouper le code dans des fichiers individuels pouvant être hébergés sur un CDN dans le but de minimiser les appels réseau pendant l'exécution, y compris le chargement initial (lorsqu'une application s'ouvre dans un navigateur) et l'utilisation (lorsqu'un client effectue des actions telles que le choix de boutons ou l'insertion d'informations).
Séparer des lots
Les architectures micro-frontend résolvent les problèmes de performance causés par les très grands ensembles générés par le regroupement individuel d'un grand nombre de fonctionnalités. Par exemple, un très gros site Web de commerce électronique peut être regroupé dans un JavaScript fichier de 6 Mo. Malgré la compression, la taille de ce fichier peut avoir un impact négatif sur l'expérience utilisateur lors du chargement de l'application et du téléchargement du fichier à partir d'un CDN optimisé pour les périphériques.
Si vous divisez l'application en page d'accueil, en détails sur le produit et en micro-frontends de panier, vous pouvez utiliser un mécanisme de regroupement pour produire trois offres groupées individuelles de 2 Mo. Cette modification peut améliorer les performances lors du premier chargement de 300 % lorsque les utilisateurs consultent la page d'accueil. Les packs de micro-frontends du produit ou du panier sont chargés de manière asynchrone uniquement si et lorsque l'utilisateur visite la page produit d'un article et décide de l'acheter.
De nombreux frameworks et bibliothèques sont disponibles sur la base de cette approche, qui présente des avantages tant pour les clients que pour les développeurs. Pour identifier les limites commerciales susceptibles de découpler les dépendances dans le code, vous pouvez mapper différentes fonctions commerciales à plusieurs équipes. La propriété distribuée apporte indépendance et agilité.
Lorsque vous divisez des packages de construction, vous pouvez utiliser une configuration pour cartographier les micro-frontends et piloter l'orchestration pour le chargement initial et pour la navigation après le chargement. Ensuite, la configuration peut être utilisée pendant l'exécution plutôt que pendant la construction. Par exemple, le code frontal côté client ou le code principal côté serveur peut effectuer un appel réseau initial à une API pour récupérer dynamiquement la liste des micro-frontends. Il récupère également les métadonnées nécessaires à la composition et à l'intégration. Vous pouvez configurer des stratégies de basculement et de mise en cache pour des raisons de fiabilité et de performance. Le mappage des micro-frontends permet de rendre les déploiements individuels de micro-frontends détectables par des micro-frontends précédemment déployés et orchestrés par une application shell.
Versions de Canary
Une version Canary est un modèle bien établi et populaire pour le déploiement de microservices. Les versions de Canary répartissent les utilisateurs cibles d'une version en plusieurs groupes et publient les modifications progressivement, au lieu de les remplacer immédiatement (également connu sous le nom de déploiement bleu/vert). Un exemple de stratégie de publication de Canary consiste à appliquer une nouvelle modification à 10 % des utilisateurs cibles et à en ajouter 10 % par minute, avec une durée totale de 10 minutes pour atteindre 100 %.
L'objectif d'une version de Canary est d'obtenir un feedback précoce sur les modifications, en surveillant le système afin de réduire l'impact des éventuels problèmes. Lorsque l'automatisation est en place, les indicateurs de l'entreprise ou du système peuvent être surveillés par un système interne qui peut arrêter le déploiement ou démarrer une restauration.
Par exemple, une modification peut introduire un bogue qui, dans les premières minutes d'une publication, entraîne une perte de revenus ou une dégradation des performances. La surveillance automatisée peut déclencher une alarme. Grâce au modèle de découverte de services, cette alarme peut arrêter le déploiement et revenir en arrière immédiatement, affectant seulement 20 % des utilisateurs au lieu de 100 %. L'entreprise bénéficie de la réduction de l'ampleur du problème.
Pour un exemple d'architecture qui utilise DynamoDB comme stockage pour implémenter une API d'administration REST, consultez la solution Frontend Service Discovery on AWS sur
