Micro-frontend : la démarche

Micro-frontend, voilà 7 ans que le mot a été lâché par ThoughtWorks. 7 ans de recherches qui continuent aujourd’hui.

Les organisations ayant trouvé de la valeur dans les microservices, retrouvent en général les inconvénients des architectures monolithiques dès que du développement d’interface doit être réalisé. Envieux de retrouver de la souplesse dans la construction, le déploiement, l’isolation de logiciel et de l’ownership sur des domaines métiers précis, micro-frontend a officialisé un souhait de développer une nouvelle manière de construire des interfaces web.

Les dénominations se multiplient : les micro-frontends, l’architecture micro-frontend ou encore interfaces composables. Nous préférons parler de démarche micro-frontend. Héritant des microservices, nous disposons de suffisamment d'expérience pour dire qu’elle est autant une méthode d’analyse du problème métier, qu’un défi d’implémentation technologique.

Essayons de comprendre et regrouper tous les éléments qui vous permettront de décider si la démarche vous aidera. Et dans le cas positif, comment s’y prendre.

D'où vient la démarche ?

Avant d’explorer la consistance de la démarche micro-frontend, rappelons la provenance du terme, afin de comprendre si elle serait adaptée à votre organisation.

En 2011, pourquoi les microservices ?

La démarche micro-frontend est l’héritière de la démarche microservice, première fois mentionnée en 2011. Ses composantes techniques et la complexité que cette architecture implique ont beaucoup été discutées, et elle implique des compromis.

Les principaux compromis de l’architecture microservices

En 2016, enter micro-frontend

Les microservices apportaient de la valeur à certaines organisations, mais la démarche en perdait quand du développement d’interface visuelle entrait en jeu. Les points de décisions d’architecture, synchronisation de la direction pour le déploiement, ownership partagé (donc pas d’ownership) devenaient alors le quotidien du développeur dans ce genre de logiciel.

En 2016, Thoughtworks pousse la démarche jusqu'à l'interface, la nomme micro-frontend, et la fait entrer en catégorie Assess de son fameux Technology Radar, signifiant que la technologie vaut le coup d’être exploré afin de comprendre, comment elle affecterait votre entreprise. Les applications frontend pourraient être divisées par pages ou par fonctionnalités, construites et opérées par des équipes indépendantes. À cette époque, tout restait à découvrir pour les moyens techniques permettant cette souplesse.

Dans les années qui suivent, les acteurs du web sur les secteurs du e-commerce et du streaming expérimentent sur leurs interfaces massivement utilisées. Certaines entreprises y voient même un succès. En 2020, ThoughtWorks passe la démarche en Adopt, montrant que certaines entreprises y ont trouvé des bénéfices.

En 2023, qu’en est-il ?

Micro-frontend profite des réflexions autour du découpage de domaine métier en sous-domaines métier peu couplés, déjà initiés par les microservices. Le Domain-Driven Design offre de nombreux outils pour faire un découpage cohérent de problématiques métier gérées par l’entreprise. Une démarche microservices réussie passe forcément par cette étape, il en est de même pour micro-frontend. La démarche a beaucoup plus de chances de réussir conjointement à ce découpage, afin de créer des artefacts indépendants dans leur cycle de vie et dans le traitement d’une problématique métier bien ciblée.

Les techniques d’implémentations et les outils de micro-frontend évoluent beaucoup aujourd’hui. L’instabilité du monde du développement frontend facilite cette évolution lente. Où rend-on l’interface ? Comment gardons-nous un design cohérent sur des fragments d’interfaces composés ? De manière intéressante, les problématiques d'interfaces sont toujours différentes selon les acteurs, puisque leurs organisations et leurs pré-requis techniques sont différents. Malgré tout, les outillages sont plus robustes, prêt à l'emploi, et les REX commencent à sortir.

Une démarche établie et une multitude d’implémentations possibles, voilà ce qui caractérise le monde de micro-frontend aujourd’hui.

À quoi ressemble la démarche ?

La viabilité d'un artefact logiciel dépend fortement de l'analyse du domaine métier qu'il traite.

Définissons cette démarche

La démarche pousse l’organisation à explorer son domaine métier, les problématiques qu’elle essaye de résoudre à travers l’informatique. Cette exploration amène à distinguer des sous-domaines faiblement couplés. Si l’organisation ne trouve pas de sous-domaines, la démarche micro-frontend est inutile.

DDD est une boîte à outils pour le développement de logiciels. Elle fournit deux ateliers permettant d’explorer son domaine métier et de distinguer des sous-domaines. C’est l’event storming et le découpage en bounded context.

L’event storming amène les experts métier de l’entreprise, les développeurs, ainsi que toutes personnes impliquées dans le logiciel, à communiquer et clarifier de manière visuelle les processus métier sur lesquels ils travaillent. L’atelier finit sur une représentation de tous les événements importants du métier ainsi que des questionnements. La représentation visuelle permet de mettre en évidence des sous-domaines, séparés par la présence d'événements pivots en commun, ou parfois aucun évènement en commun.

Un bounded context représente les frontières dans lesquelles les problématiques métier s'appliquent. Ces frontières marquent un terrain fertile où il est cohérent de créer un logiciel dédié à une seule problématique métier.

Un exemple de tableau en fin d’atelier d’Event Storming

D’autres outils plus techniques du DDD peuvent vous permettre de faire émerger des modules indépendants dans le code. Les expérimenter en rendant indépendant un module dans le logiciel d’interface monolithe, est sûrement une première étape réussie vers le micro-frontend.

Il est très important de passer du temps à cerner son domaine, plutôt que de se lancer dans des solutions toutes faites taggé "Micro-frontend". Un découpage non pertinent amènera l’organisation à créer une interface comme une addition d’interface dépendantes les unes des autres.

Comment faire des choix technologiques ?

Une fois la démarche, inspirée de DDD, ancrée dans l’organisation, les questionnements techniques peuvent débuter sereinement.

Pour nous aider, Luca Mezzalira propose un arbre de décision facilitant la prise de décisions techniques. Il l'a appelé le micro-frontend decision framework. Le framework aide à identifier quelles propriétés techniques peuvent avoir un ou plusieurs micro-frontends.

L'arbre de décision comprend 4 questions.

1) Plusieurs domaines métiers doivent-ils être présents sur une seule page ?

Cette question oriente un découpage vertical ou horizontal, et limite le champ des possibles sur les implémentations. Un découpage horizontal implique plusieurs micro-frontends sur une même vue. Tandis qu’un découpage vertical implique un seul domaine métier sur une vue.

2) Où les micro-frontends se composeront-ils ? Où est-ce-que le HTML se rend ?

Du côté du navigateur, au niveau d'un CDN, ou bien au niveau d'un serveur, différentes techniques d'implémentation s’offrent à nous, après réponses à ces deux questions.

3) Comment l’utilisateur est-il routé d'un micro-frontend à un autre, d'une page à une autre ?

Le routage peut être au niveau du navigateur, du CDN, ou bien du serveur. Différentes contraintes permettent de choisir.

4) Si nécessaire, comment les micro-frontends vont-ils communiquer  ?

Il est conseillé d'avoir peu de dépendances entre domaines métier, mais quand on modélise des processus, c'est rarement le cas. Si des éléments doivent être partagés, il convient de choisir quelles méthodes utiliser : du webstorage, une API sur le réseau, un custom event JS sur le navigateur.

À partir de cette matrice, de nombreuses implémentations sont imaginables. Voici quelques exemples d’implémentations de micro-frontend :

• Une application SPA contenant ce qu'on appelle un "application-shell". En fonction de la route demandée, cette application-shell va charger / décharger d'autres micro-frontends
• Une application serveur qui charge des micro-frontends, rend chacun d’entre eux et l’envoie au client
• Un web component répondant à un besoin métier et qui peut-être intégré à n'importe quelle page

Quels challenges résout la démarche ?

Plusieurs signaux montrent que la démarche, le questionnement, et les outils déjà existants peuvent apporter à une équipe tech.

Un agrandissement d’équipe efficace sur un logiciel d’interface

Le premier que nous avons identifié est le suivant : vous avez ou vous êtes dans des équipes de développement, séparées, travaillant sur une même interface, et vous devez beaucoup communiquer pour avancer. C’est-à-dire, communiquer pour la mise en production, les mises à jour de librairies, les standards de code, ou bien encore les décisions techniques. De plus, les équipes n'arrivent plus à faire des choix qui servent au mieux leurs intérêts et l’intérêt de la problématique métier qu’elles veulent traiter. Ce genre de problématiques peuvent se présenter lorsque l’équipe dépasse la Two-Pizza Team.

Autre signal, la montée en compétences sur le front est longue pour les nouveaux arrivants. Il est difficile de comprendre tous les processus métier accessibles depuis l'interface. Enfin, il est difficile de responsabiliser les équipes sur des domaines métiers précis.

Des conversations peuvent vous mettre la puce à l’oreille

La refonte d’interface incrémentale et itérative

Deuxième cas que nous avons identifié : Votre entreprise a un site web basé sur une technologie non maintenue, ou pour laquelle il est difficile de trouver des forces de travail. Malgré cela, ce site rapporte encore de la valeur à l'entreprise mais ne peut plus évoluer dans cette même technologie. La démarche micro-frontend adossée à l’analyse des différents domaines métiers présents dans l’interface va permettre de réaliser une refonte itérative en minimisant les risques d’échecs.

Des conversations peuvent mettre la puce à l’oreille

En bref,

La démarche micro-frontend aide à la résolution des problèmes du passage à l'échelle sur le développement d'une application front et sur la refonte d’interface complexe.

Des paramètres à prendre en compte

Il est important de noter que la démarche n’est pas faite pour lancer un projet, malgré toutes les espérances sur le succès de l’interface. Martin Fowler en parle.

Certaines questions existent pour savoir si la démarche pourrait apporter quelque chose à l'équipe. Les réponses seront très subjectives mais elles vous montrent les paramètres à pondérer avant de se lancer. Ces paramètres sont les suivants :

• La taille du build : Plus l’artefact buildé à une taille conséquente, plus de données devront passer par le réseau, plus la performance du site peut être impactée.
• Le nombre de développeurs travaillant sur le logiciel : Plus il est élevé plus la communication et la prise de décision sera complexe
• L’indépendance entre les équipes : Ont-elles des objectifs fortement liés? Les décisions doivent être prises conjointement
• La fréquence de release : les équipes doivent-elles obligatoirement mettre en production au même moment ? Si une équipe impose un rythme, tout le monde doit suivre ce rythme ?
• Les besoins technologiques des équipes : Afin de redonner l’ownership, les choix techniques doivent revenir aux équipes impactées et qui gère le domaine métier.
• Un backend monolithique : SI l’organisation a déjà réussi à découper son backend en micro-services, allez au bout de la démarche devrait définitivement responsabiliser les équipes.
• Un site statique ou dynamique : Cela peut impacter la nécessité de la démarche et les choix technologiques.

Quelles challenges introduit la démarche ?

L’intégration de la démarche induit des compromis. Tout comme l’architecture microservice, cela reste un choix d’architecture.

Quand on choisit une architecture, le but visé est de gérer des problèmes plus simples. Il n'y a pas d'architecture parfaite, on cherche le mieux possible et l'option la moins mauvaise. Faire du micro-frontend, c’est construire un système d’interface distribué, avec tout ce que cela implique.

Le risque du découpage inopportun de l'application

Dans les organisations de grandes tailles, le temps passé à trouver des solutions est parfois priorisé à celui passé à cerner les problèmes. Pour trouver des micro-frontends faiblement couplés, ce temps est pourtant indispensable. Si ce temps n'est pas pris, le découpage risque d'être incohérent. Cette conférence de DDD Europe 2022, donne 3 paramètres qui vous permettront d’évaluer la cohérence de ce découpage, c’est-à-dire le couplage entre différentes lignes de code, entre les différents logiciels : la force (par quel moyen le code est utilisé ? par un import direct ou par des abstractions ?), la volatilité (les fréquences de changements des deux logiciels) et la distance entre les lignes de codes qui doivent changer (dans la même méthode, classe, logiciel, ou dans un autre logiciel).

Plusieurs signaux avertissent d’un mauvais découpage :

• pour faire une fonctionnalité, il faut modifier et déployer plusieurs micro-frontends
• des équipes doivent encore se synchroniser pour certains déploiements
• la charge cognitive des développeurs reste la même (temps passé à communiquer et à se tenir au courant des avancés d’autres équipes)
• le temps d’onboarding reste le même

La démarche micro-frontend découle de Domain-Driven Design. Il faut découper en domaines business faiblement couplés, c’est-à-dire traitant de problèmes indépendants, et n’ayant pas forcément les mêmes vitesses d’évolution. Une bonne première étape est de découper le monolithe en monolithe modulaire, avant de passer le pas vers micro-frontend.

Une interface inconsistante

Sachant que des équipes différentes vont produire plusieurs fragments d’interface pouvant s'afficher sur la même page web, votre site risque de manquer d'un design cohérent. Dans le monde du web et de l'interface, un design inconsistant a des conséquences non négligeables sur la rétention, la confiance de l'utilisateur envers le site ou l'image de marque.

Un système de design robuste et éprouvé, avec du leadership et de la gouvernance, peut aider à surpasser la problématique. Sortir une librairie de composants visuels permettra aux micro-frontends d’utiliser les mêmes composants graphiques. Et pour garantir la consistance, vérifier la version de la librairie utilisée lors du build est une première solution au problème.

La résistance de la structure organisationnelle

Les choix d'architecture découlent de problèmes ressentis. Cependant, on observe parfois que certains choix sont faits pour coller à la théorie, à une description faite par une autre entreprise, ou bien pour afficher le buzzword sur les offres d’emplois.

De la même façon, faire du micro-frontend n'est pas une cible. Les entreprises l'ont mise en place avec l'objectif d'avoir plus d'agilité dans les choix business, plus de résilience, plus de souplesse dans la construction et le déploiement d’interface.

> Les micro-frontends ne sont pas un but en soi.

Si vous êtes convaincus par la démarche, il faudra convaincre vos partenaires en mettant en avant les problèmes que vous voulez résoudre.

Plusieurs implémentations possibles

La vérité est qu'il y a autant d'implémentations que de types d'organisation d'équipe possibles. L’exploration de nouveaux concepts, des techniques de transclusion, de rendu, de cycle de vie demandent de l'expérimentation. Afin de faire le bon choix, se laisser le temps d’expérimenter et de documenter avec les Architecture Decision Records (ADR), pour trouver la meilleure implémentation est judicieux.

Pour résumer

Aujourd’hui, on peut affirmer que micro-frontend est une véritable démarche qui inclut de la méthode de conception logicielle et l’utilisation des technologies disponibles sur le web.

Avant de vous lancer dans la démarche, il est important de mesurer la souffrance des équipes à travailler sur un logiciel d’interface monolithique.

Par la suite, s’inspirer de la démarche du Domain-Driven Design est grandement utile. Lancer des event storming et définir des bounded contexts prépare un découpage de monolithe en monolithe modulaire. Cette étape peut être largement suffisante pour réduire la charge cognitive des équipes.

Pour finir, si les contraintes de déploiements, de choix de technologie et de communication se font trop fortes sur un monolithe modulaire, mettez en place une culture de l'expérimentation et de l’apprentissage pour faire des choix éclairés sur comment implémenter des micro-frontends dans votre contexte.

Pour aller plus loin

• Pourquoi micro-services ?
• Martin Fowler parle de micro-frontend
• Le micro frontend framework de Luca Mezzalira
• Le livre Building micro-frontend de Luca Mezzalira
• Le questionnaire "Ai-je besoin de micro-frontends"
• Une vidéo sur Les risques des micro-frontends
• State of Frontend 2023