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.
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 :
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 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 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.
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 :
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 ?
Prenons du recul et observons l’architecture du SI de la Digital Factory :
On y retrouve :
À 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 :
Micro-frontend pousse à rendre autonomes les équipes sur leurs logiciels du back jusqu’au front. Cela vous évoquera sûrement la loi de Conway.
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 :
Invivo a exploré 3 technologies :
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.
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.
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é :
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.
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
La digital factory d’Invivo a tiré plusieurs enseignements de cette migration.
Plusieurs facteurs ont facilité cette migration avec micro-frontend :
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).
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.
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.
Les speakers nous délectent d’une slide résumé aux petits oignons.