Fermer

mai 8, 2022

5 pièges de l’utilisation des micro-interfaces et comment les éviter


J’ai récemment écrit sur cinq raisons pour lesquelles il vaut la peine d’adopter une architecture micro-frontend. Bien sûr, il y a du pour et du contre à tout. Les micro-interfaces sont une nouvelle approche architecturale et sont susceptibles de représenter l’avenir du développement Web. En même temps, ils comportent quelques pièges, et il est essentiel de les connaître pour pouvoir les résoudre ou les éviter complètement.

Dans cet article, vous apprendrez les leçons les plus importantes que mon équipe et moi avons apprises en utilisant des micro-interfaces. Sur une période de deux ans, nous avons identifié de nombreux problèmes avec cette architecture et commis autant d’erreurs. Il est donc temps de les partager pour vous aider à les combattre ou à les éviter.

Rappelons d’abord ce qu’est l’architecture micro frontale, puis plongeons dans leurs pièges et comment éviter chacun d’eux.

Les micro-interfaces en bref

Martin Fowler définit l’approche micro frontale du développement comme :

un style architectural où les applications frontales livrables indépendamment sont composées dans un ensemble plus vaste.

Lorsqu’il est appliqué au développement Web, cela 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’opportunité de profiter de tous ses avantages, tels que l’évolutivité, l’indépendance technologique et la maintenabilité. En revanche, sur le long terme, nous avons remarqué 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 non seulement appris les avantages des micro-interfaces, mais également leurs principaux inconvénients. Examinons-les maintenant et voyons ce que nous aurions dû faire pour les éviter ou les résoudre.

1. Dépendances redondantes

Chaque micro application frontale est indépendante des autres par définition. En d’autres termes, une architecture micro-frontend implique plus d’une application frontale qui devrait pouvoir fonctionner également sans les autres. Pour permettre cela, chacun d’eux a ses propres dépendances. Donc, en regardant dans l’ensemble, vous perdez les avantages d’utiliser un gestionnaire de packages. En fait, votre application entière sera probablement composée de plusieurs versions des mêmes bibliothèques, dispersées sur les micro-interfaces.

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 incombe aux utilisateurs finaux, qui sont obligés de télécharger plus de données. De plus, cela impacte le temps de rendu et par conséquent la Google Web Vitals scores, affectant également le référencement de votre site Web.

Comment résoudre ce problème

Une solution possible comporte trois étapes. Tout d’abord, identifiez l’ensemble des bibliothèques communes à tous les micro-frontends. Deuxièmement, créez une micro interface contenant toutes les bibliothèques partagées. Ensuite, mettez à jour vos micro-interfaces pour que leur package intégré importe les bibliothèques requises à partir de ce projet partagé.

Comme décrit dans l’original de Martin Fowler article de blog d’où vient cette idée, le partage de dépendances entre applications présente de nombreux obstacles et ne peut être considéré comme une tâche facile à accomplir. Alors gardez cela à l’esprit lorsque vous essayez d’atteindre cet objectif.

2. Styles conflictuels et qui se chevauchent

Encore une fois, la technologie et l’indépendance de l’équipe sont excellentes, mais cela peut également introduire certains problèmes. Cela est particulièrement vrai lorsqu’il s’agit de style. En fait, chaque micro frontal ne peut pas avoir son propre style d’un point de vue commercial. En effet, vous ne voulez certainement pas que vos applications aient l’air composées de nombreux correctifs. Tout doit être cohérent, à la fois en termes de style, d’interface utilisateur et d’UX.

Un autre problème découlant du fait que plusieurs interfaces font partie de la même application est que vous pouvez vous retrouver avec des remplacements de règles CSS involontaires. Les chevauchements indésirables en termes de CSS deviennent courants lorsqu’il s’agit de micro-interfaces, et vous pouvez les découvrir après avoir déployé votre application. La raison en est que chaque équipe ne travaille généralement que sur sa propre application et n’a pas une vue d’ensemble avant un déploiement.

Ces problèmes peuvent affecter négativement la réputation de votre marque. De plus, les utilisateurs finaux paieront le prix de ces incohérences, notamment en termes d’interface utilisateur.

Comment résoudre ce problème

La seule solution possible en matière d’UI et d’UX est de s’assurer que chaque équipe parle à l’autre et a le même résultat en tête. En outre, l’ajout de composants de style dans le projet de micro-frontend partagé susmentionné pourrait aider ici. Néanmoins, cela rendrait chaque application micro frontale dépendante de cela, et cela casse 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 souhaitez éviter les chevauchements CSS, une solution consiste à ajouter un ID au conteneur frontal <div>. Ensuite, configurez webpack pour insérer cet ID avant chaque règle CSS. Sinon, vous pourriez décider d’adopter une méthodologie CSS telle que BEM (Block-Element-Modifier). Cela vous encourage à considérer un site Web comme une collection de blocs de composants réutilisables, dont le nom de classe doit être unique dans votre projet. Lis Présentation de BEM pour en savoir plus sur le fonctionnement de ce système.

3. Mauvaises performances

Avoir plus d’une application frontale JavaScript en cours d’exécution sur la même page ralentira par conséquent l’ensemble de l’application. En effet, chaque instance de framework nécessite des ressources en termes de CPU, de RAM et de bande passante réseau.

Gardez également à l’esprit que lorsque vous testez votre micro-interface isolée des autres, vous ne le remarquerez peut-être pas. Les problèmes commencent lorsque plusieurs instances d’un framework s’exécutent en même temps. En effet, s’ils sont exécutés indépendamment, ils n’ont pas à partager les ressources de la machine sous-jacente comme ils le devront lors du déploiement.

Comment résoudre ce problème

Une idée pour résoudre ce problème est de renforcer la communication d’équipe pour éviter de refaire les mêmes appels et élaborations. Ensuite, stockez leur résultat dans un endroit auquel chaque micro interface a accès, ou permettez-leur 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 plus, en ce qui concerne les performances, vous devez tester l’application avec toutes ses micro-interfaces, et ne vous fiez pas uniquement aux tests effectués sur chaque micro-interface.

4. Communication entre les interfaces

Au départ, vous n’aurez pas besoin de faire communiquer vos micro-interfaces, 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-frontal concerne l’indépendance, cela s’oppose à la communication.

Lorsque l’application dans son ensemble se développe, rendre vos micro-interfaces capables de communiquer sans effort les unes avec les autres est susceptible de devenir une priorité. Surtout si vous voulez répéter sans cesse les mêmes opérations, surtout si elles ne sont pas idempotentes.

De plus, la communication est nécessaire pour obtenir des performances plus élevées, comme expliqué ci-dessus. Par exemple, vous ne voulez pas que votre application fasse deux fois le même appel d’API pour récupérer les mêmes données et ralentir inutilement votre serveur.

Comment résoudre ce problème

La solution consiste à implémenter une couche de messagerie personnalisée basée sur un état partagé stocké dans un cookie ou stockage local, ou sur des événements personnalisés. Comme vous pouvez l’imaginer, la mise en œuvre a un coût et peut rapidement devenir complexe et lourde à gérer. Tenez également 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 davantage 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 différentes bases de code signifie qu’il devient plus difficile de trouver des fonctionnalités, des fonctions et des utilitaires réutilisables. C’est mauvais en termes de découvrabilité du code et donc de réutilisabilité. En d’autres termes, vous pouvez facilement vous retrouver avec des implémentations en double des mêmes composants sur différents micro-frontends.

Comment résoudre ce problème

La solution est de soutenir une logique de communication entre les équipes dès le départ. Comme mentionné ci-dessus, cela implique d’avoir un projet avec des ressources réutilisables pour chaque technologie adoptée. Mais avoir un tel projet sans le tenir à jour le rendrait inutile.

Ainsi, vous devez autoriser chaque équipe à y ajouter des composants et des bibliothèques. De plus, avoir une équipe dédiée à cela pourrait faciliter l’ensemble du processus. En fait, il peut être difficile pour une équipe indépendante et isolée de comprendre quels éléments seront partagés par plus d’un micro frontal.

De plus, ne considérez pas l’indépendance technologique comme plusieurs équipes isolées. Au contraire, avoir des équipes qui se parlent et se tiennent au courant est essentiel pour la réussite du projet. Ainsi, favoriser une culture de la communication doit être 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, soutenus par l’expérience accumulée par mon équipe en travaillant quotidiennement avec elle pendant deux ans. Bien que l’approche micro frontale permette aux développeurs de diviser une application frontale en parties indépendantes plus petites, cela ne signifie pas que chaque équipe doit également être isolée. Au contraire, partager 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 voyage micro frontend. Mais nous avons beaucoup appris de cette aventure, et j’espère qu’elle a été utile pour partager les principales causes qui nous ont conduit à un échec et comment les éviter ou les contrer.

Merci d’avoir lu! Ne hésitez pas à tendre la main vers moi pour toute question, commentaire ou suggestion.






Source link