Architecture de micro frontends

Les micro frontends étendent l'idée des microservices à l'interface utilisateur : une grande application web est divisée en éléments développés, testés et déployés indépendamment. Chaque élément appartient à une équipe distincte et ils sont réunis pour former une seule expérience à l'exécution.

Une gigantesque application Angular unique (un « frontend monolithique ») lie chaque équipe à un même cycle de publication, une même compilation et un même déploiement. À mesure que les équipes grandissent, cela ralentit tout le monde. Les micro frontends permettent aux équipes de publier selon leur propre calendrier.

La propriété essentielle est le déploiement indépendant : l'équipe du paiement peut déployer un nouveau parcours de paiement sans recompiler ni redéployer le catalogue de produits. Chaque élément distant est un artefact distinct derrière son propre pipeline.

Sur le plan architectural, un hôte (coquille) charge un ou plusieurs éléments distants. La coquille gère le routage de niveau supérieur et la mise en page ; les éléments distants fournissent des zones fonctionnelles chargées à la demande.

Les éléments distants peuvent être combinés au moment de la compilation, sur le serveur (SSI/edge) ou à l'exécution dans le navigateur. La composition à l'exécution avec Module Federation est la plus courante pour Angular, car elle préserve le déploiement indépendant.

Module Federation permet à une application compilée d'exposer des modules qu'une autre application compilée charge via HTTP à l'exécution, en partageant les bibliothèques communes afin d'éviter leur duplication. C'est le moteur de la plupart des micro frontends Angular.

Chaque micro frontend devrait correspondre à un domaine métier clairement défini (catalogue, paiement, compte). Des frontières de domaine nettes réduisent au minimum le couplage entre les équipes, ce qui constitue tout l'intérêt de cette approche. Les préoccupations partagées (authentification, système de conception) deviennent des contrats explicites.

Les micro frontends ajoutent une complexité réelle : décalage des versions entre les éléments distants, dépendances dupliquées en cas de mauvaise configuration, débogage plus difficile entre les frontières et échecs de chargement à l'exécution. Adoptez-les uniquement lorsque la taille des équipes justifie cette surcharge.

Pour une petite équipe ou un produit unique, un monolithe bien structuré avec des routes chargées paresseusement est plus simple et plus rapide. Les micro frontends deviennent avantageux lorsque plusieurs équipes doivent déployer indépendamment dans la même application.

Pour éviter une interface disparate, les équipes partagent une bibliothèque de système de conception et des styles globaux. La cohérence est un contrat délibéré, et non le fruit du hasard, car chaque élément distant est compilé séparément.

Les éléments distants Angular doivent partager une seule copie du framework Angular à l'exécution ; charger deux versions d'Angular casse l'injection de dépendances et alourdit le paquet. Des outils tels que Native Federation gèrent ce partage pour vous.

Quel est l'avantage déterminant des micro frontends ?

Les micro frontends divisent une grande application en éléments distants déployables indépendamment et chargés par une coquille hôte, chacun correspondant à un domaine métier. La composition à l'exécution via Module Federation est la norme pour Angular, qui doit partager une seule copie du framework. Ils résolvent le couplage lié à la taille des équipes, mais ajoutent un coût opérationnel réel.