Les microfrontends sont un style architectural relativement nouveau pour la construction d’applications web. Comme son nom l’indique, il s’agit d’une extension du modèle populaire des micro-services où la tranche verticale de fonctionnalité qu’un micro-service fournit est étendue jusqu’au front-end. L’application elle-même devient une composition de composants microfrontend vaguement couplés, le modèle promettant les mêmes avantages que les microservices (mises à niveau progressives, couplage lâche, etc.).
Les modèles de logiciels ne sont pas inventés isolément, les bons ont tendance à être émergents. La communauté du génie logiciel commence à s’intéresser à certaines solutions aux problèmes qu’elle rencontre, les « modèles » représentant ces solutions sous une forme condensée. La découverte (par opposition à l’invention) de modèles ne diminue pas leur importance et leur signification. Leur valeur réside dans leur capacité à saisir succinctement l’essence d’une solution à un ensemble de problèmes communs et, ce faisant, à nous donner un vocabulaire commun.
Chez Kilukru Média, nous construisons depuis de nombreuses années des applications frontend complexes, principalement pour les services applicatif. Récemment, j’ai « comparé mes notes » avec un certain nombre d’ingénieurs qui avaient travaillé sur ces applications pour voir si un modèle de microfrontend avait commencé à émerger. À ma grande surprise, ce n’est pas le cas !
Cet article de blogue pose la question suivante : pourquoi ?
Qu’est-ce que les microfrontends ?
Une architecture d’application web typique ressemble à ce qui suit :
Des services discrets (il peut s’agir d’un service de catalogue, d’un service de panier d’achats, d’un service de profil utilisateur) fournissant des API spécifiques à un domaine, qui sont utilisées pour créer l’application frontale. Chacun de ces services et le front-end ont leurs propres bases de code, pipelines de CI/CD et pratiques DevOps, et selon leur taille ou leur structure organisationnelle, peuvent être développés par leur propre équipe.
Avec les microfrontends, l’architecture devient la suivante :
Plutôt que de fournir des services fournissant des données qui sont consommées par l’application frontale, ils fournissent du « contenu » sous la forme de mini applications. Dans le contexte d’une plateforme de commerce électronique, plutôt que de disposer d’un service de panier d’achats qui fournit des méthodes API (par exemple, énumérer le contenu du panier, ajouter des articles, supprimer des articles), le modèle de microfrontend devrait permettre au service de panier d’achats de fournir le HTML et le JavaScript requis pour rendre et « exploiter » le panier d’achats. En conséquence, l’application frontale devient une agrégation de petites applications, qui sont les microfrontends.
La référence canonique de ce modèle se trouve sur le blogue de Martin Fowler, où ils décrivent les microfrontends comme :
Un style architectural dans lequel des applications frontales indépendantes sont composées en un ensemble plus grand
L’article décrit un certain nombre d’avantages clés de cette approche : – Mises à niveau progressives – la possibilité de faire évoluer une grande base de code sans avoir à la réécrire – Bases de code simples et découplées – la division d’une grande application en plus petits morceaux la rend plus facile à gérer – Déploiement indépendant – pour citer, « tout comme pour les microservices, la déployabilité indépendante des microfrontends est essentielle », ce qui réduit à son tour la portée de chaque déploiement et diminue les risques – Équipes autonomes – Le découplage des bases de code et des cycles de publication conduit à un plus grand niveau d’autonomie.
Il n’est pas surprenant que ces avantages s’appliquent également lorsque l’on discute des mérites d’une architecture de microservices.
La suite de l’article sur le site de Martin Fowler se poursuit par une discussion sur la mise en œuvre d’une architecture de Micro-frontend.
Les mises en œuvre du microfrontal varient
Un certain nombre d’entreprises ont partagé leur expérience de l’adoption de microfrontends, ce qui nous permet de mieux comprendre comment ce modèle peut être appliqué dans la pratique.
IKEA a été l’une des premières entreprises à écrire sur ce modèle, dans un article intitulé simplement « Microservice Websites« . Comme son nom l’indique, cet article est antérieur au terme « Micro-frontend ». Le défi auquel ils s’attaquaient était tout simplement « Comment pouvons-nous développer des sites web où les différentes parties des pages sont développées par des équipes différentes ». J’aime beaucoup la façon dont ils mettent soigneusement en évidence les « hypothèses et les contraintes » de leur activité spécifique, dans leur cas il s’agit d’un site web grand public ; le « temps d’interactivité » et les contraintes du navigateur du client sont donc tous deux très importants. En fin de compte, ils ont opté pour une approche qui utilise la transclusion côté service pour composer les parties constitutives de leur site web.
Spotify est largement considéré comme ayant adopté des microfrontends. Contrairement à IKEA, qui est un site web de magasinage, Spotify offre une expérience plus complexe et plus immersive de type application. En conséquence, il y a beaucoup plus d’interaction entre les différents composants microfrontend qui sont assemblés pour créer l’application. Pour ce faire, l’application utilise des iframes, avec un bus d’événements qui communique les événements et l’état entre ces composants.
Le DAZN est un autre fervent défenseur des microfrontends, qu’il utilise dans le cadre de ses services de streaming d’abonnements sportifs. Ils décrivent une approche dans laquelle un bootstrap léger est initialement chargé, suivi par le microfrontend nécessaire basé sur des informations de routage. L’application des DAZN ne charge qu’un seul microfrontend à la fois, de sorte qu’il n’est pas nécessaire de composer plusieurs composants frontaux côté client ou serveur.
Enfin, une autre source d’information notable est le site web Micro-frontends.org, créé par Michael Geers, l’auteur du livre « Micro-front ends in action ». L’approche décrite par ce site web est assez marquée par les opinions, par exemple en préconisant des composants agnostiques sur le plan technologique – sans code de cadre partagé. En pratique, cela vous permettrait de construire un composant dans Angular et un autre dans React.
De la composition côté serveur de composants qui ont relativement peu d’interaction côté client, en passant par la composition d’iframe jusqu’au montage d’un seul composant basé sur le routage, ces articles décrivent des architectures très différentes !
Pourquoi y a-t-il une telle variabilité ?
Au début, le Web était principalement utilisé comme un moyen de partager du contenu statique, une gigantesque bibliothèque de référence numérique. Cependant, à mesure que les navigateurs devenaient plus performants et puissants, les gens ont commencé à proposer des expériences plus interactives sur le web. Finalement, nous sommes arrivés au point où le web est le principal mécanisme de distribution pour pratiquement tout, du contenu statique aux applications commerciales immersives.
Les besoins technologiques d’un simple site web sont très différents de ceux d’une application web telle que décrite dans l’article d’Aral Balkan, le Document To Application Continuum.
À l’extrême gauche, nous avons des sites web statiques, le web des années 90, pour la plupart exempts de JavaScript, centrés sur le contenu, servant du texte et des images. En progressant de gauche à droite, les sites dynamiques ajoutent un peu d’interactivité côté client, avec moins d’allers-retours vers le serveur. En avançant vers la droite, nous rencontrons les applications web, des outils centrés sur le comportement, avec des milliers de lignes de JavaScript. C’est là que nous trouvons des modèles standard comme les « applications à page unique ».
À l’extrême droite se trouve un type d’application web que vous ne connaissez peut-être pas, le portail. On les trouve souvent au sein de grandes organisations comme les banques, où de multiples applications (plateforme de négociation, gestion des risques, outils opérationnels) sont hébergées sur la même plateforme web. Elles sont souvent présentées comme une app-store interne.
En considérant ce spectre, une autre observation intéressante est la mesure dans laquelle ces sites / applications nécessitent une communication intercomposants (ou dans le contexte des microfrontends, combien de communication est nécessaire entre chaque mini application). La communication entre les composants est faible pour les sites web interactifs (par exemple, le site d’achat IKEA), mais elle augmente à mesure que l’expérience s’apparente davantage à une application (Spotify). Il est intéressant de noter que ce chiffre diminue une fois de plus à l’extrémité Portail – la quantité de communication interapplications est modeste.
Les choix architecturaux faits par Spotify, DAZN, IKEA et d’autres sont très influencés par leur position sur ce spectre.
Les dangers des microfrontends
Jusqu’à présent, nous avons constaté que toutes les architectures de microfrontend ne sont pas les mêmes, et pourquoi. Cela suffit-il à remettre en question la validité de cette approche ? Je pense que oui, mais ce n’est pas tout !
À mon avis :
L’analogie avec les microservices est mal adaptée. Si les microservices et les microfrontends tirent tous deux profit de l’organisation d’équipes autour de capacités commerciales, il existe des différences notables. Les microfrontends, du fait qu’ils fonctionnent dans le navigateur, entraînent des coûts et des sacrifices différents si vous permettez aux équipes de choisir leur propre pile technologique ou de prendre en charge des pipelines de déploiement indépendants.
Les microservices sont dangereux. Dans le prolongement de ce qui précède, j’ai vu beaucoup trop de projets de microservices qui échouent. Dans presque tous les cas, cela est dû à la complexité inhérente à cette architecture : trop de microservices (souvent centrés sur une seule entité plutôt que sur un contexte limité), des défis liés à la découverte, l’infrastructure en tant que code, les pipelines de déploiement. Souvent, les gens font appel aux microservices simplement parce qu’ils pensent que c’est la bonne façon de construire des systèmes de nos jours. Les microfrontends ont des caractéristiques similaires aux microservices, ils apportent certains avantages, mais à un coût de complexité élevé.
Les modèles sont vagues et flous et intrinsèquement dangereux. Je crois fermement que les modèles ou les approches qui vous amènent à poser plus de questions qu’ils n’apportent de réponses ne sont pas de bons modèles ! Je pense que les microfrontends ne sont pas à la hauteur de cette situation.
Les idées ont besoin d’une masse critique. Pour qu’un modèle tourne et mûrisse, il faut qu’un nombre significatif de personnes ou d’entreprises l’adoptent, le testent et en tirent des enseignements. Je pense simplement qu’il n’y a pas assez de personnes qui utilisent les microfrontends pour que ce soit le cas.
Les microfrontends supposent une structure organisationnelle spécifique. On suppose dans ce schéma que les équipes doivent posséder des tranches entières de fonctionnalités frontales. Dans certaines organisations, cela est logique, mais dans les grandes organisations, les services back-end fournissent souvent des données à une myriade d’autres systèmes, tant en amont qu’en aval. Dans ce contexte, il n’est peut-être pas logique d’adopter une propriété par tranches verticales.
« Il existe 11 microcadres frontaux que vous devez connaître« . Dois-je en dire plus ? La solution à l’adoption d’un modèle logiciel légèrement vague dont vous n’avez peut-être pas besoin est de ne pas chercher un cadre qui prétend le mettre en œuvre !
Alors que devriez-vous faire ?
Une chose que je tiens à préciser, c’est que si j’ai de fortes réserves quant à la validité des microfrontends en tant que modèle ou style architectural, je ne veux en aucun cas donner l’impression de critiquer les articles partagés par les équipes d’IKEA, DAZN et autres. Ce sont des articles vraiment intéressants qui décrivent d’excellentes architectures qui fonctionnent pour leurs contextes spécifiques. Lisez-les, mais s’il vous plaît, laissez le modèle de microfrontend à la porte !
Si vous travaillez sur une application frontale à grande échelle, comprenez la nécessité d’avoir des équipes évolutives. Réfléchissez à la manière dont vous pourriez créer un environnement qui le permette : – des itérations rapides sur certains composants, des itérations plus lentes sur d’autres – l’isolement des fonctionnalités – le potentiel de partage et de réutilisation des composants entre les applications – différentes bases de code, avec leurs propres pipelines de construction – créer une bonne expérience pour les développeurs.
Mais dans chaque cas, commencez par la solution la plus simple possible (YAGNI), si vous en avez vraiment besoin – examinez comment cela pourrait être réalisé compte tenu des contraintes de votre candidature et de votre structure organisationnelle.
