Que sont les microfrontends?

Dans cet épisode du Smashing Podcast, nous parlons de micro-frontends. Qu'est-ce qu'une micro-interface et en quoi est-ce différent du type d'approche que nous pourrions adopter en ce moment? Drew McLellan découvre le pionnier du micro-frontend, Luca Mezzalira.

Afficher les notes

Mise à jour hebdomadaire

Micro-Frontends

Transcription

Drew McLellan: C'est un expert développeur Google sur les technologies web et gestionnaire de la communauté JavaScript de Londres. Avec plus de 15 ans d'expérience, il travaille actuellement comme vice-président de l'architecture, concevant la plate-forme 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 que conférencier expérimenté lors de conférences techniques dans le monde entier. Il est italien, arbore une belle barbe et a clairement une connaissance approfondie de la plate-forme Web. Mais saviez-vous qu'il a déjà traversé l'Amérique du Sud sur une autruche? Mes amis fracassants, veuillez accueillir Luca Mezzalira. Salut Luca. Comment allez-vous?

Luca Mezzalira: Je fracasse.

Drew: Je veux vous parler aujourd'hui du sujet des micro-frontends. Maintenant, c'est un concept qui est complètement nouveau pour moi, certainement par son nom, et je m'attends à ce qu'il soit nouveau pour beaucoup de nos auditeurs aussi. Avant d'entrer dans les micro-frontaux eux-mêmes, je suppose que nous devons comprendre le problème que vous cherchez à résoudre avec eux. Alors peut-être pourriez-vous nous en dire un peu plus sur la façon dont vous voyez les applications d'une manière plus traditionnelle et sur quels types de problèmes ces choses peuvent-elles se produire qui pourraient être des micro-frontends?

Luca: D'accord, c'est un bon point de départ, à mon avis. Donc, généralement, lorsque vous implémentez ou concevez un nouveau projet de champ vert et que vous souhaitez travailler avec des applications frontales, vous disposez de quelques architectures que vous pouvez exploiter. Vous pouvez utiliser une application de page unique, vous pouvez utiliser une application de rendu côté serveur ou vous pouvez utiliser une application de plusieurs pages composée de simples pages HTML. Évidemment, ce sont des options super valides et je pense que très utilisées par de 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é est lorsque vous travaillez sur ces plates-formes en particulier, lorsque vous pensez à Par exemple, sur la plate-forme SaaS, vous devez avoir plusieurs développeurs et plusieurs équipes qui travaillent sur le même projet. Et évidemment, la façon dont, par exemple, vous effectuez l'acquisition ou la rétention est complètement différente sur la façon dont vous exposez le catalogue ou comment vous montrez une partie spécifique d'une plate-forme.

Luca: Alors maintenant, d'après mon expérience, je travailler beaucoup avec une application d'une seule page. Je travaille avec une application de rendu côté serveur, mais à un moment donné dans DAZN, je serais invité à réfléchir à un moyen de faire évoluer notre équipe technique. Et je dois venir … si pour le backend, nous avons une solution qui est des microservices dans ce cas, afin que nous puissions faire évoluer nos API indépendamment, et prendre en considération que 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 d'une seule page, 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, différent côté client.

Luca: Donc, la seule chose qu'ils sont en train de charger ne sont que quelques fichiers statiques comme CSS et HTML et JavaScript qui sont servis par CDN, et dans ce cas, vous pouvez évoluer en conséquence, ce n'est pas un grand défi. Mais le vrai défi est de savoir comment mettre à l'échelle les équipes travaillant sur la même plate-forme, car parfois les défis auxquels est confrontée une équipe 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 pensez, 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 vous avez votre monolithe, vous n'avez donc qu'à configurer tout dans votre CICD une seule fois pour le front-end et le back-end, puis vous commencez à répéter 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 maintenir la même architecture qui pourrait, disons, créer des avantages pour votre entreprise, parce que peut-être vous pouvez trouver des goulots d'étranglement.

Luca: Revenons maintenant à la partie application d'une seule page. Donc, si nous voulons mettre à l'échelle une partie d'application d'une seule page, le défi n'est pas technique, c'est avec les humains si vous voulez. Alors, comment faire évoluer les équipes travaillant sur la même application. Donc, ce que j'ai fait il y a quelques années, c'est de commencer à étudier une architecture et des principes possibles qui me permettraient de faire évoluer le front-end et le backend. Donc, travailler sur les principes du backend pour 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 ainsi 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 d'une manière qui nous permettra de nous concentrer sur un petit problème. Donc, un problème plus petit que l'application entière 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 fondamental pour Micro-frontend est d'essayer de trouver leur 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 d'activité et peut être déployé indépendamment

Drew: Donc je veux dire que vous avez mentionné les microservices à l'arrière. Donc, conceptuellement, c'est une sorte de solution similaire au problème. Les microservices servent à l'arrière, mais sont portés à l'extrémité avant. Est-ce une équivalence approximative ou y participe-t-il davantage?

Luca: Oui. Non, c'est un moyen de résoudre le même problème qu'il essaie de résoudre les microservices à l'arrière mais à l'avant 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 trouvé ce qu'ils appellent, le cadre de décision Micro-frontend qui est essentiellement quatre étapes qu'ils utilisent pour, disons, vous identifiez une approche pour Micro-frontend, parce que si jusqu'à présent, nous choisissent généralement un cadre qui a conçu l'architecture pour nous et nous l'implémentons en plus 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 la façon dont vous implémenter en plus de cette architecture spécifique.

Luca: Donc, sur Micro-frontend, vous devez commencer à prendre du recul. 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 couper horizontalement, vous pouvez donc avoir plusieurs micro-frontends dans la même vue ou vous pouvez couper verticalement. Par conséquent, vous chargez toujours un micro-frontend à la fois. Et ces décisions sont très importantes, car elles entraîneront ensuite certaines autres options que vous aurez en fonction de la décision initiale à prendre. Donc, le premier, comme je l'ai dit, vous décidez comment vous souhaitez découper votre application. La seconde est de savoir comment 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 un micro-front-end différent et ensuite servir la vue finale à votre utilisateur. Ou vous voulez utiliser le côté bord inclus, c'est une norme qui est à l'intérieur des CDN afin de composer une page et de les y servir.

Luca: Ce sont trois des options que vous avez. Et puis, outre la composition, vous devez réfléchir à la façon dont vous souhaitez router. Donc, comment vous effectuez le routage, je ne sais pas, / login ou / signin vers la partie catalogue ou un objet détail spécifique. Ici aussi, vous avez comme trois options. Vous pouvez le faire sur le serveur d'applications, 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 que vous dites, d'accord, maintenant pour cette URL spécifique, vous devez charger une autre vue ou un autre micro-frontend. Et la dernière partie est de savoir comment vous communiquez avec Micro-frontend.

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

Luca: Ensuite, si vous pensez à avoir plusieurs micro-frontend tous ensemble, alors vous devriez éviter d'avoir états qui sont partagés entre Micro-frontend, car sinon vous couplez des choses. Au lieu de tout le concept, c'est le découplage et le déploiement indépendant. Et donc disons que les défis d'une scission horizontale, qui est la première décision que vous devriez prendre ou la scission verticale, sont complètement différents, et nous devons être très conscients de celui qui correspond à notre cas d'utilisation.

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

Luca: Ouais, plus que de la technologie , Je verrais que nous choisissons 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, ça s'appelle le framework Luigi, qui a été publié par SAP open source. Ce qu'ils font, c'est créer des iframes où ils enveloppent leur micro-frontend à l'intérieur. Alors maintenant, si vous pensez à cela, disons, en utilisant des iframes de nos jours, vous êtes sur un site Web public qui peut-être comme le référencement ou d'autres fonctionnalités obligatoires, cela pourrait être problématique.

Luca: Mais dans le cas de SAP, si vous y pensez, 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 une version différente du navigateur . Donc, pour eux, cette chose leur permet 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. Pour donner un autre exemple, Spotify, nous utilisons des iframes au début. En fait, la publication documentaire est toujours composée de plusieurs iframes et chaque iframe est une minuscule application qui ne fait, je ne sais pas, qu'un lecteur de musique ou simplement sa recommandation, quelle qu'elle soit. Ils essaient d'avoir la même approche sur le web, mais ils ont rejeté cela cette année afin de revenir à une application d'une seule page.

Luca: Et cela signifie, ils expliquent pourquoi dans le blog technique, ils disaient cela évidemment si vous appliquez cela à des millions d'utilisateurs qui utilisent des iframes qui 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'interagir avec votre page serait plus long. Donc, en réalité, cette approche pourrait convenir à certains cas d'utilisation, mais ils ne devraient 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 ce problème et que vous pouvez commencer à dire, d'accord, j'ai découpé l'application de cette manière, donc j'ai les options disponibles quand je veux composer, quand je veux router, quand je veux communiquer, ça doit vous guider pour 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 la cohérence dans le système de conception que vous avez à travers tout le micro-frontend. Ou je ne sais pas comment vous gérez les dépendances et évitez le choc des dépendances à l'intérieur du micro-frontend, mais la réalité est que les quatre décisions que j'ai mentionnées précédemment vous permettront de prendre ensuite toutes les autres rapidement sans avoir le problème de la sur-réflexion, 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 plus rapide qu'une revue 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 des équipes au sein de votre organisation et avec 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 à relever?

Luca: Oui. Je peux donc vous raconter quelle est l'histoire de DAZN. C’est l’entreprise sur laquelle je travaille. Actuellement à DAZN, nous avons eu un beau défi. Nous avons donc actuellement plus de 300 personnes qui travaillent à l'avant et à l'arrière de notre plateforme. Il s'agit d'une plateforme OTT qui est diffusée en direct lors d'événements sportifs dans le monde. Et le bit intéressant est que si tous les microservices nous savons gérer plus ou moins et nous avons des équipes réparties. Nous avons donc quatre centres de développement. Nous voudrions mettre des équipes dans chacun des centres de développement sur le devant, et nous avons essayé cette approche et cela fonctionne plutôt bien. Ainsi, avec Micro-frontend, nous avons été en mesure de fournir différents domaines commerciaux à différents endroits et de permettre la communication croisée entre les équipes à l'intérieur d'un domaine commercial spécifique, tout simplement parce que le pire des cas est que si vous devez parler avec une autre équipe sur votre même domaine commercial , vous atteignez la distance de marche de votre bureau. Si à la place vous avez besoin de discuter de choses spécifiques au sein de l'équipe de distribution, alors avec peut-être quelqu'un à Londres au lieu d'Amsterdam, ou au lieu d'une entreprise en Pologne, vous organisez simplement un appel.

Luca: Mais ce genre de communication est plus rares que celles qui se produisent entre les équipes au sein du même emplacement. Et c'est pourquoi nous avons commencé à travailler là-dessus. La première chose qu'ils ont faite a donc été de voir comment nos utilisateurs interagissaient avec notre site Web, comment la société é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 zones et nous ces quatre zones que nous avons attribuées à chaque centre de développement.

Luca: Évidemment, il y a un certain point de contact entre ces zones, mais il y a ensuite des moyens que vous pouvez dire atténuer et avoir un premier atelier avec les différentes équipes qui sont dans des endroits différents et ensuite travailler vers le même contrat API par exemple, ou le même objectif avec des points de contrôle pendant le développement. Mais la bonne chose d'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 le fonctionnement de l'entreprise. 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 dans la même langue si vous parlez sur la conception pilotée par 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, nous disons, augmentez le débit et réduisez les frais de communication, et l'étendue des dépendances qui se produisaient dans d'autres situations sur lesquelles ils travaillaient.

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

Luca: Ouais . Donc, dans DAZN, nous avons décidé de découper verticalement notre Micro-frontend et c'était une décision qui nous a permis d'avoir la liberté de choisir la technologie dont nous avons besoin pour chaque Micro-frontend unique. Étant donné que chaque fois que nous chargeons un micro-frontend par heure, cela signifie par exemple que la façon dont nous avons une page de destination est différente du trajet 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

Luca: Et puis à leur propre rythme, à leur rythme, ils mettaient à jour leurs propres trucs. Cela nous permet donc également 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 les versions également candidates pour le front-end. Nous implémentons, disons, plusieurs pratiques qui nous permettent de simplement essayer certains moments de la production et de voir comment les choses fonctionnent.

Luca: La beauté de ces approches pour lesquelles nous pouvons décider indépendamment d'avoir le bon outil pour le bon travail plus que d'avoir un dénominateur commun sur toute 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ù la société grandissait, l'entreprise évoluait et devenait plus mature et le défi est complètement différent. Donc, ce ne serait 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. En particulier une institution comme DAZN, que l'on passe de pratiquement zéro à 3000 employés en trois ans. Donc, comme vous pouvez l'imaginer, ce fut une croissance massive et une croissance massive pour l'entreprise ainsi que pour la base d'utilisateurs.

Drew: Existe-t-il un moyen établi pour les différents micro-frontend de partager des données et pour communiquer les uns avec les autres, par exemple, juste pour rester en phase avec le même point de vue ou existe-t-il un moyen de le faire?

Luca: Oui, c'est le cas. 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 est de stocker tout ce qui doit être, disons, partagé sur différents micro-frontend ou sur un stockage Web, soit une session ou un stockage local ou en mémoire. Et puis sur la base de ces informations, le Micro-frontend est chargé, peut récupérer du shell de l'application à ces informations et ensuite les consommer, les modifier ou les changer. Cela dépend entièrement de la façon dont vous découpez l'application, mais dans ce cas, juste pour fournir un exemple, si vous pensez que lorsque vous êtes des utilisateurs authentifiés et que vous devez vous rendre sur la page de connexion, lorsque vous et les API sont consommés et ils fournissent un jeton JWT, Micro-frontend les transmet au shell de l'application et au shell de l'application en commençant, 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 à partir 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 sur leur propre roue.

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

Luca: Je pense d'abord et avant tout que le principal défi que je vois est 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, nous passons enfin 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 d'avoir quelqu'un qui trace le chemin, c'est maintenant que nous avons, disons, plusieurs personnes en haut définissant le bon chemin à l'intérieur de leur domaine, et c'est un énorme changement

Luca: D'un autre côté, je pense que la complexité est d'accepter parfois que vous faites la mauvaise abstraction pourrait être, disons, plus cher que la duplication de code. Et 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 passent beaucoup de temps à en faire le meilleur code de tous les temps ou le meilleur sous 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'ils ont commencé avec quelques cas d'utilisation pour un composant spécifique. Et puis ces cas d'utilisation sont devenus 10 et le code est devenu impossible à gérer.

Luca: Donc, essayer d'ajouter une nouvelle fonction à l'intérieur du même composant pourrait être plus à risque qu'un avantage. Je pense donc que l'autre chose que nous devons comprendre avec Micro-frontend est de savoir combien nous voulons le partager et combien nous voulons dupliquer. Et il n'y a pas de mal, honnêtement, à dupliquer. Dans notre cas, par exemple, nous avons une duplication de pied de page et d'en-tête, et nous l'avons fait principalement parce que nous avons changé comme trois fois l'en-tête en quatre ans. Donc, comme vous pouvez l'imaginer, le fait que nous les centralisions, sommes affectés à une équipe et créons 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 logique derrière cela et si nous voulons changer une fois, nous ne voulons pas appliquer cela deux fois dans plusieurs parties du code. Nous voulons avoir une seule bibliothèque qui est une source de vérité, mais pour l'en-tête et le pied de page, également s'il y a une divergence ou pour le pixel ou s'il y a une fonction qui est déployée comme une semaine plus tard, cela ne nuira pas à la

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

Luca: Oui, donc ma suggestion serait d'abord et avant tout de ne pas démarrer un projet greenfield avec Micro-frontend à moins de savoir exactement comment il devrait être construit. Et généralement, il est très peu probable que vous ayez 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 sur cela, il pourrait être non trivial 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 d'é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 sens très fort pourrait convenir à l'architecture Micro-frontend. Évidemment, cela ne signifie pas qu'à partir de maintenant, tout devrait être transformé en micro-frontend, car le micro-frontend n'est pas du tout la solution miracle.

Luca: Ce que c'est, c'est une architecture supplémentaire sur laquelle nous pouvons nous appuyer. le monde frontal. Et jusqu'à présent, nous avions comme une certaine quantité d'architectures, maintenant nous en avons une supplémentaire. Mais cela représente beaucoup de défis car, évidemment, vous devez le faire, si avant le rendu côté serveur ou une application d'une seule page, il existe des modèles clairs qui ont été explorés puis mis en œuvre par plusieurs frameworks, etc. Avec Micro-frontend actuellement, c'est une façon de faire les choses. Mais l'ajout du cadre décisionnel 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 que sont les micro-frontends et comment ils doivent être utilisés. Et beaucoup de gens pensent que peut-être disons, sont mauvais parce que, 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 , comprenez comment l'implémenter et vous pourrez commencer à travailler dessus. Je suis tout à fait d'accord pour dire qu'il y a des défis techniques et qu'il y a beaucoup de décisions que vous devez prendre et que vous ne pouvez pas commencer tout de suite avec un éditeur devant vous en train d'écrire du code et de penser, d'accord, maintenant je crée un micro-frontend architecture. Parce que vous devez comprendre le concept, comprendre le contexte et créer, ainsi que la gouvernance autour de cela parce que la complexité ne consiste pas seulement à écrire le code, mais aussi à comprendre comment toutes les pièces s'emboîtent dans la partie CICD, la partie SEO et ainsi de suite. [19659010] Luca: Le micro-front offre donc, disons, un niveau de flexibilité et nécessite beaucoup d'efforts pour définir le droit de gouvernance. Parce que lorsque vous avez le droit de gouvernance, tout se passe bien. Souvent et malheureusement, je dirais trop souvent, j'ai vu des entreprises qui, lorsqu'elles ne passent pas assez de temps du côté de la gouvernance, comprennent le CICD par exemple, parce qu'elles ne pensent pas que c'est important. Mais à la place pour Micro-frontend, comme pour les microservices, une bonne automatisation vous permettra d'accélérer le développement. Si vous ne passez pas assez de temps sur le bit d'automatisation, vous risquez d'avoir plus de charge que d'avantages.

Drew: Je suppose que c'est comme tant de choses dans le monde du développement Web où les gens sont en danger de plonger avec 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 du micro-frontend facilite très rapidement l'intégration dans une application existante, pour repérer un petit problème et 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 façon est de regarder davantage le découpage vertical par rapport au 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 ensemble sans utiliser I-frame, cela pourrait être compliqué, voire impossible. Donc, si vous commencez, vous n'avez pas l'aspect de… si vous vérifiez le défi, non pas du point de vue technique, mais du point de vue commercial. 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 une version plus mise à jour d'un framework et cela pourrait être un bon moyen. Et puis vous suivez 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 d'appliquer le modèle d'étrangleur qui est un modèle bien connu pour les microservices, mais à l'avant . Donc, basé sur l'URL et basé sur le navigateur et le pays de l'utilisateur. Si lentement mais régulièrement, fondamentalement, nous tuions le monolithe, que dans ce cas, c'était une application d'une seule page, libérant notre nouvelle application plus souvent et voyant les comportements des utilisateurs, si cela améliorait l'expérience, cela causait un problème sur notre système ou pas. 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 ressemble à un très attrayant solution to some problems I'm sure a lot of people are facing. If I, as a developer, wanted to start investigating more about Micro-frontend, where would be a good place to start?

Luca: Yes, so currently I’m spending a lot of my spare time trying to advocating around these architecture, because I think there are a lot of misconceptions. On my Medium account. I’ve wrote several articles that are available there as well. A recorded a lot of videos in conferences that you can find on YouTube without any problem. And the other thing I would suggest if you’re looking for some code example on some frameworks, the one that I would recommend to start with is a single SPA, mainly because it has a vertical slicing approach, it’s easier to pick it up and you can start to understand the benefit of this architecture. Then there are many others that are available. 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.

(dm, ra, il)