Ce contenu est le produit d’une retranscription d’une conférence proposée par Sébastien Oddo durant le bdx.io 2023 https://youtu.be/HFMBC-upNQ8

À quoi ça sert et qu’est-ce que c’est ?

Terme relativement nouveau, et ayant connu un fort coup de projecteur durant l’année 2023, l’approche micro-frontends consiste, grossièrement, à construire un ensemble logiciel à partir de périmètres techniques n’utilisant pas les mêmes frameworks ou règles internes.

Concrètement, il s’agit d’être en mesure de permettre aux équipes techniques travaillant sur un projet de taille importante d’utiliser les outils et les approches de leur choix en fonction de leurs connaissances ou de leurs préférences dans un périmètre logiciel défini. Celui-ci sera à son tour exécuté de manière à travailler de concert avec d’autres ensembles au sein d’une application paraissant unie pour l’utilisateur final.

Il s’agit donc de donner la sensation d’évoluer dans un ensemble applicatif cohérent sans que celui-ci ne soit construit avec des technologies identiques.

Durant sa conception, l’application devra être découpée en périmètres fonctionnels cohérents qui pourront être confiés à des équipes relativement autonomes tant dans leurs organisations que dans leurs choix technologiques.

Le nerf de la guerre étant d’être en mesure de faire fonctionner ces bases de codes et équipes de concert, tant d’un point de vue purement technique qu’organisationnel (eg: les déploiements).

Est-ce judicieux ?

Malgré des intérêts managériaux apparents et la promesse d’autonomies des équipes pas toujours très cohérentes d’un point de vue technique, l’approche micro-frontends ne sert qu’à découpler le travail des équipes entre elles et les intégrations de fonctionnalité.

Ce n’est pas factoriser

L’approche micro-frontends ne sert pas à factoriser le code. Au contraire même, une partie de la base de code de chacune des features étant exclusivement dédiée à sa communication avec les autres fonctionnalités développées dans d’autres technologies.

Comment assembler tout ça ?

Peu importe l’approche technique retenue, une application en micro-frontends reposera toujours et nécessairement sur une couche de code “glue”. Dans le cadre de projets JavaScript, cette glue prend souvent la forme de dépendances qui ne sont, à ce stade (janvier 2023), pas ou peu matures. Par ailleurs, cette couche de colle prend donc un aspect stratégique non-négligeable et il sera donc central de maintenir la connaissance autour de celle-ci dans vos équipes.

Rester cohérent

Un effort non-négligeable devra être déployé pour assurer une expérience cohérente à l’utilisateur, dans sa navigation mais également dans son accès aux services (authentification et déploiements).

Et le FUTUR alors ?

Est-il réellement judicieux au long terme de multiplier les technologies ? Si l’intérêt à court terme, en l’état courant des équipes, l’approche micro-frontend peut sembler être une bonne idée, il sera nécessaire à l’avenir de maintenir ces mêmes compétences au sein du pôle technique; sous peine de devoir re-développer des fonctionnalités utilisant des technologies que vous ne souhaitez plus maintenir.

Terminologie

Shell application

Base de code support dans laquelle les applications (ou micro-fronts) viennent se greffer. Pour l’utilisateur, elle prend souvent la forme concrète d’une barre de navigation permettant d’accéder aux diverses fonctionnalités offertes par le service.

Sub-application

Application avec un cycle de vie indépendant, peut éventuellement vivre en dehors du contexte offert par la shell application.

• Réduction du couplage
• Porter une attention particulière à la cohérence

Component

Composant logiciel à fort couplage, peut être réutilisable mais pas autonome.

• Couplage fort avec son environnement

Suggestion de technologies

Module federation

Aujourd’hui intégrée à Webpack, cette technologie consiste à préciser, au build, des bundles de code à exposer (et pouvant être consommés par d’autres builds) et des bundles de code à consommer (ces bundles étant disponibles de manière distante sur le réseau).

La fédération de modules (Module Federation) permet aux développeurs de partager du code et des ressources entre plusieurs applications JavaScript ou micro-frontends. Elle divise le code en modules indépendants pouvant être chargés à la demande, facilitant le développement et le déploiement indépendants des micro-frontends. Fondée sur le chargement distant de modules JavaScript, elle utilise le module bundler Webpack pour charger des modules à partir d’autres applications. Les développeurs configurent Webpack pour exposer et consommer des modules entre applications, permettant un déploiement indépendant. Les micro-frontends chargent dynamiquement le code nécessaire à partir d’autres micro-frontends lorsqu’un utilisateur visite une page contenant plusieurs d’entre eux.

Documentation Module Federation

single-spa

Il s’agit de définir une configuration pour chaque micro-frontend indépendant, spécifiant comment charger, exécuter et évaluer l’état du micro-frontend. single-spa prend ensuite en charge le chargement dynamique du code lorsque nécessaire, l’exécutant uniquement au moment requis. single-spa couvre donc les besoins en terme de router et de contexte d’exécution. A priori la technologie la plus mature pour aisément construire l’ensemble shell-application + micro-frontends.

Documentation single-spa

Impressions personnelles

’tention, c’est mon avis à moi. Pas celui de M. Oddo.

J’ai tendance, par défaut, à me désintéresser de tous les buzzwords qui peuvent apparaître dans un environnement aussi changeant que celui du développement JavaScript. Aussi, le sujet des micro-frontends n’a pas fait exception. J’ai, pour ainsi dire, découvert le sujet au cours de cette édition 2023 du bdx.io, mon avis n’est donc pas le plus éclairé sur le sujet.

Les technologies de chargement asynchrone des dépendances telles que proposées par Webpack ou single-spa me semblent intéressantes:

• Pour le découplage qu’elles permettent, découper l’application en sous-périmètres livrés de manière décorrélée me semble être plutôt futé.
• Pour les économies de données qu’elles offrent, en permettant au client de ne télécharger que le code qu’il s’apprête à effectivement utiliser.

En revanche, l’idée sous-jacente régulièrement associée à cette approche, à savoir utiliser diverses technologies pour essayer de créer une application a priori cohérente pour l’utilisateur, me laisse plutôt sceptique.

• Gérer un panel de compétences diverses (en termes de framework de travail) peut sembler être intéressant; néanmoins, cela implique que seules certaines personnes peuvent intervenir sur un périmètre de code donné. Gare aux départs. Gare aux congés. Gare aux embauches (comment tester la compétence d’un type dans un domaine que je ne maîtrise pas ou peu?).
• L’appropriation (ownership) de la base de code me semble être le nerf de la guerre pour garder des développeurs intéressés par leur travail (et permettre à celui-ci d’être relativement humanisant). Ici, cette appropriation ne s’exerce que sur un périmètre nécessairement réduit (sinon l’approche perd de son intérêt) d’une part, et d’autre part, nécessite un effort de coordination non négligeable (interfaces, déploiements, gestion des versions) sous peine de proposer à l’utilisateur final une expérience toute décousue.

L’intérêt ne semble donc être réellement présent que pour les grosses entreprises, devant réaliser de gros outils. Celles-ci faisant en fait face aux problèmes inverses dans le cas d’une structure monolithique (manque d’ownership, manque de liberté des développeurs), l’approche micro-frontend permet de retrouver un périmètre de travail équivalent à une plus petite structure.