Création de micro-frontends

Les micro-interfaces permettent à vos équipes de gérer et de déployer indépendamment de petites parties de l'interface. Les complexités supplémentaires de cette architecture en valent-elles la peine pour votre organisation?

Avec la montée en puissance des petits services Web backend distribués ces dernières années, il n’est pas surprenant que les gens parlent maintenant de faire la même chose sur le frontend. «Micro frontends» est un terme qui est apparu pour la première fois en 2016 pour décrire de petites applications Web frontales découplées qui fonctionnent de concert pour créer une application complète.

En gardant un œil sur l'historique récent du développement Web, il est facile de retracer l'attrait des micro-frontends. Au fur et à mesure que les grandes équipes quittaient les bases de code monolithiques (1), elles divisaient leur code frontal (affichage et interface utilisateur) et backend (base de données, autorisation et logique métier) (2). Au fur et à mesure que la complexité et la taille de l'équipe augmentaient, de nombreuses entreprises se sont tournées vers les microservices (3), qui divisent la base de code du backend en éléments plus petits et déployables indépendamment. Bien qu'aucune architecture ne soit parfaite, de nombreuses entreprises ont adopté avec succès des microservices pour réduire la complexité et augmenter la vitesse de livraison.

Les micro-frontends (4) utilisent le même concept que les microservices pour améliorer les bases de code frontend. L'avènement et l'adoption généralisée de frameworks tels que React, Angular et Vue ont provoqué une augmentation de la complexité et de la logique métier gérée sur le frontend. Alors que les micro-frontaux nécessitent toujours une bonne architecture et utilisent souvent ces frameworks plus lourds, la capacité de gérer et de déployer indépendamment des éléments du frontend en petits morceaux plaît aux grandes organisations d'ingénierie.

À quoi ressemble un micro-frontend?

L'idée d'une micro-interface consiste à diviser l'interface utilisateur en morceaux par fonction du produit et à faire de chacun de ces éléments une base de code frontend déployable indépendamment. Bien que les divisions et la méthode de décomposition du code varient, il est utile d'imaginer un exemple spécifique.

Si vous exécutez une application de commerce électronique, la page de détails de votre produit peut avoir une barre de navigation, un bouton de connexion, un résumé du panier de l'utilisateur , les avis des acheteurs et certaines métadonnées sur le produit et une image. Dans une application frontale typique, vous auriez probablement toutes ces pièces divisées en composants mais vivant dans la même base de code. Dans une architecture micro frontend, vous pouvez diviser l'application en cinq bases de code différentes, chacune appartenant à une équipe responsable d'une fonctionnalité spécifique.

Cette architecture permettrait à l'Équipe des avis de déployer une nouvelle interface d'examen lundi, l'équipe du panier pour déployer les mises à jour du panier le mardi, et l'équipe de compte pour corriger un bogue de connexion mercredi, le tout sans affecter les principaux détails du produit sur la page.

Bien que nouvelle, cette structure introduit une certaine complexité. Plus d'applications signifient plus de code et plus de déploiements. Dans le reste de cet article, nous examinerons certains des avantages et des inconvénients des micro-interfaces. Nous verrons quelles décisions les responsables de l'ingénierie doivent prendre lors de l'adoption de cette architecture et vous aiderons à décider si elle convient à votre organisation.

Pourquoi Micro Frontends?

J'ai commencé à suggérer certaines des raisons pour lesquelles les développeurs

Strong Boundaries

Chaque développeur de logiciel pense à la séparation des préoccupations lors de la planification d'un nouveau projet. Bien que les micro-interfaces ne soient pas une exigence pour des bases de code frontales bien organisées, elles peuvent promouvoir des divisions explicites entre les responsabilités dans une application Web.

«Nous essayons de nous préparer à tomber dans le gouffre du succès en prenant de mauvaises décisions difficile, et les bons faciles. – Cam Jackson sur les micro-frontends

Petites bases de code

Les bases de code plus petites sont intrinsèquement plus faciles à raisonner. En supposant que vos limites sont bien définies, les équipes préféreront probablement les petites bases de code aux grandes. Cela dit, la configuration d'erreurs d'automatisation et de débogage qui dépassent les limites peut être un nouveau défi pour les micro-frontends.

Petits déploiements

À mesure que votre frontend se développe, des actions simples comme la mise à jour du cache ou l'effacement du CDN peuvent avoir un impact considérable sur les performances. Les micro-interfaces vous permettent de déployer de petites modifications sur des éléments de votre base de code plutôt que d'être obligé de mettre à jour le tout en un seul passage. Ces petits changements limitent également la portée des bogues car ils n'affecteront probablement que la partie du code avec laquelle ils interagissent.

Equipes autonomes

Enfin, chaque micro-interface de votre application peut être gérée par une seule équipe qui peut Choisissez le cadre, les bibliothèques et les modèles de conception qui correspondent le mieux à leurs besoins. Ces petites équipes autonomes sont confrontées à moins de goulots d'étranglement et d'approbation pour chaque décision, et cette structure permet à l'organisation d'expérimenter de nouveaux outils sans réécrire l'intégralité du frontend.

Inconvénients des micro-frontaux

Chaque style architectural comporte des compromis, et les frontends ne sont pas différents. Bien qu'ils résolvent certains problèmes épineux, en particulier pour les grandes équipes de logiciels d'entreprise, ils introduisent également un nouvel ensemble de problèmes. Si vous avez travaillé avec des microservices backend, vous êtes probablement au courant de ces compromis, mais il vaut la peine de les noter.

Duplicate Dependencies

«Certaines implémentations de micro frontend peuvent conduire à la duplication de dépendances, augmentant le nombre d'octets les utilisateurs doivent télécharger. » – Cam Jackson

Si vous imaginez avoir trois applications frontales qui chargent toutes leur propre framework frontend, vous pouvez voir à quelle vitesse les dépendances dupliquées peuvent ralentir votre application. C'est encore plus un problème avec les micro-frontends qu'avec les microservices d'arrière-plan, car chaque dépendance doit être transmise via Internet à vos utilisateurs plutôt que simplement compilée pour sur le serveur.

Siled Teams

Parce que les micro-frontends encouragent l'analyse de rentabilisation frontières entre les éléments, ils pourraient contribuer à une culture indésirable du «nous contre eux». Si vous autorisez des équipes à travailler avec différents frameworks frontend ou modèles de conception, vous risquez également d'introduire des frictions inutiles lorsque les développeurs veulent passer d'une unité à une autre.

Rigid Boundaries

Enfin, séparer complètement vos applications les rend plus plus difficile de les déplacer plus tard. Cela peut être une bonne chose dans une grande application établie, mais cela pourrait ralentir inutilement le développement d'une nouvelle application qui évolue rapidement.

Décisions à prendre avant d'adopter des micro-frontends

Si vous avez pesé le pour et le contre et a décidé qu'une architecture micro frontend valait l'investissement, il est temps de commencer à réfléchir aux détails d'implémentation. Étant donné que les micro-interfaces sont nouvelles, de nombreux problèmes résolus depuis longtemps dans les interfaces monolithiques traditionnelles doivent être repensés.

Cohérence de l'interface utilisateur

Par exemple, vous devez décider de la manière dont vous standardiserez le style de vos interfaces. Chargez-vous une seule bibliothèque de styles ou des bibliothèques individuelles pour chaque micro frontend? Aurez-vous un concepteur central qui garantira la cohérence, et si oui, comment allez-vous les empêcher de devenir un goulot d'étranglement? Comment allez-vous communiquer les changements ou les nouveaux styles aux autres équipes micro frontend?

«La cohérence UX est un aspect important. L'expérience utilisateur peut devenir un défi si l'équipe individuelle suit sa propre direction, il devrait donc y avoir un support commun pour garantir que l'UX n'est pas compromis. " – Agile Champs

Une solution consiste à utiliser une bibliothèque d'interface utilisateur standard comme Kendo UI qui fournit aux développeurs des solutions prédéfinies aux éléments stylistiques courants. Bien que vous ayez encore à décider comment et où charger ces composants, avoir une source centrale pour eux laissera moins de décisions de conception à chaque équipe.

Intégration

Un autre défi intéressant lors de l'adoption de micro-frontends est de décider comment et quand les intégrer. À un moment donné, toutes les petites applications doivent être compilées et servies aux utilisateurs sous la forme d'une seule application utilisable. Cette composition peut être faite sur le serveur en utilisant un outil standard comme Nginx ou un outil spécialisé comme Ara . Cela peut être fait au moment de la construction en compilant vos interfaces en tant que packages individuels dans une application shell. Cela peut être fait sur le frontend en utilisant iFrames ou un outil spécialisé comme single-spa .

Il n'y a pas de bonne réponse ici, mais les implications de votre décision peuvent être larges. L'intégration aura un impact sur la façon dont vous testez, livrez et construisez votre application, alors réfléchissez bien avant de commencer.

Partage de données

Enfin, envisagez le partage des données et la communication entre les composants. Devrez-vous répéter les appels d'API pour agréger les données, ou vos micro-interfaces auront-elles un seul état partagé? Comment vont-ils se connecter aux services backend dont ils ont besoin? Comment les changements d'un microfrontend seront-ils propagés à un autre? Comment allez-vous gérer les données d'authentification?

Le partage de données entre des interfaces avec des bases de code disparates n'est pas forcément facile. Au fur et à mesure que votre application évoluera, cela deviendra un aspect de plus en plus difficile de la maintenance et du développement.

Conclusion

Les meilleures pratiques pour les micro-interfaces continuent d'évoluer, mais il est clair qu'elles résolvent certains problèmes difficiles, en particulier pour les grandes équipes. La possibilité de déployer des éléments de l'application de manière indépendante, d'appliquer des limites et de choisir la meilleure technologie pour le domaine concerné est unique dans le développement frontal. En supposant que votre équipe dispose de l'expertise technique nécessaire pour résoudre certains des défis que présentent les micro-interfaces, le modèle pourrait valoir l'investissement.