Le micro-frontend décomplexé : les dessous d’une migration incrémentale et itérative

La Duck Conf est la conférence de l’architecture de SI by Octo. Dans ce 2ème talk de la journée, Xavier Julien Head of WebFront chez Invivo et Brandone Martins, Lead Micro-frontend à OCTO Technology annonce la couleur : Le théorie est laissée de côté pour du concret. Ils vont raconter une histoire respirant plus le pragmatisme que le dogmatisme.

Leur challenge : nous donner toutes les clés afin que les tenants et aboutissants de la démarche micro-frontend soient clairs comme de l’eau de source dans 30 minutes. Ils se basent sur l'expérience de la digital factory d’Invivo qui a effectué une migration risquée en s'inspirant de cette architecture.

Posons le contexte

Invivo, de l’agriculture au digital

Invivo est un acteur international de l’agro-alimentaire avec pour but de favoriser la transition agricole et alimentaire vers un agrosystème résilient. C’est une union de coopératives agricoles rassemblant 185 coopératives adhérentes, autour de quatre pôles d’activités stratégiques :

• Négoce international de grains
• Agriculture
• Agroalimentaire (malterie, pôle blé, vin)
• Jardinerie et distribution alimentaire.

Finalement, un pôle global transverse de solutions innovantes et digitales complète ce dispositif. Le groupe est créé en 2001 et 2018 marque l’année où l’entreprise va prendre un tournant digital en créant la première marketplace dédiée aux agriculteurs.

Après plusieurs succès sur le créneau numérique, Invivo crée sa digital factory et continue de développer des produits en marque blanche, ré-utilisés par ces marques (parmi les plus connus du grand public : Jardiland et GammVert).

Le commencement

Le premier besoin que la digital faqui ciblait les agriculteurs avec un réseau internet limité et une gamme de produit stable, les équipes tech partent sur une SPA en VueJS en 2018. Fort de ces premiers succès, plus d’une centaine de développeurs et développeuses contribuent à cette application devenue plateforme : Aladin.farm.

La vision long terme

La vision d’Invivo sur le long terme continue d’être ambitieuse : transformer le site en plateforme et pouvoir faire de la marque blanche. Pour atteindre ces objectifs la digital factory remet sur la table qu’elle doit reprendre du temps sur la qualité du code front, et s’adapter afin de travailler avec un nombre d’équipes variables.

Le plat de spaghetti

Effectivement, en 5 ans, enchaînant les fonctionnalités coeur et ré-orientation de modèle, le code de la plateforme s’est transformé en plat de spaghetti. Cela est devenu une douleur, pour les contributeurs, d’apporter une évolution sur cette web app.

Plusieurs symptômes vous feront remarquer que vos équipes affrontent un plat de spaghetti, que ce soit sur du front-end ou backend :

• La prise décision est compliqué pour les équipes
• Il est difficile de définir des standards communs
• Les équipes ont des contraintes techniques / métier différentes
• Le temps d’onboarding est excessif. Il faut plus d’un mois pour un développeur pour contribuer au logiciel.

La fatalité des librairies

Mais l'événement qui déclenche l’histoire racontée, c’est une contrainte extérieure : la migration technique du framework front Vue 2 vers Vue 3 avec une deadline au 31 Décembre 2024. Vue 2 devient End of Life (EOL), donc plus maintenue par la communauté, et rester sur cette version rendrait encore plus difficile les évolutions.

Après une première tentative, cette migration ne peut pas se faire en une fois à moins d’un big bang, la faute au plat de spaghetti. Comment s’en sortir ?

Prise de recul d’archi

Prenons du recul et observons l’architecture du SI de la Digital Factory :

On y retrouve :

• 1 web app front monolithique
• 1 Back-for-front
• Une quinzaine de micro-services (4 sont représentés par souci de simplicité)

À ce moment-là, les équipes de développement Invivo sont divisées en sous-équipes métier : une équipe panier, une équipe paiement, une équipe recherche etc … Chacune des équipes travaille sur son micro service dédié.

Il est intéressant d’observer que ces problématiques de migration technologique n’étaient pas ressenties dans les dépôts de code de microservices. Effectivement chacune de ces équipes travaillent sur des logiciels indépendants. Mais au moment d’arriver sur le front, c’est là que le flou s’installe.

Pour régler le problème sur le long terme, il a fallu penser à un moyen de redonner de la responsabilité sur un périmètre clair du front aux équipes. Mais aussi leur donner la liberté de choisir les standards et les technologies qui répondent le mieux à leur problématique métier, sans que ça ait une incidence sur les autres équipes.

Utiliser l’architecture micro front-end, c’est découper son interface en par fragment dédié et isolé. Cinq grand principes de micro-frontend sont énoncés :

1. Un micro-frontend est une réponse à une et une seule problématique métier
2. Chaque micro-frontend utilise les standards et les technologies utile pour sa problématique sans contrainte des autres domaines métiers
3. Chaque micro-frontend peut être déployé indépendamment des autres
4. Un micro-frontend est sous la responsabilité d’une feature team et une seule
5. Définir un contrat d’interface entre les MFE si besoin de communication

Micro-frontend pousse à rendre autonomes les équipes sur leurs logiciels du back jusqu’au front. Cela vous évoquera sûrement la loi de Conway.

Comment découper un site e-commerce ?

Un premier découpage cohérent serait de créer un micro-frontend pour un micro-service. Bien que micro soit dans le nom de l’architecture, Xavier nous conseille de commencer à découper macro. Effectivement, Invivo a pris le temps d’essayer l’architecture itérativement en prenant une problématique à la fois. Une fois une première mise en place terminée, vous pouvez continuer à découper.

Il existe deux possibilités de découpage pour son interface :

• vertical, dans lequel chaque page correspondra à un micro-frontend
• horizontale, dans lequel une page se construira avec un regroupement de micro-frontend

Comment mettre l’architecture micro-frontend en place ?

Sur quoi peut-on s'appuyer ?

Invivo a exploré 3 technologies :

• Le routing server, qui consiste à délivrer des pages (considérées chacune comme un micro-frontend) en fonction de l’url demandé. Cela contraindrait chacune des features teams à travailler sur un ensemble de page. Cela contraindrait Invivo à faire du découpage vertical.
• Les iframes, une technologie qui n’est plus à présenter. Chaque équipe déployait ses pages ou ses composants dans un site web dédié. Ceux-ci pourront être intégrés dans la web app délivrée à l’utilisateur grâce aux iframes.
• Module federation, qui est la dernière technologie sortie dans l'éco-système front pour faire de la composition de composant front au runtime, directement sur le navigateur du client. Pour faire court, chacune des équipes pourrait développer et déployer ses composants indépendamment des autres équipes. La web app délivrée aux utilisateurs n’aurait plus qu’à aller chercher les dernières versions déployées de ces composants dans un utilisateur récupère la webapp.

Un choix en 2 temps

De manière surprenante (à premier abord), Invivo à fait le choix de commencer avec des iframes. Le routing serveur était trop différent de l’architecture SPA actuellement en place. De plus, la Web app en Vue 2 actuellement se build avec le standard CommonJS. Cela constitue un blocage pour travailler avec Module federation, la librairie nécessite d’utiliser le dernier standard de module Javascript : ESModule.

Les iframes ça fonctionne depuis toujours, donc on peut s’appuyer dessus pour avancer sur la migration. L’utilisation de module fédération pourra venir plus tard si la techno est adéquate.

La roadmap

L’aventure démarre donc en novembre 2023 ! La stratégie de migration est la suivante : commencer par les pages concernant un seul domaine métier et les extraire dans une iframe migré en Vue 3. Les pages “Legals” seront les bons premiers boucs émissaires... Ceci marque les premiers succès de migrations, et en appellera d’autres.
En septembre 2024, la démarche a permis d’extraire des parties du site une par une : Panier, landing, mon compte, et bien d’autres. Elles sont toutes migrés en Vue 3 de manière incrémentale. On comptabilise 11 micro-frontends au total.

Le temps presse, et en novembre 2024, à deux mois de la EOL, la digital factory prend la décision de passer le monolithe restant en Vue 3. Cela se fait de manière beaucoup plus sereine, car il y avait beaucoup moins de code à migrer.

Maintenant que le risque de migration Vue 2 vers Vue 3 a été géré, les équipes peuvent commencer à utiliser module federation pour chacun de ses micro-frontends. Effectivement Vue 3 utilise le standard ESModules. Cela permettra d’utiliser des fonctionnalités comme le module sharing, afin d'améliorer les performances de chargement.

Les migrations successives vers des micro-frontends ont vu apparaître de nouvelles briques techniques sur lesquelles il faut s’attarder.

Qu’est-ce qu'une app-shell ?

Au fur et à mesure du découpage en micro-frontend, le monolithe à eu de moins en moins de responsabilités en termes de rendering. Il est devenu une app-shell. Le rôle d’une app-shell est d’intégrer de manière consistante les différents micro-frontends. Ce rôle peut impliquer plusieurs responsabilité :

1. Gestion de l”état partagé (par exemple pour l’authentification) : L’app-shell va définir où conserver l’état partager et commencer le communiquer quand c’est nécessaire.
2. Fonctionnalité de support (monitoring, analytics) : L’app-shell va porter ces modules communs à tous les micro-frontend et leur fournir des abstractions afin que ceux-ci puissent se concentrer sur la solution métier.
3. Chargement des MFEs, routing, et communication : L’app-shell va porter ces responsabilités d’orchestration. Quand une communication est nécessaire, elle va pousser les micro-frontend à déclarer un contrat de communication.

Un exemple pour comprendre

Xavier montre à l’audience un workflow de traitement et communication pour la création de commande. Celui-ci implique l’app-shell et différents micro-frontends : Panier, Commande, Mon compte.

Lorsqu’une communication est nécessaire, Invivo utilise les window.postMessage afin de faire ces communication. C’est un premier enseignement sur lequel les speakers insiste : délaissez les patterns des framework et utilisez ce que la plateforme web propose.

Un système de livraison, qui ne change pas tant que ça

Le processus de mise en prod de la web app a évolué en conséquence. Et de manière agréablement surprenante, cette nouvelle architecture n’a pas eu beaucoup d’impact sur l’infrastructure et le déploiement. On a vu dans les principes de micro-frontend qu’il était important de déployer chacun des micro-frontend indépendamment.

La web app monolithique avait une pipeline en trois temps : build > package > deploy

Ces 3 stages ont été gardés, mais afin d’avoir le moins de modifications possibles dans la pipeline, chacun des micro-frontends est buildé et déplacer dans l’artefact de build du monolithe (devenue app-shell ensuite). Après quelques manipulations sur le routage, ces micro-frontends seront disponible alors à l’url aladin.farm/${nom-du-micro-frontend}

Les speakers insistent sur un autre point important. Effectivement, micro-frontend recommande de déployer les micro-frontend de manière indépendante dans une optique d’amélioration de lead time. Finalement, Invivo ne cherchait pas forcément à améliorer son lead time en utilisant cette démarche. Afin de changer le moins de choses possible sur le déploiement, la digital factory a choisi de ne pas suivre ce principe. Et cela fonctionne très bien ainsi. Les speakers conseillent de toujours comprendre le dogme des architectures mais de les utiliser de manière pragmatique dans vos contextes.

À la fin de ce chantier, l’architecture micro-frontend a clairement été un game changer pour faire une migration risquée de manière incrémentale et itérative. Désormais, elle permet aussi aux équipes métier de développer sur des parties du front indépendantes. L’heure est au bilan

Le bilan

La digital factory d’Invivo a tiré plusieurs enseignements de cette migration.

Les facteurs de succès

Plusieurs facteurs ont facilité cette migration avec micro-frontend :

1. Le temps de mise en place de la première brique a été simplifié grâce aux principes DevOs largement compris et utilisés quotidiennement
2. Des connaissances en microservices ont aidé l’organisation à comprendre la démarche, mais dans le front web cette fois
3. Avoir un design system a permit de limiter les potentiels incohérences visuel et ne pas impacter l’image de marque

Clarification des frontières dans le code

Micro-frontend a permis de clarifier des frontières dans le code. Les équipes sont plus sereines pour faire évoluer leur micro-frontend et peuvent prendre des décisions en autonomie.

Événement marquant, une feature team largement orientée backend a réussi à s’approprier le concept et faire du front intégré dans la webapp, sans avoir à comprendre les autres librairies et concepts des autres features teams (qui ne leurs auraient pas été utiles de toute façon).

S’outiller pour ses propres besoins

Autre observation, les dix dernières années ont vu l’avènement de certaines librairies de composants dans le monde du frontend. Utiliser micro-frontend, c’est se détacher des concepts de ces librairies propriétaires et se rapprocher des APIs navigateurs. Cela pousse les développeurs à avoir une vision plus pragmatique sur le développement front et invite à revenir aux bases du web.

Pas de big bang

Finalement, sûrement le plus gros enseignement est une vérité qui est répété depuis quelques temps maintenant dans le logiciel : recommencer de 0 pour une migration est souvent voué à l’échec. Malgré cela, c’est encore des décisions que l’on peut observer dans certaines entreprises. Dans le cas du front, micro-frontend est votre allié pour faire des migrations itératives et incrémentales.

La slide de fin

Les speakers nous délectent d’une slide résumé aux petits oignons.