Smashing Podcast Épisode 6 Avec Luca Mezzalira : que sont les micro-interfaces ?

Nous terminons cette année avec un autre podcast Smashing ! Cette fois, nous parlerons de micro-interfaces. Qu'est-ce qu'une micro-interface ? En quoi est-ce différent du genre d'approche que nous pourrions adopter en ce moment? Découvrons le pionnier du micro-frontend, Luca Mezzalira.

Afficher les remarques

Mise à jour hebdomadaire

• "Ajout de fonctionnalités dynamiques et asynchrones aux sites JAMstack", Jason Lengstorf
• "Outils de données quantitatifs pour les concepteurs UX", Adonis Raduca
• "Création de compétences vocales pour Google Assistant et Amazon Alexa", Tris Tolliday
• "Au-delà du Sprint 0 : une alternative pour intégrer les équipes", Shamsi Brinn
• "Aider les navigateurs à optimiser avec la propriété CSS Contain", Rachel Andrew

Micro-interfaces

• Site de Luca Mezzalira
• Lucas sur Twitter
• "Micro-frontends, l'avenir des architectures frontend" sur Medium
• Plus d'articles de Luca sur les micro-interfaces peuvent être trouvés sur son compte Medium
• Le livre de Luca "Front-End Reactive Architectures"

Transcription

Drew McLellan : C'est un développeur Google expert des technologies Web et responsable de la communauté JavaScript de Londres. Avec plus de 15 ans d'expérience, il travaille actuellement en tant que vice-président de l'architecture, concevant la plate-forme de vidéo sportive DAZN, qui fournit du contenu sportif à la demande à des millions d'utilisateurs qui regardent tous en direct. Il est l'auteur du livre Front-End Reactive Architectures for Apress et est également réviseur technique pour Apress, Packt Publishing, Pragmatic Bookshelf et O'Reilly, ainsi qu'un conférencier expérimenté lors de conférences techniques dans le monde entier. Il est italien, arbore une belle barbe et possède clairement une connaissance approfondie de la plate-forme Web. Mais saviez-vous qu'il a un jour traversé l'Amérique du Sud sur une autruche ? Mes amis fracassants, veuillez accueillir Luca Mezzalira. Salut Luca. Comment vas-tu?

Luca Mezzalira : Je suis fracassant.

Drew : Je veux vous parler aujourd'hui du sujet des micro-interfaces. Maintenant, c'est un concept qui est complètement nouveau pour moi, certainement de par son nom, et je pense que c'est aussi nouveau pour beaucoup de nos auditeurs. Avant d'aborder les micro-frontends eux-mêmes, je suppose que nous devrions comprendre le problème que vous cherchez à résoudre avec eux. Alors peut-être pourriez-vous nous dire un peu comment vous voyez les applications d'une manière plus traditionnelle et quel genre de problèmes ces choses rencontrent et auxquelles les micro-frontends pourraient être la solution ?

Luca : D'accord, c'est un bon point de départ, à mon avis. Ainsi, généralement, lorsque vous implémentez ou concevez un nouveau projet de terrain vierge et que vous souhaitez travailler avec des applications frontales, vous disposez de quelques architectures que vous pouvez exploiter. Vous pouvez utiliser une application à une seule page, vous pouvez utiliser une application de rendu côté serveur ou vous pouvez utiliser une application multipage composée de simples pages HTML. Évidemment, ce sont des options super valables et je pense qu'elles sont très utilisées par de très nombreux développeurs. Le vrai problème que nous essayons de résoudre ici est de savoir comment vous pouvez adapter ces concepts avec des équipes distribuées à des centaines de développeurs travaillant sur la même base de code, car la réalité, c'est lorsque vous travaillez sur ces plates-formes en particulier, lorsque vous pensez à Une plateforme SaaS par exemple, vous devez avoir plusieurs développeurs et plusieurs équipes qui travaillent sur le même projet. Et évidemment, la façon dont vous faites, par exemple, l'acquisition ou la rétention est complètement différente de la façon dont vous exposez le catalogue ou dont vous montrez une partie spécifique d'une plate-forme.

Luca : Donc, d'après mon expérience, je travaille beaucoup avec des applications d'une seule page. Je travaille avec une application de rendu côté serveur, mais à un moment donné dans DAZN, on me demanderait de réfléchir à un moyen de faire évoluer notre équipe technique. Et je dois venir… si pour le backend nous avons une solution qui sont des microservices dans ce cas, nous pouvons donc faire évoluer nos API indépendamment et prendre en considération l'échelle et le volume pour un débit spécifique sur une API spécifique. Sur le front-end, vraiment, c'est vraiment plus difficile parce que si vous y réfléchissez, vous n'avez pas de problème technique à résoudre lorsque vous devez évoluer, si vous utilisez une application monopage, par exemple. Probablement pour un rendu côté serveur, vous en avez, mais sur une application d'une seule page, par exemple, il est distribué par nature car il est côté client, côté client différent.

Luca : Donc, la seule chose qu'ils chargent, ce sont juste quelques fichiers statiques comme CSS, HTML et JavaScript qui sont servis par CDN, et dans ce cas, vous pouvez évoluer en conséquence, ce n'est pas un gros défi. Mais le véritable défi est de savoir comment faire évoluer les équipes travaillant sur la même plate-forme, car parfois les défis auxquels une équipe est confrontée peuvent être complètement différents des défis auxquels est confrontée une autre équipe, et généralement ce que vous faites est d'essayer de trouver beaucoup de compromis entre les choses. Parce que si vous réfléchissez, essayons de penser à un cas d'utilisation normal. Donc, généralement, lorsque vous démarrez une plate-forme, vous commencez petit. Donc, vous essayez de créer cette application rapide d'une seule page, ainsi que vous avez votre monolithe, donc vous venez de tout configurer dans votre CICD une seule fois pour le front-end et le back-end, puis vous commencez à itérer sur votre logique. Mais la réalité est que lorsque vous avez du succès, vous devez faire évoluer cette partie, et ce n'est pas toujours le maintien de la même architecture qui pourrait, disons, créer des avantages pour votre entreprise, car vous pouvez peut-être trouver des goulots d'étranglement.

Luca : Revenons maintenant à la partie application d'une seule page. Donc si on veut faire évoluer une partie applicative d'une seule page, le défi n'est pas technique, c'est avec des humains si vous voulez. Alors, comment pouvons-nous faire évoluer les équipes travaillant sur la même application. Donc, ce que j'ai fait il y a quelques années, c'est que j'ai commencé à examiner une architecture possible et des principes qui me permettraient de faire évoluer le front-end ainsi que le back-end. Travaillez donc sur les principes du backend afin que vous puissiez trouver les microservices. J'ai commencé à regarder les différentes solutions et ils sont sortis avec les micro-frontends qu'au début nous ne l'appelions même pas comme ça parce qu'évidemment il y a des années il n'y avait pas, disons, ce nom pour cette architecture spécifique .

Luca : Mais la réalité est de prendre un monolithe, donc une application d'une seule page et de la découper de manière à nous permettre de nous concentrer sur un petit problème. Donc, un problème plus petit que l'ensemble de l'application et essayer de le résoudre de la meilleure façon possible. Techniquement parlant. Évidemment, cela conduit à avoir des éléments indépendants de votre application frontale qui pourraient être déployés en production sans affecter tous les autres. Donc, le défi essentiellement pour Micro-frontend est d'essayer de trouver un moyen de prendre une application d'une seule page ou une application rendue côté serveur et de créer un artefact de ceux-ci, disons, aussi près que possible d'un domaine métier, et peut être déployé indépendamment .

Drew : Donc, je veux dire que vous avez mentionné les micro-services en arrière-plan. Donc, conceptuellement, c'est une sorte de solution similaire au problème. Les microservices servent sur le back-end, mais sont transférés sur le front-end. Est-ce une équivalence approximative ou est-ce plus impliqué là-dedans?

Lucas : Oui. Non, c'est un moyen de résoudre le même problème qu'il essaie de résoudre les microservices sur le back-end mais sur le front-end en ce moment. Habituellement, quand j'ai commencé ce voyage au début, vous savez, vous commencez à y penser et vous commencez à évaluer différentes approches. Et au cours des derniers mois, j'ai proposé ce qu'ils appellent, le cadre de décision Micro-frontend qui consiste essentiellement en quatre étapes qu'ils utilisent pour, disons que vous identifiez une approche pour Micro-frontend, parce que si jusqu'à présent, nous choisissez généralement un framework qui a conçu l'architecture pour nous et nous l'implémentons au-dessus de leur architecture. Si vous pensez angulaire ou pensez à React ou Redux. Vous avez toutes les pièces nécessaires, mais vous ne prenez pas de décisions architecturales. Vous prendriez des décisions de conception ou de mise en œuvre en plus de cette architecture spécifique.

Luca : Donc, sur Micro-frontend, vous devez commencer à revenir en arrière. Nous devons donc réfléchir à la façon dont nous voulons d'abord découper notre application. Il y a donc généralement deux options pour cela. Vous pouvez trancher horizontalement, de sorte que vous pouvez avoir plusieurs micro-interfaces dans la même vue ou vous pouvez trancher verticalement. Par conséquent, vous chargez toujours un micro-frontend à la fois. Et ces décisions sont tout à fait essentielles car elles entraîneront ensuite en cascade certaines autres options que vous avez en fonction de la décision initiale à prendre. Donc, la première, comme je l'ai dit, vous décidez comment vous voulez découper votre application. La seconde est la façon dont vous souhaitez composer votre application. Vous voulez donc avoir, par exemple, un shell d'application qui charge un ou plusieurs micro-frontends dans la même vue. Vous voulez avoir, je ne sais pas, un serveur d'applications qui compose différents fragments de vos applications, donc différents Micro-frontend, puis sert la vue finale à votre utilisateur. Ou vous voulez utiliser edge-side inclus, c'est une norme qui se trouve à l'intérieur des CDN afin de composer une page et de les servir là-bas.

Luca : Ce sont trois des options que vous avez. Et puis, en dehors de la composition, vous devez réfléchir à la façon dont vous voulez router. Alors, comment vous dirigez-vous depuis, je ne sais pas, /login ou /signin vers la partie catalogue ou un objet de détail spécifique. Ici aussi, vous avez comme trois options. Vous pouvez le faire au niveau du serveur d'application, vous pouvez le faire au niveau CDN avec Lambda Edge ou tout autre travailleur Web dans CloudFlare ou toute autre chose. Ou vous pouvez faire un site client. Vous avez donc une logique à l'intérieur de votre shell d'application qui vous dit, d'accord, maintenant pour cette URL spécifique, vous devez charger une autre vue ou une autre micro-interface. Et le dernier bit est la façon dont vous communiquez avec Micro-frontend.

Luca : Donc, généralement, si vous avez plusieurs micro-interfaces sur la même page, la gestion de cette communication est plus complexe, car vous devez maintenir les différentes micro-interfaces indépendantes. Cela signifie donc que vous ne pouvez pas avoir de référence sur la structure de la page. Ainsi, vous pouvez généralement utiliser des éléments tels que des événements personnalisés ou un compteur d'événements injecté dans chaque micro-interface. Et puis les micro-frontend communiquent ensemble. Évidemment, dans l'autre cas, lorsque vous avez, disons, une séparation verticale de votre micro-frontend, c'est beaucoup plus facile, car à l'intérieur de la verticale, la représentation d'une micro-frontend verticale est une application à une seule page ou une seule page. Et dans ce cas, il est plus facile de dire créer et partager en ayant un état partagé sur l'ensemble du micro-frontend.

Luca : Ensuite, si vous envisagez d'avoir plusieurs micro-interfaces ensemble, vous devez éviter d'avoir des états partagés entre les micro-interfaces, car sinon vous couplez des choses. Au lieu de tout le concept ici, c'est le découplage et le déploiement indépendant. Et donc disons que les défis d'une division horizontale, qui est la première décision que vous devriez prendre ou d'une division verticale, sont complètement différents, et nous devons très bien savoir lequel correspond à notre cas d'utilisation.

Drew : Plutôt qu'une solution technique spécifique, les micro-interfaces ressemblent beaucoup à un modèle de conception que vous implémenteriez dans n'importe quelle technologie appropriée au problème particulier que vous essayez de résoudre ?

Luca : Ouais, plus que la technologie, je veillerais à ce que nous choisissions la bonne architecture pour le bon travail. Juste pour vous donner un exemple, je parlais… il y a un framework célèbre, assez nouveau pour Micro-frontend, il s'appelle le framework Luigi, qui a été publié par SAP open source. Ce qu'ils font, c'est créer des iframes dans lesquels ils intègrent leur micro-frontend. Alors maintenant, si vous pensez à cela, disons, en utilisant des iframes de nos jours, vous êtes sur un site Web public qui, peut-être que le référencement ou d'autres fonctionnalités obligatoires, cela pourrait être problématique.

Luca : Mais dans le cas de SAP, si vous pensez à cela, ils ont comme une application d'entreprise où ils peuvent contrôler le navigateur que l'utilisateur utilise, ils peuvent contrôler l'environnement, ils n'ont pas besoin d'être disponibles sur une multitude ou version différente du navigateur. Donc, pour eux, ces choses leur permettent d'avoir certaines zones de l'application qui sont constantes et certaines zones qui changent indépendamment sans aucun problème. Mais évidemment, une solution iframe ne fonctionnerait pas dans une autre situation. Juste pour donner un autre exemple, Spotify, nous utilisons des iframes au début. En fait, la publication du bureau est toujours composée de plusieurs iframes et chaque iframe est une minuscule application qui fait, je ne sais pas, juste un lecteur de musique ou juste leur recommandation, quoi qu'il en soit. Ils essaient d'avoir la même approche sur le Web, mais ils l'ont rejetée cette année afin de revenir à une application d'une seule page.

Luca : Et cela signifie qu'ils expliquent pourquoi dans le blog technique, ils disaient que si vous appliquez cela à des millions d'utilisateurs qui utilisent des iframes, ils doivent charger à chaque fois le même fichier de fournisseurs. Et puis vous avez comme beaucoup de dépendances dupliquées et le temps d'interaction avec votre page serait plus long. Donc, en réalité, cette approche pourrait convenir à certains cas d'utilisation, mais elle ne devrait pas convenir à tous. C'est pourquoi je dis, comme je l'ai décrit précédemment, si vous avez un cadre de décision qui vous aide à résoudre ces problèmes et que vous pouvez commencer à dire, d'accord, j'ai découpé l'application de cette manière, donc j'ai ces options qui sont disponibles quand je veux composer, quand je veux router, quand je veux communiquer, il doit vous guider afin d'avoir la bonne décision au bon moment.

Luca : Alors évidemment à part ces quatre décisions, il y en a beaucoup d'autres. Comme la façon dont vous créez une cohérence dans le système de conception que vous avez sur tout le micro-frontend. Ou je ne sais pas comment vous gérez les dépendances et évitez le conflit de dépendances à l'intérieur du micro-frontend, mais la réalité est que ces quatre décisions que j'ai mentionnées précédemment vous permettront ensuite de prendre toutes les autres de manière rapide sans avoir le problème de la réflexion excessive, qui est la meilleure solution car vous avez déjà posé la pierre angulaire, les quatre piliers, qui vous permettront de prendre toutes les autres décisions… je ne dis pas de manière simple, mais de manière plus rapide qu'un bilan ou le spectre des opportunités.

Drew : Vous avez mentionné précédemment la façon dont Micro-frontend peut aider avec le type de structure d'équipes au sein de votre organisation et avoir beaucoup de personnes travaillant sur la même application. Quelles sont alors certaines des implications et cela fait-il une différence si vos équipes sont réparties ou colocalisées ou y a-t-il des défis auxquels ils sont confrontés ?

Lucas : Oui. Je peux donc vous raconter quelle est l'histoire de DAZN. C'est l'entreprise pour laquelle je travaille. Actuellement dans DAZN, nous avons eu comme un beau défi. Nous avons donc actuellement plus de 300 personnes qui travaillent sur le front et le back-end de notre plateforme. Il s'agit d'une plate-forme OTT qui diffuse en direct lors d'événements sportifs dans le monde entier. Et ce qui est intéressant, c'est si nous savons gérer plus ou moins tous les microservices et si nous avons des équipes réparties. Nous avons donc quatre centres de développement. Nous voudrions mettre des équipes dans chaque centre de développement sur le front, et nous avons essayé cette approche et cela fonctionne plutôt bien. Ainsi, avec Micro-frontend, nous avons pu fournir différents domaines d'activité à différents endroits et permettre la communication croisée entre les équipes au sein d'un domaine d'activité spécifique, très parce que le pire des cas est que si vous devez parler avec une autre équipe sur votre même domaine d'activité , vous atteignez juste la distance de marche de votre bureau. Si au lieu de cela vous avez besoin de discuter de choses spécifiques au sein de l'équipe de distribution, alors peut-être avec quelqu'un à Londres au lieu d'Amsterdam, ou au lieu d'une entreprise en Pologne, il vous suffit d'organiser un appel.

Luca : Mais ces types de communication sont plus rares que ceux qui se produisent entre les équipes au même endroit. Et c'est pourquoi nous avons commencé à travailler là-dessus. Donc, la première chose qu'ils ont faite a été de regarder comment nos utilisateurs interagissaient avec notre site Web, comment l'entreprise était structurée. Et lorsque nous identifions les quatre domaines clés sur lesquels nous travaillons, qui sont actuellement l'acquisition et la rétention, disons le portage de leur application principale sur plusieurs téléviseurs et mobiles et ayant le domaine principal qui pour nous est le lecteur vidéo et la phase de découverte de notre contenu. Et enfin tous les éléments du back office. J'ai pu identifier ces quatre domaines et nous ces quatre domaines que nous avons attribués à chaque centre de développement.

Luca : Évidemment, il existe des points de contact entre ces domaines, mais il existe également des moyens d'atténuer et d'organiser un atelier initial avec les différentes équipes qui se trouvent à différents endroits, puis de travailler sur le même contrat d'API, par exemple, ou le même objectif avec quelques points de contrôle pendant le développement. Mais la bonne chose de l'approche qui a permis d'approcher avec Micro-frontend est le fait que nous comprenons enfin profondément comment notre système fonctionnait. Nous nous asseyons et nous analysons comment nous étions structurés et nous avons changé non seulement la façon dont nous étions affectés, mais aussi la façon dont l'entreprise fonctionnait. Et c'était une sorte d'approche différente de ce qu'ils ont vu jusqu'à présent. Mais cela prouve que cela fonctionne plutôt bien dans le cas où chaque équipe peut interagir avec l'équipe du même emplacement dans le même domaine.

Luca : Donc, ils parlent exactement le même langage si vous parlez de la conception axée sur le domaine. Et c'est que s'ils ont besoin d'interagir avec d'autres équipes, ils peuvent littéralement partager l'atelier ou voler vers un autre centre de développement et c'est moins qu'un problème. Mais de cette façon, disons, augmentez le débit et réduisez les frais généraux de communication, ainsi que l'étendue des dépendances qui se produisaient dans d'autres situations sur lesquelles ils travaillaient.

Drew : Et est-ce que toutes ces équipes doivent utiliser comme un framework JavaScript standardisé ? Ont-ils tous besoin de coder dans les mêmes choses, ils doivent tous être React ou Angular ou pour permettre l'interopérabilité entre eux ou les gens peuvent-ils utiliser différentes choses pour différents Micro-frontend ?

Lucas : Ouais. Donc, dans DAZN, nous avons décidé de découper verticalement notre micro-frontend et c'est une décision qui nous a permis d'avoir la liberté de choisir la technologie dont nous avons besoin pour chaque micro-frontend. Considérant que chaque fois que nous chargeons une micro-interface à la fois, cela signifie par exemple que la façon dont nous avons une page de destination est différente du parcours de connexion / inscription. Nous pouvons donc mettre à jour… nous utilisons principalement React pour le moment. Mais si, par exemple, je me souviens quand React 16 était une version que nous avons pu publier en production React 16, aussi si ce n'était pas dans la version stable pour juste une page de destination et voir si cela fonctionnait sans affecter tous les autres équipes.

Luca : Et puis à leur propre rythme, à leur propre rythme, ils mettaient à jour leurs propres trucs. Cela nous permet donc aussi, disons, d'essayer de nouvelles technologies ou de nouvelles hypothèses que nous avons sur l'application existante avec un certain nombre d'utilisateurs. Parce que nous implémentons également les versions candidates pour le front-end. Nous mettons en œuvre, disons, plusieurs pratiques qui nous permettent d'essayer certains moments de la production et de voir comment les choses fonctionnent.

Luca : La beauté de ces approches est que nous pouvons décider indépendamment d'avoir le bon outil pour le bon travail plutôt que d'avoir un dénominateur commun sur l'ensemble de la pile. Parce que comme vous pouvez l'imaginer, lorsque vous avez commencé à travailler sur un projet, la décision que vous avez prise les premières années est probablement différente de la décision que vous avez prise dans une trajectoire où l'entreprise grandit, l'entreprise évolue et ceux-ci sont devenus plus matures et le défi est complètement différent. Ce ne serait donc pas assez flexible ou assez agile, si vous y réfléchissez, le fait que nous nous en tenions à la même décision que nous avons prise il y a deux ans. Notamment une institution comme DAZN, que l'on passe de quasiment zéro à 3000 salariés en trois ans. Donc, comme vous pouvez l'imaginer, c'était une croissance massive et c'était une croissance massive pour l'entreprise ainsi que pour la base d'utilisateurs.

Drew : Existe-t-il un moyen établi pour les différentes micro-interfaces de partager des données et de communiquer entre elles, par exemple, juste pour rester en phase avec la même vue ou existe-t-il un moyen de le faire ?

Lucas : Oui, il y en a. Cela dépend du cadre de décision, de la voie que vous allez emprunter. Parce que si vous allez prendre la tranche verticale, c'est devenu très facile. Donc, ce que nous avons pour communiquer via Micro-frontend est un shell d'application qui se charge dans Micro-frontend à l'intérieur de lui-même. Et ce qu'il fait, c'est stocker tout ce qui doit être, disons, partagé entre différentes micro-interfaces ou sur un stockage Web, soit une session, soit un stockage local, soit en mémoire. Et ensuite, sur la base de ces informations, le micro-frontend est chargé, peut récupérer ces informations depuis le shell de l'application, puis les consommer, les modifier ou les modifier. Cela dépend entièrement de la façon dont vous découpez l'application, mais dans ce cas, juste pour donner un exemple, si vous pensez que lorsque vous êtes des utilisateurs authentifiés et que vous devez accéder à la page de connexion, lorsque vous êtes connecté et que les API sont consommées et ils fournissent un jeton JWT, Micro-frontend les transmet au shell de l'application et au shell de l'application, nous avons enregistré leur stockage Web.

Luca: Ensuite, après que le shell de l'application charge la nouvelle zone authentifiée pour cette application spécifique et ces zones authentifiées, ils récupèrent le jeton JWT du shell de l'application et effectuent soit un jeton d'accès d'actualisation, soit valident certaines données à partir du Jeton JWT. Donc, il utilise essentiellement les informations qui ont été produites par un autre micro-frontend à leur propre volant.

Drew : Cela semble être un concept très intéressant et je vois potentiellement beaucoup d'avantages à travailler de cette façon, mais cela ne peut pas être sans défis, assurément. Y a-t-il des choses particulières qui sont plus difficiles à gérer lors de l'architecture des choses de cette manière ?

Luca : Je pense que le principal défi que je vois est avant tout le changement de mentalité. Parce qu'avant, nous avions l'habitude d'avoir, disons, les responsables techniques ou les développeurs principaux qui décidaient de tout autour d'une application entière prenant toutes les décisions. Maintenant, finalement, nous passons de cette entité centralisée à une entité décentralisée qui est locale pour chaque État. Comme vous pouvez l'imaginer, cela pose des défis car si avant nous avions quelqu'un qui traçait le chemin, c'est maintenant que nous avons, disons, plusieurs personnes au sommet définissant le bon chemin dans leur domaine, et c'est un énorme changement d'état d'esprit.

Luca : D'un autre côté, je pense que la complexité consiste parfois à accepter que faire une mauvaise abstraction pourrait être, disons, plus cher que de dupliquer du code. Et c'est que je sais qu'il y a quelque chose que j'ai trouvé très difficile dans la gestion des développeurs parce qu'ils pensent, "D'accord, maintenant je peux réutiliser cet objet ou cette bibliothèque spécifique des centaines de fois dans le projet", mais la réalité est très différente. J'ai vu une bibliothèque de composants abstraite et ils ont passé beaucoup de temps à en faire le meilleur code de tous les temps ou le meilleur dans une forme parfaite. Mais la réalité n'a été utilisée que deux fois. Donc l'effort de faire ça, ce n'était pas exactement ça. J'ai vu de l'autre côté des bibliothèques qu'elles commençaient avec quelques cas d'utilisation pour un composant spécifique. Et puis ces cas d'utilisation sont devenus 10, puis le code est devenu impossible à maintenir.

Luca : Essayer d'ajouter une nouvelle fonction dans le même composant pourrait donc être plus risqué qu'avantageux. Je pense donc que l'autre chose que nous devons comprendre avec Micro-frontend est à quel point nous voulons le partager et combien nous voulons le dupliquer. Et il n'y a pas de mal, honnêtement, à dupliquer. Dans notre cas, par exemple, nous avons une duplication du pied de page et de l'en-tête, et nous l'avons fait principalement parce que nous avons changé environ trois fois l'en-tête en quatre ans. Donc, comme vous pouvez l'imaginer, le fait que nous les centralisions, que nous soyons affectés à une équipe et que nous créions une dépendance externe pour toutes les équipes, toutes les centaines de développeurs que nous avons, est plus disons un problème qui profite à l'entreprise car nous n'ajoutons pas une valeur énorme.

Luca : En même temps, nous refactorisons actuellement nos bibliothèques partagées qui seraient des bibliothèques de paiement, car évidemment le paiement a une certaine logique derrière cela et si nous voulons changer une fois, nous ne voulons pas l'appliquer deux fois dans plusieurs parties du code. Nous voulons n'avoir qu'une seule bibliothèque qui soit une source de vérité, mais pour l'en-tête et le pied de page, même s'il y a un écart ou pour un pixel ou s'il y a une fonction qui est déployée comme une semaine plus tard, cela ne blessera pas le application.

Drew : Y a-t-il donc des signes révélateurs que les gens devraient rechercher lorsqu'ils évaluent une application et se disent : « Oh oui, ce serait un bon candidat pour passer à une sorte d'architecture micro-frontend ? »

Luca : Oui, donc ma suggestion serait avant tout de ne pas démarrer un projet entièrement nouveau avec Micro-frontend à moins que nous ne sachions exactement comment il doit être construit. Et généralement, il est très peu probable que vous disposiez de ces informations car, en particulier si vous avez une nouvelle plate-forme ou un nouveau projet et que c'est la première fois que vous travaillez dessus, il peut être difficile de trouver ces informations. Habituellement, ce que je suggère, c'est de commencer avec une architecture existante qui serait donc une application d'une seule page, puis de la faire évoluer. En particulier, par exemple, j'ai trouvé, je pense que l'utilisation de Micro-frontend pour les applications héritées ou lorsque nous voulons remplacer une partie spécifique de l'application ou lorsque nous avons un projet que nous voulons faire évoluer et mettre à l'échelle pour plusieurs équipes, ce sont trois cas d'utilisation que je ressens très fort pourrait convenir à l'architecture Micro-frontend. Évidemment, cela ne veut pas dire qu'à partir de maintenant, tout doit être fait en micro-frontend, car le micro-frontend n'est pas du tout la solution miracle.

Luca : Ce qu'ils sont, c'est une architecture supplémentaire que nous pouvons exploiter dans le monde frontal. Et jusqu'à présent, nous avions un certain nombre d'architectures, maintenant nous en avons une supplémentaire. Mais c'est beaucoup de défis parce qu'évidemment vous devez, si avant le rendu côté serveur ou une application d'une seule page, il y a des modèles clairs qui ont été explorés puis implémentés par plusieurs frameworks et ainsi de suite. Avec Micro-frontend actuellement, c'est une façon de faire les choses. Mais l'ajout du cadre de décision devrait probablement permettre aux gens de prendre les bonnes décisions pour leurs cas d'utilisation. Parce qu'il y a souvent beaucoup d'idées fausses sur ce qu'est le micro-frontend et comment il doit être utilisé. Et beaucoup de gens pensent que peut-être, disons, sont mauvais pour, je ne sais pas, avoir trop de bibliothèques dans une vue ou d'autres choses.

Luca : La réalité est que vous devez comprendre profondément le concept, comprendre comment le mettre en œuvre, puis vous pouvez commencer à travailler dessus. Je suis tout à fait d'accord qu'il y a des défis techniques et qu'il y a beaucoup de décisions que vous devez prendre et vous ne pouvez pas simplement commencer tout de suite avec un éditeur devant vous en écrivant du code et en pensant, d'accord, maintenant je crée un micro-frontend architecture. Parce que vous devez comprendre le concept, comprendre le contexte et créer, également la gouvernance autour de cela parce que la complexité n'est pas seulement d'écrire le code, c'est aussi comprendre comment toutes les pièces s'emboîtent dans la partie CICD, la partie SEO et ainsi de suite.

Luca : Donc Micro-frontend fournit, disons, un niveau de flexibilité et nécessite beaucoup d'efforts pour définir le droit de gouvernance. Parce que lorsque vous avez la bonne gouvernance, tout se passera bien. Souvent et malheureusement je dirais trop souvent, j'ai vu des entreprises où elles ne consacrent pas assez de temps à la gouvernance, à la compréhension du CICD par exemple, parce qu'elles ne pensent pas que ce soit important. Mais au lieu de cela pour Micro-frontend, comme pour les microservices, avoir le droit d'automatisation vous permettra d'accélérer le développement. Si vous ne consacrez pas suffisamment de temps à l'automatisation, vous risquez d'avoir plus de fardeau que d'avantages.

Drew : Je suppose que c'est comme tant de choses dans le monde du développement Web où les gens risquent de plonger dans une solution technique avant d'avoir vraiment compris le problème. Et il semble qu'avec Micro-frontend, vous devez voir le problème, puis implémenter la solution pour savoir quel problème vous résolvez. Je suppose que la nature même de Micro-frontend rend très facile de commencer à s'intégrer dans une application existante, de repérer un petit problème et de l'échanger avec un Micro-frontend afin de résoudre ce problème. Est-ce une suggestion raisonnable?

Luca : Oui, je dirais que oui. Dans ce cas, la seule chose que je suggérerais si nous commençons de cette manière est de regarder davantage le découpage vertical que le découpage horizontal, car sinon vous devez résoudre tant de problèmes, supposons que par exemple vous utilisez Angular et vous souhaitez passer à une nouvelle version d'Angular. Si vous avez besoin d'avoir deux versions angulaires vivant ensemble sans utiliser I-frame, cela pourrait être compliqué, voire impossible. Donc si vous commencez, vous l'aspect non pas de… si vous cochez le challenge, non pas du point de vue technique, mais du point de vue business. Peut-être par exemple, vous pouvez prendre, je ne sais pas, la partie de connexion sur laquelle vous voulez écrire avec une version différente ou la même version mais plus de version de mise à jour d'un framework et cela pourrait être un bon moyen. Et puis vous traversez le chemin. Cela pourrait être un bon moyen de remplacer lentement mais régulièrement une application spécifique.

Luca : Ce que nous avons fait dans notre cas, c'est essentiellement appliquer le modèle strangler qui est un modèle bien connu pour les microservices, mais sur le front-end. Donc basé sur l'URL et basé sur le navigateur et le pays de l'utilisateur. Si lentement mais régulièrement, en gros, nous tuions le monolithe, qui dans ce cas était une application d'une seule page, publiant notre nouvelle application plus souvent et voyons les comportements des utilisateurs, si cela améliorait l'expérience, cela causait un problème sur notre système ou non. Et cela nous a permis de fournir une valeur immédiate à l'entreprise, mais en même temps nous a permis de tester nos hypothèses et de voir si nous allions dans la bonne direction ou non.

Drew : Cela semble être une solution très attrayante à certains problèmes auxquels, je suis sûr, beaucoup de gens sont confrontés. Si, en tant que développeur, je voulais commencer à en savoir plus sur Micro-frontend, où serait un bon point de départ ?

Luca : Oui, donc actuellement je passe beaucoup de mon temps libre à essayer de plaider autour de ces architectures, parce que je pense qu'il y a beaucoup d'idées fausses. Sur mon compte Medium. J'ai écrit plusieurs articles qui y sont également disponibles. A enregistré beaucoup de vidéos dans des conférences que vous pouvez retrouver sur YouTube sans aucun problème. Et l'autre chose que je suggérerais si vous cherchez un exemple de code sur certains frameworks, celui que je recommanderais pour commencer est un seul SPA, principalement parce qu'il a une approche de découpage vertical, il est plus facile de le prendre et vous pouvez commencer à comprendre l'avantage de cette architecture. Ensuite, il y en a beaucoup d'autres qui sont disponibles. Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.