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, Xavier Julien, Head of WebFront chez Invivo et Brandone Martins, Lead Micro-frontend à OCTO Technology annoncent la couleur : ils vont raconter une histoire respirant le pragmatisme plus 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, créée en 2001.

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 ses marques, parmi elles : Jardiland et GammVert.

Le commencement

La première web app développée 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. Aujourd’hui, plus d’une centaine de développeurs et développeuses ont contribué à cette application : 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 doit reprendre du temps sur la qualité du code frontal, et s’adapter afin de travailler avec un nombre d’équipes variables.

Le plat de spaghetti inévitable

Mais en 5 ans, enchaînant les fonctionnalités coeur et ré-orientation de modèle, le code s’est transformé en plat de spaghetti. Plusieurs symptômes sont présents :

• Il est difficile de définir des standards communs entre différentes équipes
• Les équipes ont des contraintes techniques / métier différentes
• Le temps d’onboarding est excessif.

La fatalité des librairies

Une contrainte extérieure vient chambouler les plans des équipes techniques : Vue 2 devient End of Life (EOL), donc plus maintenue par la communauté le 31 Décembre 2024. La migration technique Vue 2 vers Vue 3 s’impose. 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 une web app front monolithique, un back-for-front et 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 backend. Effectivement, chacune de ces équipes travaillent sur des logiciels indépendants. Ces problématiques ne s'observent que sur le front monolithique.

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. L’architecture micro-frontend est toute trouvée pour ces problématiques.

Utiliser l’architecture micro front-end, c’est découper son interface en 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 les équipes autonomes 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'itérer sur l’architecture en prenant une problématique à la fois.

Deux possibilités de découpage existent :

• vertical, dans lequel chaque page correspondra à un micro-frontend
• horizontal, 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 serveur, 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 et Invivo à faire du découpage vertical.
• Les iframes, une technologie qui n’est plus à présenter. Chaque équipe travaille sur 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, 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. Chacune des équipes pourrait développer et déployer ses composants de manière indépendante 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.

Un choix en 2 temps

De manière surprenante, 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 fonctionnent depuis longtemps, donc la technologie semble assez stable pour avancer sur la migration. L’utilisation de module fédération pourra venir plus tard si la technologie 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ée 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ées 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 de Vue 2, 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 a été géré, les équipes commencent à 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és :

1. Gestion de l”état partagé (par exemple pour l’authentification) : L’app-shell va définir où conserver l’état partagé et comment le communiquer quand c’est nécessaire.
2. Fonctionnalité de support (par exemple le monitoring et les 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 et l’effectuer.

Un exemple pour comprendre

Xavier montre 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 communications. C’est un premier enseignement sur lequel les speakers insistent : 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

De manière agréablement surprenante, cette nouvelle architecture n’a pas eu beaucoup d’impact sur l’infrastructure et le déploiement. Les principes de micro-frontend mentionnent qu’il est important de déployer les micro-frontends de manière indépendante.

La web app monolithique a chez Invivo un pipeline en trois temps : build > package > deploy.

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

Les speakers insistent sur un autre point important. Effectivement, l’architecture recommande de déployer les micro-frontends de manière indépendante, dans une optique d’amélioration de lead time. Mais Invivo ne cherchait pas forcément à améliorer son lead time en utilisant cette démarche. Dans une démarche de changement incrémental et itératif, la digital factory a choisi de ne pas suivre ce principe. 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 visuelles 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.