Vous avez tout à fait raison de dire qu'il y a un compromis à faire ici: vous échangez certains aspects de l'expérience utilisateur pour obtenir une meilleure expérience de développeur (ce qui pourrait à son tour améliorer l'expérience utilisateur de différentes manières). Est-ce que cela en vaut la peine? Ça dépend.
Par exemple, je pense que Spotify utilise cette approche pour diviser leur interface utilisateur en composants isolés ( source ). Chaque widget vit dans un iframe et peut donc avoir son propre ensemble de bibliothèques, etc. Ils ont la contrainte organisationnelle unique que le travail est effectué par des escouades autonomes (une équipe interfonctionnelle). Il est donc plus difficile de s'entendre sur des normes à l'échelle de l'entreprise et de modifier ces normes ultérieurement. Ainsi, pour eux, les micro-frontends contribuent à préserver une certaine flexibilité. Mais sans cette approche, leur application de bureau serait peut-être moins un porc de mémoire.
La mise en cache HTTP ne va pas beaucoup aider: chaque micro-interface peut utiliser des versions de framework différentes . De plus, le coût de la duplication n'est pas seulement le transfert de données, mais les coûts côté client de la (re) compilation des bibliothèques et du stockage des structures de données dupliquées.
Personnellement, je pense que de tels micro-frontends peuvent être une architecture valide mais sont probablement déconseillés à moins que
- vous êtes une très grande organisation avec des équipes hautement autonomes qui travaillent toutes sur l'interface utilisateur et doivent faire des versions très fréquentes (par exemple quotidiennement) et
- votre budget de performances UX a de la place pour cette duplication, ou votre produit est si bon que l'UX n'a pas d'importance. Notez que les performances doivent être testées sur des appareils bas de gamme, pas sur votre machine de développement.
Si votre organisation n'est pas énorme ou si vos équipes sont un peu plus spécialisées, il pourrait être plus facile pour toutes les personnes impliquées (gestion, développeurs et, finalement, utilisateurs) d'avoir un processus de construction et de déploiement commun qui évite les doublons inutiles. Par exemple, si vous n'avez que 4 équipes travaillant sur l'interface utilisateur, elles peuvent probablement se parler pour convenir d'un ensemble commun de bibliothèques et comment intégrer leur travail dans une architecture cohérente.
Les micro-frontends semblent être l'une de ces choses qui sont vraiment cool mais dont vous n'avez pas vraiment besoin jusqu'à ce que vous fonctionniez à l'échelle.