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.

Gérer les dépendances pour des préoccupations transversales

La gestion consciente des dépendances est essentielle au succès d'une architecture distribuée telle que les micro-frontends. La gestion des dépendances est l'un des aspects les plus difficiles du développement du micro-frontend.

Dans une architecture micro-frontend, deux aspects importants de la gestion des dépendances sont la baisse de performance liée au transfert d'artefacts de code volumineux vers le client et la surcharge des ressources de calcul. Idéalement, votre organisation doit définir la manière dont les dépendances sont maintenues dans une architecture frontale distribuée.

Trois stratégies viables pour imposer la maintenance des dépendances sont Share Nothing, en utilisant des standards Web tels que l'importation de cartes et la fédération de modules. D'autres approches sont des anti-modèles car elles violent les principes de base des architectures distribuées.

Ne partagez rien, dans la mesure du possible

L'approche « ne rien partager » postule qu'aucune dépendance entre des artefacts logiciels indépendants ne doit être partagée, ou du moins pas lors de l'intégration ou de l'exécution. Cela signifie que si deux micro-frontends dépendent de la même bibliothèque, chacune doit être intégrée à la bibliothèque au moment de la construction et expédiée séparément. De plus, chaque micro-frontend doit valider que la bibliothèque ne pollue pas les espaces de noms globaux et les ressources partagées.

Cela entraîne des licenciements, mais il s'agit d'un compromis délibéré avec une agilité maximale. En l'absence de dépendances d'exécution partagées, les équipes disposent d'une flexibilité maximale pour faire évoluer le logiciel de la manière qu'elles jugent utile, à condition de le faire dans le cadre de leur solution et de ne rompre aucun contrat d'interface.

Sur une plate-forme où les micro-frontends suivent le principe de ne rien partager, il est important de garder les micro-frontends aussi légers que possible. Cela nécessite des développeurs compétents et assidus dans l'optimisation des performances de leurs micro-frontends et qui ne sacrifient pas l'expérience utilisateur au profit de l'expérience des développeurs.

Lorsque vous partagez du code

Lorsque vous décidez de partager du code, vous pouvez le partager sous forme de bibliothèques ou de modules d'exécution. Par exemple, l'équipe principale du frontend fournit des bibliothèques destinées à être consommées par le biais du micro-frontend. CDNs Les équipes chargées de la valeur commerciale peuvent charger les bibliothèques au moment de l'exécution ou utiliser des référentiels de packages pour publier leurs bibliothèques. Les équipes de micro-frontend peuvent développer sur une version spécifique de la bibliothèque packagée au moment de la création, de la même manière que les applications mobiles utilisant des frameworks hybrides.

Une troisième option consiste à utiliser un registre de paquets privé pour prendre en charge l'intégration des bibliothèques communes au moment de la création. Cela réduit le risque qu'une modification définitive du contrat de bibliothèque entraîne des erreurs lors de l'exécution. Cependant, cette approche plus conservatrice nécessite une plus grande gouvernance pour synchroniser tous les micro-frontends avec les nouvelles versions de bibliothèque.

Pour améliorer les temps de chargement des pages, les micro-frontends peuvent externaliser les dépendances de bibliothèque à charger à partir de fragments mis en cache à partir d'un CDN tel qu'Amazon. CloudFront

Pour gérer les dépendances d'exécution, les micro-frontends peuvent utiliser des cartes d'importation (ou des bibliothèques telles queSystem.js) pour spécifier l'endroit d'où chaque module est chargé au moment de l'exécution. La fédération de modules webpack est une autre approche qui permet de pointer vers une version hébergée d'un module distant et de résoudre les dépendances communes entre les micro-frontends indépendants.

Une autre approche consiste à faciliter le chargement dynamique des cartes d'importation avec une demande initiale adressée à un point de terminaison de découverte.

État partagé

Pour réduire le couplage des micro-frontends, il est important d'éviter une gestion globale des états accessible depuis tous les micro-frontends dans une même vue, comme dans le cas des architectures monolithiques. Par exemple, le fait de disposer d'un magasin Redux mondial accessible depuis tous les micro-frontends augmente le couplage.

Un modèle pour éliminer l'état partagé consiste à l'encapsuler dans des micro-frontends et à communiquer avec des messages asynchrones, comme indiqué précédemment.

Lorsque cela est absolument nécessaire, introduisez des interfaces bien définies pour l'état global et optez pour le partage en lecture seule afin d'éviter tout comportement inattendu :

Si vous devez partager plusieurs informations entre des micro-frontends, nous vous recommandons de revoir les limites des micro-frontends. Le besoin de partager peut être dû à l'évolution de l'entreprise ou à une conception initiale médiocre.

Il est également possible d'utiliser des sessions côté serveur, où chaque micro-frontend récupère les données requises à l'aide d'un identifiant de session. Pour réduire le couplage, il est important d'éliminer l'état partagé et de séparer les données de session spécifiques au micro-frontend.