5 pièges de l’utilisation des micro-frontaux et comment les éviter
J’ai récemment écrit sur les cinq raisons pour lesquelles il vaut la peine d’adopter une architecture micro frontend. Bien sûr, il y a des avantages et des inconvénients à tout. Les micro-frontends constituent une approche architecturale nouvelle, et sont susceptibles de représenter l’avenir du développement Web. En même temps, ils s’accompagnent de quelques pièges, et il est essentiel de les connaître pour pouvoir les aborder ou les éviter complètement.
Dans cet article, vous découvrirez les leçons les plus importantes que mon équipe et moi-même avons apprises en utilisant les micro-frontends. Sur une période de deux ans, nous avons identifié de nombreux problèmes avec cette architecture et fait tout autant d’erreurs. Il est donc temps de les partager pour vous aider à les aborder ou à les éviter.
Rappelons d’abord ce qu’est l’architecture micro frontend, puis plongeons dans leurs pièges et comment éviter chacun d’entre eux.
Les micro-frontaux en quelques mots
Martin Fowler définit l’approche micro frontend du développement comme étant
un style architectural où des applications frontales livrables indépendamment sont composées en un tout plus grand.
Lorsqu’elle est appliquée au développement Web, elle implique d’avoir de nombreuses petites applications frontales indépendantes faisant partie du même site Web ou de la même application Web. Comme déjà mentionné ici, mon équipe avait utilisé cette approche avec succès. En particulier, nous avons eu l’occasion de profiter de tous ses avantages, tels que l’évolutivité, l’indépendance technologique et la maintenabilité. D’un autre côté, sur le long terme, nous avons constaté de sérieux problèmes. Nous avons donc décidé d’abandonner cette approche architecturale pour revenir à une architecture monolithique plus traditionnelle.
Cela signifie que nous avons appris non seulement les bons côtés des micro-frontends, mais aussi leurs inconvénients majeurs. Plongeons maintenant dans ces derniers et voyons ce que nous aurions dû faire pour les éviter ou les résoudre.
1. Dépendances redondantes
Par définition, chaque application micro frontend est indépendante des autres. En d’autres termes, une architecture micro-frontend implique plus d’une application frontale qui doit pouvoir fonctionner également sans les autres. Pour permettre cela, chacune d’entre elles a ses propres dépendances. Ainsi, en regardant l’ensemble, vous perdez les avantages de l’utilisation d’un gestionnaire de paquets. En fait, votre application entière sera probablement constituée de nombreuses versions des mêmes bibliothèques, dispersées dans les micro-frontends.
C’est sans aucun doute un problème, car cela rend votre application Web inutilement plus grande que ne le serait son homologue monolithique. Cela retombe sur les utilisateurs finaux, qui sont obligés de télécharger plus de données. De plus, cela a un impact sur le temps de rendu et par conséquent sur les scores Google Web Vitals, ce qui affecte également le référencement de votre site Web.
Comment résoudre ce problème
Une solution possible comporte trois étapes. Premièrement, identifiez l’ensemble des bibliothèques communes à tous les micro-frontaux. Deuxièmement, créez un micro-frontend contenant toutes les bibliothèques communes. Ensuite, mettez à jour vos micro-frontaux pour que leur paquetage construit importe les bibliothèques requises de ce projet partagé.
Comme décrit dans l’article de blog original de Martin Fowler dont cette idée est issue, le partage des dépendances entre applications présente de nombreux obstacles et ne peut être considéré comme une tâche facile à accomplir. Gardez donc cela à l’esprit lorsque vous essayez d’atteindre cet objectif.
2. Styles contradictoires et chevauchement
Encore une fois, l’indépendance des technologies et des équipes est formidable, mais elle peut aussi introduire certains problèmes. C’est particulièrement vrai lorsqu’il s’agit de style. En fait, chaque micro-frontend ne peut pas avoir son propre style d’un point de vue commercial. En effet, vous ne voulez absolument pas que vos applications aient l’air composées de nombreux patchs. Tout doit paraître cohérent, que ce soit en termes de style, d’interface utilisateur ou d’expérience utilisateur.
Un autre problème découlant du fait que plusieurs frontaux font partie de la même application est que vous pouvez vous retrouver avec des chevauchements involontaires de règles CSS. Les chevauchements non désirés en termes de CSS deviennent courants lorsqu’on a affaire à des micro-frontaux, et vous pouvez les découvrir après avoir seulement déployé votre application. La raison en est que chaque équipe travaille généralement uniquement sur sa propre application, et ne voit pas l’ensemble du tableau avant un déploiement.
Ces problèmes peuvent nuire à la réputation de votre marque. En outre, les utilisateurs finaux paieront le prix de ces incohérences, notamment en termes d’interface utilisateur.
Comment y remédier
La seule solution possible en matière d’IU et d’UX est de s’assurer que chaque équipe se parle et a le même résultat en tête. L’ajout de composants stylisés dans le projet de micro frontend partagé susmentionné pourrait également être utile. Néanmoins, cela rendrait chaque application micro frontend dépendante de cela, et cela rompt l’indépendance sous-jacente en conséquence. Mais au moins, cela empêchera votre application dans son ensemble de paraître hétérogène.
Si vous voulez éviter le chevauchement CSS, une solution consiste à ajouter un ID au conteneur du frontend
3. Performances médiocres
Le fait d’avoir plus d’une application JavaScript frontale fonctionnant sur la même page aura pour conséquence de ralentir l’ensemble de l’application. Cela est dû au fait que chaque instance du framework requiert des ressources en termes de CPU, de RAM et de bande passante réseau.
Gardez également à l’esprit que lorsque vous testez votre micro frontend isolé des autres, vous pouvez ne pas le remarquer. Les problèmes commencent lorsque plus d’une instance d’un framework est exécutée en même temps. En effet, si elles sont exécutées indépendamment, elles n’ont pas à partager les ressources de la machine sous-jacente comme elles devront le faire lors du déploiement.
Comment résoudre ce problème
Une idée pour résoudre ce problème est de renforcer la communication de l’équipe pour éviter de faire les mêmes appels et élaborations. Ensuite, stocker leur résultat dans un endroit auquel chaque micro frontend a accès, ou leur permettre de communiquer avant d’effectuer une opération lourde pour vérifier si les mêmes données ont déjà été récupérées ou générées auparavant.
De même, en ce qui concerne les performances, vous devez tester l’application avec tous ses micro frontends, et ne pas vous fier aux tests effectués sur chaque micro frontend seul.
4. Communication entre les frontends
Au départ, vous n’aurez pas besoin de faire communiquer vos micro-frontends, sauf dans de rares cas. Cela pourrait vous faire croire qu’il en sera toujours ainsi. De plus, bien que le modèle architectural micro frontend concerne l’indépendance, celle-ci s’oppose à la communication.
Lorsque l’application dans son ensemble se développe, faire en sorte que vos micro-frontends puissent communiquer sans effort les uns avec les autres est susceptible de devenir une priorité. Surtout si vous voulez continuer à répéter les mêmes opérations encore et encore, surtout si elles ne sont pas idempotentes.
En outre, la communication est nécessaire pour atteindre des performances plus élevées, comme expliqué ci-dessus. Par exemple, vous ne voulez pas que votre application effectue deux fois le même appel API pour récupérer les mêmes données et ralentisse inutilement votre serveur.
Comment résoudre ce problème
La solution consiste à mettre en œuvre une couche de messagerie personnalisée basée sur un état partagé stocké dans un cookie ou un localStorage, ou sur des événements définis par l’utilisateur. Comme vous pouvez l’imaginer, cette mise en œuvre a un coût et peut rapidement devenir complexe et lourde à gérer. De plus, tenez compte du fait que la communication introduit des frais généraux. Vous devez donc être sûr que ce que vous construisez apportera de réels avantages, et ne ralentira pas encore plus votre application.
5. Problèmes de communication entre les équipes
La communication dans une grande équipe peut être un problème, mais rien n’est pire que la communication entre plusieurs équipes. En effet, le fait d’avoir plusieurs équipes travaillant sur des bases de code différentes signifie qu’il devient plus difficile de trouver des caractéristiques, des fonctions et des utilitaires réutilisables. C’est mauvais en termes de découvrabilité du code et donc de réutilisation. En d’autres termes, vous pouvez facilement vous retrouver avec des implémentations dupliquées des mêmes composants sur différents micro-frontaux.
Comment résoudre ce problème
La solution consiste à soutenir une logique de communication entre les équipes dès le début. Comme mentionné ci-dessus, cela implique d’avoir un projet unique avec des ressources réutilisables pour chaque technologie adoptée. Mais avoir un tel projet sans le tenir à jour le rendrait inutile.
Vous devez donc permettre à chaque équipe d’y ajouter des composants et des bibliothèques. De plus, le fait d’avoir une équipe dédiée à cette tâche pourrait faciliter l’ensemble du processus. En effet, il n’est peut-être pas facile pour une équipe indépendante et isolée de comprendre quels éléments seront partagés par plus d’un micro-frontend.
De plus, ne pensez pas à l’indépendance technologique comme à plusieurs équipes isolées. Au contraire, le fait que les équipes se parlent et se tiennent au courant est essentiel à la réussite du projet. Ainsi, favoriser une culture de la communication doit être l’un des éléments clés lors de l’adoption d’une architecture micro frontend.
Conclusion
Dans cet article, nous avons examiné les cinq plus grands pièges de l’approche architecturale micro frontend, étayés par l’expérience que mon équipe a accumulée en travaillant quotidiennement avec elle pendant deux ans. Bien que l’approche micro frontend permette aux développeurs de diviser une application frontend en petites parties indépendantes, cela ne signifie pas que chaque équipe doit également être isolée. Au contraire, le partage des solutions, des composants, des ressources et des connaissances est la clé du succès.
Malheureusement, nous ne le savions pas en tant qu’équipe. Ainsi, nous avons été contraints d’abandonner notre périple micro frontend. Mais nous avons beaucoup appris de cette aventure, et j’espère qu’il a été utile de partager les principales causes qui nous ont conduits à un échec et comment les éviter ou les contrer.
Merci de votre lecture ! N’hésitez pas à me contacter pour toute question, commentaire ou suggestion.
