Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comparaison des micro-frontends avec des architectures alternatives

Comme pour toutes les stratégies architecturales, la décision d'adopter des micro-frontends doit être basée sur des critères d'évaluation guidés par les principes de votre organisation. Les micro-frontends présentent des avantages et des inconvénients. Si votre organisation décide d'utiliser des micro-frontends, vous devez mettre en place des stratégies pour relever les défis des systèmes distribués

Lors du choix d'une architecture d'application, les alternatives les plus populaires aux micro-frontends sont les monolithes, les applications n-tier et les microservices associés à une interface d'application mono-page (SPA). Toutes ces approches sont valables, et chacune d'elles présente des avantages et des inconvénients.

Monolithes

Une petite application qui ne nécessite pas de modifications fréquentes peut être livrée très rapidement sous forme de monolithe. Même dans les situations où une croissance significative est attendue, un monolithe est une première étape naturelle. Plus tard, le monolithe peut être retiré ou transformé en une structure plus flexible. En commençant par un monolithe, votre entreprise peut se lancer sur le marché, recueillir les commentaires des clients et améliorer le produit plus rapidement.

Cependant, les applications monolithiques ont tendance à se dégrader si elles ne sont pas soigneusement entretenues ou si la taille de la base de code augmente au fil du temps. Lorsque plusieurs équipes contribuent de manière significative à la même base de code, elles contribuent rarement toutes à sa maintenance et à son fonctionnement. Cela entraîne un déséquilibre des responsabilités, ce qui a un impact sur la rapidité et entraîne des inefficiences. Dans le même temps, le couplage involontaire entre les modules d'un monolithe entraîne des effets secondaires imprévus à mesure que la base de code évolue. Ces effets secondaires peuvent entraîner des dysfonctionnements et des pannes.

Applications de niveau N

Une application plus complexe dont le rythme d'évolution est relativement statique peut être construite sous la forme d'une architecture à trois niveaux (présentation, application, données), avec une couche REST ou GraphQL entre le frontend et le backend. Cela est beaucoup plus flexible et les équipes des différents niveaux peuvent se développer indépendamment dans une certaine mesure. L'inconvénient d'une application n-tier est qu'il est beaucoup plus difficile de déployer des fonctionnalités. Le frontend et le backend étant découplés par un contrat d'API, les modifications majeures doivent être déployées ensemble ou l'API doit être versionnée.

Envisagez le scénario courant suivant : si le lancement d'une nouvelle fonctionnalité nécessite une modification du schéma de données, les responsables du produit peuvent mettre plusieurs jours à s'entendre sur un ensemble de fonctionnalités avec une équipe de frontend. Ensuite, l'équipe du frontend demandera à l'équipe du backend de développer et de publier les fonctionnalités de son côté. L'équipe principale travaillera avec les propriétaires des données pour publier une mise à jour du schéma de base de données. Ensuite, l'équipe du backend publiera une nouvelle version de l'API, afin que l'équipe du frontend puisse développer et publier ses modifications. Dans ce scénario, la propagation de toutes les modifications vers la production peut prendre des semaines, voire des mois, car chaque équipe dispose de son propre backlog, de ses propres priorités et de ses propres mécanismes en matière de développement, de test et de publication des modifications.

Microservices

Dans une architecture de microservices, le backend est décomposé en petits services, chacun répondant à un problème commercial particulier dans un contexte limité. Chaque microservice est également fortement découplé des autres services en exposant un contrat d'interface clairement défini.

Il convient de mentionner que les contextes limités et les contrats d'interface devraient également exister dans des monolithes bien conçus et des architectures n-tier. Dans une architecture de microservices, toutefois, la communication s'effectue via le réseau, généralement via le protocole HTTP, et les services disposent d'une infrastructure d'exécution dédiée. Cela permet le développement, la fourniture et le fonctionnement indépendants de chaque service principal.

Choix de l'approche adaptée à vos besoins

Les monolithes et les architectures n-tier regroupent plusieurs domaines en un seul artefact technique. Cela facilite la gestion d'aspects tels que les dépendances et le flux de données interne, mais complique la fourniture de nouvelles fonctionnalités. Pour maintenir une base de code cohérente, une équipe investit souvent du temps dans le refactoring et le découplage en raison de la grande base de code qu'elle doit gérer.

Les applications développées par quelques équipes peuvent ne pas avoir besoin de la complexité supplémentaire associée au passage aux micro-frontends. Cela est particulièrement vrai si les équipes ne paient pas les pénalités liées à un couplage élevé et aux longs délais de publication des modifications.

En résumé, les architectures plus complexes et distribuées constituent souvent le bon choix pour les applications complexes et en évolution rapide. Pour les applications de petite ou moyenne taille, une architecture distribuée n'est pas nécessairement supérieure à une architecture monolithique, en particulier si l'application n'évolue pas de façon spectaculaire sur une courte période.