La plupart des développeurs ont déjà entendu parler de l’architecture de microservices, mais le terme de micro frontend est moins connu. Comme son nom l’indique, le concept de micro frontend est similaire à celui des microservices. Son objectif est de résoudre la plupart des problèmes relatifs aux applications monolithiques : elles sont trop volumineuses, difficiles à utiliser, à modifier, et inviter de nouvelles personnes à travailler sur ces applications peut s’avérer difficile. De plus, si plusieurs équipes travaillent sur différentes parties de l’application, elles devront coordonner toutes leurs modifications.
Les microservices vous aident à diviser le back-end en plusieurs services indépendants. Vous pouvez utiliser la même approche pour diviser une application monopage en applications plus petites. Vous aurez alors besoin d’un « orchestrateur » pour réunir les différentes parties afin que l’utilisateur ne remarque aucun changement.
Quelles sont les alternatives à l’architecture micro frontend ?
Bien sûr, il existe d’autres moyens de gérer certains des aspects indésirables liés aux énormes applications, en séparant une partie du code dans le paquet npm, par exemple. Cela peut résoudre une partie du problème, notamment en réduisant la taille du référentiel. Dans Angular, vous pouvez également séparer le code dans un module et appliquer un chargement différé. Cela peut permettre, dans une certaine mesure, un fractionnement vertical de l’application. Mais cela présente également des inconvénients, comme celui de devoir générer le projet de premier niveau lorsque l’une des dépendances est mise à jour. L’expérience développeur n’est pas non plus idéale. Lorsqu’on utilise un framework, quel qu’il soit, il vaut mieux tout mettre à jour vers la même version, mais c’est une tâche colossale que personne n’a envie de faire. Vous avez également la possibilité de joindre plusieurs applications via l’iframe. Cela les rend indépendantes, mais peut-être trop, car la communication inter-applications pose problème, tout comme le partage du code, des styles, etc.
Micro frontends : un bon compromis ?
Les micro frontends combinent ces deux approches. Chaque micro frontend est une application distincte comparable à une application monopage. Ils ne sont pas compilés dans un index.html avec des fichiers de script et de style liés, mais dans un module JavaScript. À la place d’une iframe dans l’application « principale », le code indique que lorsque l’URL correspond à un certain modèle, le module est alors chargé en différé et placé à un endroit spécifique. Il est ainsi possible d’avoir plusieurs applications interconnectées sur la même page.
Par conséquent, les micro frontends n’ont pas besoin de gérer la mise en page de l’application ni les règles CSS de base qui ne peuvent être traitées que dans l’application principale. Autre avantage : si plusieurs micro frontends utilisent la même version de React, ils peuvent partager le même module React. Il n’est pas nécessaire de le télécharger séparément pour chaque micro frontend. Lorsqu’il y a différentes versions d’un module JavaScript, cela n’est pas non plus un problème.
Par contre, il faut s’assurer que les styles des micro frontends ne s’appliquent pas à d’autres parties de l’application, c’est l’un des principaux soucis. Heureusement, la plupart des frameworks d’interface utilisateur incluent des outils permettant de gérer cela facilement.
Outils pour les architectures micro frontend
Écrire votre propre code pour charger des applications micro frontend serait une tâche assez fastidieuse. Heureusement, de nombreux frameworks permettent de gérer l’orchestration et offrent des outils pour convertir les applications écrites dans d’autres frameworks populaires au format micro frontend.
Chez Pure, nous avons choisi single-spa. Il présente plusieurs avantages : il est facile à comprendre, il prend en charge les frameworks JavaScript et dispose d’une documentation détaillée. En outre, single-spa propose plusieurs types de micro frontends, chacun adapté à des tâches légèrement différentes.
Pour l’instant, nous utilisons uniquement le type « Application », car c’est le plus facile à utiliser pour passer d’une application monopage à des micro frontends. Les autres types nécessitent également une architecture micro fronted plus détaillée. Le type « Application » est le type recommandé par défaut par les créateurs de single-spa.
