Fédération de modules v7 avec modules délégués Partie 2 (2023)

Méduse · Déléguer les modules audio

Victoria Luri :

Alors, commençons notre conversation et parlons des commentaires magiques et de la façon dont il est important que Rspack ait ajouté cela.

Zak Jackson :

Ouais. Donccommentaires magiquesest à peu près juste un moyen de décorer ce que Webpack doit faire pour fournir des indices sur ce qui se passe lors d'une certaine importation. Vous pouvez contourner les commentaires magiques et le faire via les règles du webpack. Mais parfois, c'est beaucoup plus délicat. C'est comme, faire au cas par cas, quelque chose comme un commentaire magique. Il y a un couple comme nous pouvons lui dire quel morceau il devrait être appelé.

Nous avons donc une importation dynamique, nous pouvons définir son nom qu'il doit être généré car nous pouvons lui dire, vous savez, faites comme une importation récursive, comme importer tout ce dossier, importer n'importe quoi et tout découper. Mais nous pourrions dire, mais ne regroupez ni ne fragmentez aucun fichier .json. Donc et cela ne peut pas être fait en changeant le contexte du webpack à travers les commentaires magiques. Et puis les autres sont comme webpack, ignorez, c'est probablement celui pour lequel j'ai le plus utilisé, je veux dire à webpack, évitez de jouer avec cette importation, laissez-la comme une importation dynamique vanille ESM, et l'environnement lui-même le fera le gérer. Il en va de même pour un certain nombre de choses comme des webpack’y sur mesure. Mais les défis que nous avons rencontrés à l'origine en examinant cela pour SWC ; SWC n'a rien pour analyser les commentaires, il n'était pas considéré comme une partie valide de l'AST, mais ESTree, sur quoi Babel et Webpack sont basés avec Acorn. Ils utilisent des commentaires comme des marqueurs de métadonnées ou des choses supplémentaires à effectuer sur quelque chose.

Donc, de toute façon, il semble qu'ils aient obtenu un support de commentaire pour SWC. Et maintenant, cela débloquera tout le commentaire magique, car à l'origine, c'était la seule limite. C'est comme si nous pouvions l'implémenter, mais nous ne serions pas en mesure de lire les commentaires et de faire quoi que ce soit en conséquence. Ce qui n'est pas énorme. Mais il est vraiment agréable que de nombreux utilisateurs de Webpack implémentent les commentaires magiques pour que Webpack fasse des choses plus complexes, morceau par morceau ou importation par importation. Donc, avoir cela signifie qu'il y aura beaucoup de parité de fonctionnalités avec la façon dont certaines choses fonctionnent où. Comme ils dépendent de webpack qui importe le méga nav comme vous le savez, Mega nav.js, pas seulement 381.js ou quel que soit le nom qu'il va trouver. Donc, préserver ce genre de capacités. Dans l'analyseur lui-même, c'est un très gros bonus. Ne pas avoir à tout écrire, ce sont des expressions régulières ou des règles ou des trucs comme ça à l'avant dans la construction. Mais étant capable de le faire à la volée, cela nous permet de faire des choses intéressantes comme nous pouvons créer un chargeur qui crée des importations avec des commentaires magiques.

Vous pouvez donc vous lancer dans la méta-programmation. Parce que maintenant je peux dire d'accord, sur la base de ce que vous faites, nous allons dire, voici un faux fichier qui fait ces choses d'importation et change la façon dont vous l'importez. Mais nous pouvons le faire pendant que nous imprimons les instructions requises, pas comme si je devais reconfigurer Rspack ou faire quelque chose comme ça. Il offre donc cette très belle capacité d'ajustements génératifs à la façon dont les applications sont construites pendant que l'application est en cours de construction. Ce n'est pas un cas d'utilisation étendu. Mais quand vous en avez besoin, vous en avez vraiment besoin. Et je pense qu'un autre truc sympa que nous faisons avec des commentaires magiques est celui qui s'appelle fournir des exportations. Et disons que vous importez des icônes dynamiques. Et ça va faire, vous savez, 5000 morceaux de fichiers, parce que vous avez 5000 icônes.

Donc, d'habitude, j'irais comme importer une barre oblique, laver avec soin. Et puis je viens de télécharger la seule icône. Mais si nous quittons le fichier d'index, je vais tout obtenir et si je fais une importation dynamique, cela signifie que je vais séparer ce fichier et en tirer ce dont j'ai besoin. Mais Webpack va savoir ce dont j'ai besoin après l'avoir séparé. Mais avec un commentaire magique, cela ressemble à nos idées de secouage d'arbre inversé. Est-ce un commentaire magique ? Ensuite, vous pouvez passer une chose appelée exportations fournies ou exportations utilisées. Et vous pouvez réellement le dire, hé, j'importe des icônes, mais je n'utilise que trois icônes. Ainsi, lorsque vous divisez cette chose, l'arborescence secoue tout le reste de cette importation dynamique, à l'exception de ces quatre exportations ou plus que j'utilise. Et donc c'est vraiment puissant pour créer du code scindable en arborescence dans des scénarios vraiment avancés où vous essayez de charger paresseux quelque chose qui est généralement une grande bibliothèque mais vous ne voulez qu'une chose en sortir. Et donc les commentaires magiques pour les exportations fournies ou les exportations utilisées sont super pratiques.

Victoria Luri :

Cela semble vraiment intéressant et cool. Mais parlons des modules délégués. Donc, le post que nous avons fait sur les modules délégués, il a vraiment suscité beaucoup de commentaires et beaucoup d'intérêt. Pouvez-vous s'il vous plaît partager sur la façon dont vous avez mis à jour votre architecture de référence ?

Zak Jackson :

Oui, j'ai donc encore des modules délégués déposés en tant que fonctionnalité bêta pour le plug-in de fédération Next.js. La plupart du temps, je l'ai laissé là-dedans, car notre prochaine implémentation est la plus avancée que nous ayons. Et donc tout ce que nous voulons faire de nouveau, nous pouvons le faire sur Next, assez facilement, puisque nous avons créé une sorte de notre propre monstre à l'intérieur de Next qui nous permet de faire tout ce que nous voulons. Et c'est une très belle plate-forme pour l'ingénierie inverse Next.js, à ce stade.

Donc, les modules délégués s'intègrent très facilement là-bas, car nous avions déjà un gros plugin intelligent en plus pour que le Next joue bien. L'idée va être avec les délégués est d'en extraire cette logique et de la déplacer dans l'un de mes autres packages universels. Ce n'est pas directement lié au référentiel Next, comme je pourrais en mettre une partie dans le package Node, ou le mettre dans le package utils ou quelque chose comme ça. Et cela le donnera à tout le monde. Mais oui, les progrès jusqu'à présent ont été assez bons. Nous avons été en mesure de trouver quelques bugs en cours de route, et comment implémenter ces choses, juste de la bonne manière partout. Mais si vous voyez certains des exemples commençant par le mot délégué dans mon dossier d'exemples, il s'agit alors d'un exemple de module délégué.

Nous avons donc un délégué Next et nous avons juste un délégué webpack vanille, qui était comme le premier que nous avons fait, tout comme tester la théorie. Et puis ça a marché. Et donc c'était comme, d'accord, cool. Nous allons faire un autre exemple, avec le module délégué, nous utilisons Medusa et toutes les manières vanille. Donc, ce que les délégués nous ont en quelque sorte donné jusqu'à présent, et dans mes exemples, je pense que le meilleur sera le plugin Medusa que nous utilisons dans Federation. Donc depuis hier, j'ai déployé une application Next.js sur Vercel. Et c'est, vous savez, pour les applications Next fédérées. L'un d'eux est un shell, et les autres sont des composants ou d'autres pages. Et maintenant, avec ces modules délégués, je peux accéder à toutes les demandes d'extraction que j'ai ouvertes sur Vercel. Donc, une branche différente, où c'est juste ça, mon module délégué est implémenté ici, et peut-être que j'ai bifurqué la branche et j'ai fait comme une version bleue de l'en-tête, ou quelque chose comme ça pour le tester. Et puis disons que je le bifurque à nouveau et que je crée une version rouge de l'en-tête. Maintenant, je peux accéder aux versions originales rouges ou bleues de l'en-tête. Et sur l'un ou l'autre, je peux retourner dans Medusa et je peux changer la version et je peux faire en sorte que la bleue soit rouge, ou simplement rien et toutes les autres demandes d'extraction, je peux essentiellement les changer aussi. Donc, mes demandes d'extraction ouvertes ne signifient plus rien. C'est comme un domaine que je peux aller frapper. Mais effectivement, les trois pull requests. Si je change dans Medusa, les trois demandes d'extraction vont me montrer exactement le même changement de code, car je peux le lier et dire bien utiliser l'en-tête de la demande d'extraction numéro deux, même si vous êtes actuellement vert, utilisez celui du rouge et réinsérez-le et faites-le sur le serveur ou dans le navigateur. Donc, voir cela être gérable était une très grande chose à voir parce que nous n'avons surtout vu que Medusa gérer les choses jusqu'au navigateur. Donc, voir cela maintenant va jusqu'au serveur. Le serveur ne répond pas en demandant à Medusa quoi faire, et Medusa lui dit quoi faire, puis il revient à la vie dans le navigateur. Sans aucune erreur d'hydratation ou avertissement ou quoi que ce soit du genre, c'est vraiment très impressionnant. Et puis en plus, le délégué a aussi ce concept de protocole de remplacement.

C'est donc très similaire à ce que nous voulions faire avec Medusa et ajouter comme une extension Chrome, de sorte que je peux dire, eh bien, c'est ce à quoi Medusa est configuré. Mais quand je vais en production, je veux voir l'en-tête bleu juste pour moi, personne d'autre. Nous avons donc en quelque sorte simplement implémenté la version du pauvre, où j'ai écrit quelque chose que nous reprenons dès le début, puis je le traite, puis je mets à jour la façon dont Webpack fait quelque chose et j'appelle le rechargement à chaud, puis il pousse moi à travers avec le site mis à jour. Et donc, laissez-moi maintenant que Medusa gère tout, puis juste au-dessus de Medusa, j'ai si des remplacements existent dans le tampon, lisez le remplacement, trouvez l'entrée distante actuelle, ce remplacement est forcé. Donc, si c'est comme remplacer la maison, et puis voici, la version et le hachage ou quoi que ce soit, puis juste à partir d'une chaîne de requête, mon navigateur et changera la navigation bleue en rouge ou en vert. Et puis si je supprime la chaîne principale et la recharge à nouveau, je reçois le rouge maintenant. Et je suis capable de le faire pour toutes les demandes d'extraction. Encore une fois, nous avons maintenant Medusa et j'ai un moyen de passer outre avant que cette chose ne demande à Medusa, cela demandera à un système que j'ai en plus, puis j'irai d'accord, eh bien, vous ne faites pas n'importe quoi avec ça. Nous irons à Medusa pour la configuration principale. Et c'est vraiment puissant pour les modules délégués, car nous pouvons continuer à ajouter des couches au-dessus ou en dessous. Medusa ne peut être qu'un des appels. Et vous savez, je parlais à quelqu'un de la sécurité et de la conformité. Et ils disaient, eh bien, si Medusa était piraté, quelqu'un ne pourrait-il pas faire beaucoup de dégâts, comme changer les URL de vos scripts ? Et puis cela pointe vers votre source de vérité? Et j'étais comme, eh bien, oui, mais nous avons des couches de sécurité, plusieurs couches de sécurité en quelque sorte intégrées ici. Mais nous pouvons également définir des politiques à l'intérieur du module délégué. Ainsi, nous pourrions dire, lorsque vous demandez quelque chose à Medusa, vérifiez le domaine que Medusa a rendu, est-ce que le domaine est enregistré quelque part à l'intérieur de votre infrastructure ? L'URL fait-elle partie de votre entreprise, comme s'il n'y avait pas d'URL malveillante provenant d'un autre emplacement ? Nous pourrions avoir le module délégué, une sorte de contrôle de sécurité et lire ce que Medusa est sur le point de donner à Webpack et valider, si cela devrait être autorisé ou non, cela ne devrait pas être autorisé. Et si ce n'est pas autorisé, nous pourrions toujours court-circuiter à nouveau et dire, d'accord, eh bien maintenant, revenons à la version stable, comme peut-être que nous avons un seau, comme le canal stable que nous codons en dur. Et donc nous savons que la version stable que nous mettons en place est lululemon.com/you know, remote slash stable slash remote entry.js. Et donc maintenant j'ai trois mécanismes à ma disposition, je peux le remplacer à la volée, je peux le demander à Medusa, je peux vérifier ce que fait Medusa si j'ai besoin de faire des vérifications supplémentaires. Et puis enfin, je peux aussi simplement récupérer, que dois-je faire si les deux scénarios ne correspondent pas aux exigences, et je peux avoir un troisième recours sur la façon d'aller et de faire quelque chose là-dedans.

Mais ce sont trois mécanismes complètement différents sur la façon d'acquérir l'interface de connexion aux deux conteneurs Webpack différents. Donc, il offre juste une tonne de puissance. Comme, je pense que la façon dont je verrais les modules délégués est avec cela, nous pourrions probablement créer notre propre cadre métallique autour de la fédération de modules. C'est la puissance que cela vous donne parce qu'il contient un middleware, si nous voulons faire quelque chose, disons comme Next.js, où chaque page charge des données, et vous savez, cela fait tout cela, nous pourrions probablement câbler beaucoup de ce truc via le module délégué, s'il a besoin de charger des données, alors nous pourrions l'attacher. Donc, ce que Webpack obtient, c'est une interface spécifique à tout type d'effet secondaire que nous voulons analyser, comprendre ou répondre. Donc, si nous savons que la page qui arrive, ce sera ce type de page de récupération de données, nous pourrions envelopper le module délégué pour renvoyer ce type de construction pour récupérer des données, comme s'il s'agissait d'obtenir des accessoires de serveur, ce qui est quelque chose de spécial dans Next. C’est donc vraiment bien que nous ayons ce niveau de contrôle. Cela me donne l'impression que les modules délégués sont comme le middleware Express à l'intérieur de la fonction require de Webpack où vous savez qu'entre demander quelque chose et le récupérer, vous pouvez en faire ce que vous voulez. Et puis enfin, vous l'alimentez en webpack, donc c'est une tonne de contrôle par rapport à tout ce que nous avons eu auparavant.

Victoria Luri :

Ouais, celui-ci semble vraiment puissant.

Zak Jackson :

Il s'agit probablement du plus gros déblocage technique depuis la création de la Fédération. De toutes les fonctionnalités dont il dispose, c'est probablement la plus puissante disponible, c'est pourquoi je suis si excité à ce sujet.

Victoria Luri :

Pourriez-vous également utiliser quelque chose comme des disjoncteurs avec un module de délégués commutant une télécommande fédérée en fonction du pourcentage d'erreur ou de la latence ?

Zak Jackson :

C'était quelque chose dont je parlais. Et c'est aussi un peu là où je pense que Medusa pourrait être utile. Parce que lorsque nous parlons de beaucoup de ces types de capacités, le seul domaine qui est toujours en quelque sorte bloqué est celui qui ingère les informations pour y répondre, afin que je puisse avoir un moniteur de performances. Et c'est super. Et je peux soit le faire déclencher quelque chose dans mon CI, soit faire quelque chose comme ça. Mais vous arrivez à la vague du problème que je trouve, c'est que chaque fois que vous faites des choses en CI, c'est très stupide. Comme CI ne sait pas grand-chose. Nous avons fait des efforts pour faire des choses comme l'analyse statique pour la sécurité, ou le peluchage, ou d'autres types d'outils comme ça. Mais CI, effectivement, ne comprend pas ce qui se passe, il va juste le faire, faire un travail. Et tant qu'il ne casse pas, faire ce travail, c'est un peu tout ce qu'il sait. La surveillance des performances, d'autre part, peut en savoir un peu plus en profondeur sur la zone ou là où elle est étiquetée pour être lente. Mais il ne sait pas vraiment quoi faire avec ça. Donc, s'il ne peut m'envoyer qu'une très petite information, comme l'en-tête est lent. Comment traduisez-vous cela dans une grande entreprise avec comme 1000 dépôts qui sont créés et détruits tout le temps ? Que oh, cette carte est toujours sortie? Ou comment maintenez-vous ce lien? Pour que vous sachiez de quoi ils parlent - voici en fait cet en-tête ici. Ainsi, avec les modules délégués qui nous offrent cette option pour dire, d'accord, eh bien, nous pouvons récupérer des informations pour comprendre à quoi ressemblent nos performances et les ajuster en conséquence. Mais nous devons savoir que quelqu'un doit presque être l'ajusteur. Donc, si nous utilisons quelque chose comme Medusa, où nous avons commencé à renvoyer des informations RUM à Medusa, Medusa pouvait voir, hé, l'en-tête vient d'être publié, cela ne ralentissait que le site qui utilise cette nouvelle version d'en-têtes.

Alors maintenant, nous avons réduit la portée, ce n'est pas quelque chose qui a ralenti le site, c'est cette version qui vient de se produire. Et tous ceux qui ont pris cela très vite ont vu une augmentation similaire de la latence ou des performances. Alors maintenant, nous avons déjà une bonne compréhension de ce qui l'a probablement causé. Et puis nous avons également une bonne compréhension du rayon d'impact de cela. Alors maintenant, je pourrais commencer à signaler, hé, la navigation a un problème de performances. Et cela a actuellement un impact sur ces quatre applications ici. S'il s'agit d'un problème critique, où vous pourriez créer des règles pour dire, vous savez, comme un seuil pour une alerte, si cela devient X pour cent plus lent, nous pourrions dire, d'accord, Medusa y voit un grand changement, fixez-le au version précédente, et voyez si vous pouvez le faire lors d'un test A/B. Définissez donc un cookie ou quelque chose pour suivre et rebasculez cet utilisateur avec un identifiant différent vers le mode atténué et génère 10 % du trafic, obtenez cette réponse d'atténuation. Voyons-nous un mode d'atténuation, des performances améliorées et aucune erreur n'augmente ? Si oui, nous pourrions alors dire, d'accord, poussez cela à tous les modules délégués, et maintenant nous avons annulé le site, mais nous sommes capables de le faire par programmation et de valider presque ce que Medusa pense que c'est. Comme, vous savez, c'est une validation auto-réalisatrice, vous savez, nous lui envoyons de mauvaises données et bien, laissez-moi peaufiner cela, qu'est-ce que cela a fait ? OK, tout s'est bien passé, laissez-moi rouler. Oh, si nous l'avons enroulé longtemps, nous voyons soudainement un problème, d'accord, annulez cette option. Et ça revient à n'importe quoi. Mais de toute façon à travers les délégués, cela nous donne ces capacités, où nous pouvons maintenant changer dynamiquement la façon dont les choses sont faites. Dans le navigateur, il peut s'agir de faire reculer ou d'avancer des choses. Côté serveur, je pense que c'est un peu plus intéressant, car si on dit regarder les edge workers avec Netlify, et Module Federation, on pourrait alors mesurer ce qui est moins cher. Est-il moins cher et plus rapide d'envoyer une demande à un autre travailleur de périphérie pour imprimer les en-têtes, HTML, puis que Webpack obtienne une importation fédérée de l'en-tête ? Mais nous avons un module délégué qui le modifie pour ne pas télécharger le code, mais à la place, récupérer le code HTML, puis le renvoyer comme un module exportant une chaîne.

Alors maintenant, j'importe une chaîne, c'est en fait la réponse d'un autre travailleur de pointe. Et cela devient le truc que cet autre travailleur de pointe a fait pour faire mon en-tête. Mais si c'est lent, comme si cela prend 50 millisecondes pour se connecter à l'en-tête, et nous disons, eh bien, l'en-tête ne prend que deux millisecondes pour s'afficher, le système pourrait s'auto-optimiser et dire, eh bien, nous avons vu que c'est en fait plus rapidement si nous réduisons simplement le temps d'exécution et l'exécutons sur ce seul travailleur. Nous le ferons donc à moins qu'un partenaire ne subisse une forte pression. Et puis vous pourriez dire, eh bien, dans la prochaine invocation, renvoyez-le à un autre travailleur. Et maintenant, nous pouvons en quelque sorte avoir un système informatique élastique où il peut devenir un système informatique parallèle distribué, ou il peut retomber dans des modèles plus monolithiques basés sur la mémoire. Mais vous savez, c'est quelque chose que vous devez généralement construire autour d'un tout grand cadre. Et vous devrez déployer votre application spécifiquement pour les limites des travailleurs et des choses comme ça. Avec Federation et Node Federation sur Netlify, vous pouvez en quelque sorte simplement déployer une application, comme dans la forme que vous souhaitez. Et ça marchera. Je peux donc déployer cette chose sur aucun JS. Et je pourrais alors dire, d'accord, eh bien, laissez-moi pousser cela jusqu'à Edge, et cela fonctionnerait très bien. Je ne change pas vraiment la façon dont j'ai écrit un code, il saura juste qu'il est dans le réseau Edge, et comment certaines choses doivent être faites sont un peu différentes. Mais je n'ai pas eu à concevoir et à développer une application de travail Edge, j'ai juste construit l'application et laissé l'outil de construction s'occuper de s'assurer qu'elle s'exécute là où elle est censée s'exécuter. Cela donne donc une tonne de flexibilité, même pour des choses comme imaginer. Les travailleurs de bord sont vraiment bons, mais c'est léger. Donc, si vous avez une tâche très lourde à accomplir, il est parfois préférable de la renvoyer au Node Lamda.

Cela nous donne donc ce type de mise à l'échelle en trois dimensions, où nous pouvons soit mettre à l'échelle, vous savez, horizontalement sur plus de travailleurs, soit, vous savez, contracter jusqu'à moins de travailleurs. Ou nous pouvons également pousser l'informatique entre Node.js et Edge à la volée. Alors maintenant, votre serveur de notes lent peut effectuer un démarrage à froid, faire le travail complexe qu'il doit faire, puis il y a 10 autres choses qui pourraient faire. Et cela pourrait dire, eh bien, ces choses ont été légères dans le passé, envoyons-les à 10 travailleurs distincts et traitons-les toutes en une seule fois. Au lieu de séquentiellement, faites-en un, faites-en deux, faites-en trois, faites-en quatre, puis renvoyez-le. Mais oui, donc c'est comme l'un des genres, plus il y a de possibilités, mais c'est certainement quelque chose que la conception de ce système de délégué permet des choses comme ce genre de choses que vous aviez auparavant, ce n'est tout simplement pas possible de faire fonctionner des choses comme ça, en particulier comme un calque Edge. Mais pour nous, ce serait juste un wrapper de package NPM, comme un module délégué spécial appelé like, le délégué de calcul élastique, ou autre. Et puis cette chose est conçue, ok, je peux aller ici, je peux aller là-bas, je peux aller n'importe où. Et puis la façon dont vous utilisez ce composant est similaire à la normale, comme les modèles de fédération de modules que nous voudrions, comme la façon dont les composants serveur seraient, vous ne le faites pas, vous ne lui envoyez pas un tas de données, vous ne le faites pas passez-le au contexte, il va plus sérialiser, un peu de données, l'envoyer ailleurs, il fera le travail. Et le peu de données que je lui envoie lui suffit pour comprendre ce qu'il est censé faire. Mais il fait son propre travail, récupère ses propres données et renvoie tout, ce qui est le modèle de propriété au niveau des composants.

Donc, si vous suivez déjà cela pour rendre les systèmes distribués plus fiables. Cela signifie également qu'il y a de fortes chances que vous puissiez commencer à le diviser en différentes primitives de calcul selon les besoins, et en fait augmenter et réduire votre charge de travail, car cela suivrait quelqu'un pour construire et maintenant nous fournissons ce code de colle pour laisser quelque chose comme cela se produit, ce qui serait très difficile à faire manuellement d'une manière similaire et rapide.

Victoria Luri :

Merci d'avoir partagé! Très bien, alors maintenant - démo. En parlant de rendre les systèmes distribués plus fiables, nous n'en avons pas parlé depuis un moment. Faisons une démonstration rapide de la nouvelle architecture de référence, et sa configuration était des modules délégués.

Zak Jackson :

Bien sûr. Donc euh, attention, je ne peux pas montrer mon architecture de référence pour le moment, mais j'ai une application plus simple qui fonctionne toujours et me permet de cliquer pour que je puisse parcourir comme un trois, vous savez, chaque page importante n'a rien de super fantaisiste, mais il montre toutes les parties que nous voulons travailler.

Victoria Luri :

Cela fonctionne parfaitement.

Zak Jackson :

Medusa a donc subi plusieurs itérations drastiques d'amélioration. Beaucoup de très bon travail a été fait autour de l'UX et de sa conception. Je pense que lorsque cela a commencé, c'était un projet très simple. Ça marchait, mais c'était plutôt, voici un concept éprouvé, réalisable. Non, vous pourriez exécuter une vraie application à partir de là. Et ce serait rapide. Donc, depuis ces premiers jours avec l'aide de l'équipe Valor, cette chose a vraiment explosé en un joli produit de première classe. Donc, l'une des grandes choses que je viens de voir, c'est que nous avons ce nouveau diagramme UML. Mon ancien diagramme UML était assez floconneux. Mais il a surtout fait le travail. Mais cette chose est beaucoup plus bien présentée et offre pas mal de place, comme juste plus de place à l'amélioration si nous devons continuer à augmenter la quantité de données que vous pouvez voir dans la vue UML. Ainsi, vous obtenez de meilleures vues et de meilleures interconnexions. Comme, il est plus facile de voir qui se connecte à quoi et des choses comme ça. Et à l'avenir, nous verrons beaucoup plus de fonctionnalités pour pouvoir sortir de l'interface utilisateur que nous avons définie ici, ce qui, je pense, est le plus important est de savoir comment créer une interface utilisateur qui va nous permettre aller de l'avant sans le repenser comme cinq fois ? Oh, vous savez, quels sont les cas d'utilisation les plus compliqués, cool, ceux-là sont loin. Maintenant, améliorons les choses. Et ça évolue dans ce sens, ça nous donne plus de pouvoir dans le temps.

Ainsi, partout où UML se trouve ici, nous avons notre table de dépendances qui montre toujours que la boutique vend une boutique pdp et qu'un paiement de carte de page est, vous savez, le titre, la page de paiement ou la carte. Et puis la maison est, la navigation, la page d'accueil et son plan de page. Et puis ici, nous voyons aussi qui vend des modules, donc nous pouvons voir tous ceux qui partagent donc nous voyons toutes ces offres, ce package est partagé. Cela vous donne donc une bonne idée de ce qui est disponible et de ce qui est requis dans les différentes parties de l'application.

Nous avons également notre Node Graph ici, qui a également parcouru un long chemin. Beaucoup plus lisible. Et j'adore le dimensionnement, qu'il est adapté à la taille, afin que vous compreniez mieux la taille d'une télécommande, ou combien de connexions sont établies avec une télécommande par rapport à certaines autres. Mais vous savez, si je veux voir qui utilise ce composant de titre depuis chez moi, je peux cliquer sur et je vois bien, le paiement dépend du titre. Et je pouvais bien voir, qui utilise le magasin, d'accord, le magasin consomme aussi le magasin. Et il est également utilisé à la maison et à la caisse. Et vous savez, nous pourrions aller voir la page du produit et dire, d'accord, la page du produit est utilisée par le magasin. Mais regardez la boutique, nous pouvons voir que la boutique est connectée à la page produit de la carte de la page de navigation, elle est connectée à plusieurs parties de l'application ici. Et puis vous pouvez également entrer ici et choisir le nœud que vous essayez de trouver si vous essayez de rechercher une note spécifique. Il est donc également beaucoup plus facile de naviguer à mesure que les systèmes deviennent beaucoup plus grands. Et nous pouvons également regarder la profondeur des nœuds, ce qui est une fonctionnalité vraiment intéressante pour pouvoir voir à quelle profondeur allons-nous? Ou combien ou peu de nœuds voulons-nous afficher ? Magique, vous aviez environ 1000 nœuds ici, pouvoir filtrer la profondeur, ceux qui sont en bas seraient utiles, d'autant plus que les télécommandes imbriquées et des choses comme ça arrivent. Et nous pouvons également filtrer ces éléments par des connexions directes, sans être sûrs à 100 % que tout soit déjà câblé. Oh, ouais, sens des connexions. Alors si j'ai ça là-bas, je peux voir dans quelle direction ça va. C'est un peu difficile à voir. Mais vous pouvez voir que j'ai ces flèches ici. Alors maintenant je sais qui en consomme. Et qui lui fournit quelle chose est une chose importante et utile à savoir, c'est comme, eh bien, pas que ces deux-là soient liés d'une manière ou d'une autre. Mais genre, qui est-ce ? Qui est-ce que je dois aller dépenser ? Comme si je vais changer de navigation, qui dois-je aller mettre à jour ? D'accord, je dois donc aller voir le magasin de paiement et la maison, car la navigation va avoir un impact sur ces trois là.

Et puis nous entrons dans notre graphique de dépendance, qui est comme notre ancien graphique d'accord que nous avons toujours, qui est juste une autre façon de visualiser ce qui se passe pour voir quelles sont toutes les interconnexions dans l'ensemble, et comment tout se propage et se connecte à nos autres dépendances.

Donc, une fois que nous avons en quelque sorte parcouru ces applications, si nous revenons à leur UML, je pourrais retourner à la maison et aller à la télécommande. Et maintenant que vous savez, quels sont les modules exposés ? Et où sont-ils sur le système de fichiers de ce référentiel ? Si cela nécessite quelque chose de plus, comme tout ce qui est un module partagé ou quelque chose comme ça, il sera généralement répertorié ici. Je ne reçois pas React ou certaines des choses Next.js par défaut répertoriées parce que celles-ci sont considérées comme câblées à next, nous les marquons donc simplement comme externes afin que les télécommandes ne se soucient même pas de négocier React, car pour vivre à l'intérieur de Next , React doit être là. Nous ne suivons donc pas vraiment ce genre de choses ici. Mais si je devais ajouter Lodash, il apparaîtrait et dirait, hé, vous savez, cette chose nécessite Lodash, parce que c'est celui comme le fournisseur partagé ou le paquet extérieur dont il dépend. Nous avons aussi, vous savez, tout ce qui est partagé et les versions réseau qui sont partagées. Il est donc facile de comprendre qui est sur quoi. Et nous avons les dépendances directes. C'est donc tout ce qui est répertorié dans votre package json, et ainsi que nous pouvons voir qui le consomme afin que je puisse voir cool cette chose consommée en magasin, en caisse et en titre. Et puis ici, bien sûr, j'ai mon gestionnaire de version. Alors je peux entrer ici. Et je peux choisir entre, vous savez, j'ai un horodatage, j'ai aussi le hachage git commit, vous pouvez avoir un numéro de demande d'extraction, ou vous pouvez calculer comme une version sémantique, comme vous le feriez pour un paquet npm. Et ceux-ci peuvent être répertoriés ici comme ce à quoi vous épinglez. Et puis l'autre chose, ainsi que nous avons aussi, comme la comparaison de versions, pour que vous puissiez voir au fil du temps, comment ce conteneur a changé, comme si nous mettons à jour React, je peux voir la date à laquelle cela s'est passé. Si je change ce que je partage ou consomme, je peux voir la date à laquelle un nouveau module partagé a été ajouté, ou il a commencé à importer un nouveau module fédéré. Donc je veux dire, même ici, vous pouvez voir que j'utilise 2.8.3. et puis j'utilise maintenant 2.8, bêta, bêta deux. Et puis ici, et vous savez, cette dépendance était de 6,1. et maintenant c'est 6.2. Il est donc très utile de voir, eh bien, quand le changement s'est-il produit dans votre arbre de dépendance ? Et dans les systèmes distribués, ou même dans un référentiel unique, il est vraiment complexe de savoir quand ce type d'informations se produit. Si je vois un bogue commencer à se produire en production, eh bien, que s'est-il passé ? D'accord, sortez-en un, eh bien, l'avons-nous seulement trouvé maintenant ? Ou est-ce réellement arrivé sur cette version? Vous devez donc creuser dans l'historique de Git et essayer de comprendre ce qui a pu se passer. Mais avec une telle vue, il serait beaucoup plus digeste d'aller ici et de voir, d'accord, quelque chose ne va pas, ce qui a récemment changé dans notre chaîne d'approvisionnement. D'accord, quelqu'un a mis à jour un utilitaire de cookies, juste à cette époque. Et imaginez si cette vue prenait cette fonctionnalité, l'envoyait à Medusa, imaginez si cette vue avait une connexion API à Datadog ou à Sentry. Ainsi, vous pouvez commencer à voir sous chaque version qui est coupée, voici les balises et les types d'erreurs qui arrivent, ou voici de nouvelles erreurs qui n'ont jamais été vues auparavant, uniquement lorsque cette version est apparue. Et cela vous aide à pouvoir commencer à corréler les informations. Et encore une fois, avec beaucoup d'outils comme Datadog, ils agrègent tellement de choses sur ce qui se passe. Mais aucun de ces outils ne comprend nativement comment l'application a été construite et comment elle est censée se comporter. Vraiment, seul Webpack a une compréhension approfondie de cela. Ainsi, lorsque vous commencez à utiliser ces outils qui ne savent pas grand-chose et que vous les appliquez essentiellement à un moteur d'ingestion qui comprend très bien la partie webpack, nous pouvons commencer à tirer des conclusions sur, hé, c'est probablement cette chose. Donc, cela ajoute simplement beaucoup de nouveaux types d'options.

Cela a été très difficile à apprivoiser ou à contrôler, même dans une seule interface de dépôt. Il est toujours difficile de gérer qui utilise quoi et où, même avec les packages npm, nous saurons qui utilise toujours la première version du carrousel car nous voulons le supprimer de la bibliothèque de composants. Bon, maintenant je dois faire une recherche sur 1000 dépôts et espérer que la recherche GitHub est assez bonne. Mais si tout le monde rendait compte à Medusa, je pourrais simplement entrer dans Medusa et dire, d'accord, qui utilise ce package partout ? Cool, voici le fichier et la ligne exacts sur lesquels se trouve l'importation. Et vous pouvez connaître instantanément cette énorme quantité d'informations sur votre chaîne d'approvisionnement. Il y a donc deux autres choses vraiment importantes qui sont arrivées récemment, c'est que nous avons des organisations. Alors maintenant, si vous êtes une entreprise, vous pouvez vous inscrire auprès d'une organisation. Et vous pouvez fournir d'autres rôles et autorisations à vos utilisateurs sous cette organisation et vous pouvez commencer à la gérer et à l'étendre. Ainsi, certains utilisateurs ne pourront peut-être y avoir qu'un accès en lecture. Et peut-être que vous voulez que seules vos clés AWS ou quelque chose comme ça aient les jetons d'écriture ou quelque chose comme ça à éditer ou à changer. Vous avez maintenant comme une politique là-dedans. Il ne s'agit donc pas seulement du scénario de confiance, et vous pourrez étendre certaines applications. Alors bon, vous savez, le groupe de vente au détail n'a pas besoin de voir le groupe Webapp nord-américain.

Nous pourrions donc avoir une organisation Lululemon, mais nous pourrions avoir deux groupes distincts en dessous qui voient chacun tout ce qu'ils font, mais il n'y a pas d'interconnexion, donc rien ne doit être mis en œuvre. Et une autre idée est qu'en mettant la possibilité de mettre des politiques autour des applications, je pense que c'était quelque chose que nous avons pensé à faire éventuellement à l'avenir. Alors vous les considérez comme des autorisations d'accès basées sur les rôles. Alors maintenant, vous savez, si je suis dans une banque, et j'ai une comptabilité, essayant d'extraire un module fédéré qui est généralement comme le site frontal public, vous pouvez mettre en place des mesures de sécurité pour dire que vous n'êtes pas autorisé à être en mesure de consommer cette télécommande à partir de ce poste, comme, il n'y a pas de diaphonie ici. Cela fournit donc une couche de gouvernance au-dessus de quelque chose qui est très difficile à gouverner, car je peux simplement aller déposer un script n'importe où ou ajouter un cookie. Et une fois que c'est là, c'est très difficile, vous devez faire quelque chose comme, vous savez, quelle est la politique de sécurité du contenu, qui ne fonctionne toujours qu'au niveau du domaine, donc vous devez soit construire une infrastructure pour la bloquer derrière un proxy inverse. Pendant ce temps, une grande partie si le code de colle était piloté par quelque chose comme Medusa, toutes ces règles pourraient être appliquées directement à l'exécution du webpack, et il sera beaucoup plus difficile de contourner le webpack et de reconnecter quelque chose que vous n'êtes pas censé, parce que Medusa est en quelque sorte le moteur de l'ensemble du graphique, et tout le monde utilise ce truc. Donc, vous savez, cela ajoute une bonne couche de sécurité, une bonne couche de séparation et des utilisateurs multi-locataires. Donc c'est juste beaucoup. Vous savez, c'est une grande caractéristique de toujours voulu ici, pour s'attaquer aux clients de l'entreprise, où vous ne pouvez souvent pas vous contenter d'une seule connexion, ils le voudront derrière leur SSO, et ils voudront une organisation basée chose à révoquer et à accorder l'accès aux utilisateurs au fur et à mesure qu'ils, vous le savez, vont et viennent.

Zak Jackson :

Je dirais, je pense que ce que vous décrivez là, pour plonger dans certains détails, je pense qu'une partie de cela est, en tant que développeur, la création d'une télécommande fédérée, vous pouvez spécifier que c'est juste pour EMEA, APAC ou interne , c'est juste pour externe. Et puis être capable de faire ça, d'autres personnes peuvent trouver des trucs qui sont ciblés pour ça. Mais quand ils trouvent quelque chose qui est ciblé pour cela, qu'ils ne peuvent pas utiliser, ils comprennent au moins pourquoi, et ont un moyen de contacter ensuite ces équipes et de communiquer avec elles. D'accord, ceci est étiqueté comme interne uniquement, j'en ai besoin pour mon application externe, pouvons-nous l'ajouter pour qu'il soit externe ?

Zak Jackson :

Ou pouvons-nous accepter et ouvrir un ticket ServiceNow en passant par l'admission en disant que je demande ce module fédéré à un autre directeur, Umbrella. Et maintenant qu'il y a maintenant une gouvernance en place, vous ne pouvez pas simplement injecter à chaud quelque chose ou des choses comme ça, vous avez toujours cette flexibilité, mais c'est, vous auriez, comme votre équipe, et la gouvernance sait ce qui se passe, ce qui est vraiment difficile à faire avec les packages npm, comme si vous deviez le faire de toute façon, c'est un problème très coûteux pour résoudre le code de gestion et les autorisations de qui peut faire ce que vous devez configurer votre propre registre npm personnalisé, ou quelles règles sont d'autres choses qui pourrait être contourné. Et c'est toujours comme un déploiement, mais je veux maintenant approuver cela, je dois faire une mise à jour de toutes les bases de code, je ne peux pas simplement aller à un moteur central et dire, oui, telle ou telle application autorisée veut accéder à ceci dans ces environnements avec ce jeton, et uniquement ce jeton, aucun autre jeton de lecture n'est autorisé à y accéder.

Cela offre donc beaucoup de maturité et de flexibilité réelles, compte tenu du vaste paysage de la façon dont les différentes entreprises et la conformité se rejoignent. Alors je pense que le dernier, qui est vraiment génial, c'est que pendant longtemps, Medusa a pris en charge deux environnements, le développement et la production, et il y a une sorte de code en dur dans sa base de données. Donc ça sonnait bien au début, parce que vraiment les appeler soit en mode dev, soit en mode prod, mais ça devient un peu plus délicat avec, comme les serveurs de staging, ou des choses comme ça, où je veux peut-être contrôler l'environnement de staging, ou si j'en ai, j'ai environ 15 environnements différents, ils sont tous connectés à différents backends ou versions de, disons, les API GraphQL ou quelque chose comme ça. Alors peut-être qu'ils testent une fonctionnalité par rapport, par exemple, à un environnement de scène ou de prévisualisation ou d'assurance qualité, etc. Donc, vous voudrez peut-être simplement dire, d'accord, dans Medusa, si vous êtes cet environnement, voici vos commandes de broche, voici comment vous êtes géré que je peux simplement dire cool, passez à la dernière étape en QA, ou en heurtez certains autre partie de la pile d'applications, pas seulement le développement ou la production. Mais maintenant, je peux avoir plusieurs couches. Et l'idée est que toutes les versions alimenteraient la base de données. Et la construction n'est pas définie qu'il s'agit de production ou de développement d'une manière difficile. Lorsque vous envoyez la version à Medusa, vous pouvez dire, oui, c'est destiné aux productions. Et la broche des productions, la dernière en date saisira celle qui arrive. Mais je pourrais aussi dire, eh bien, c'est un PR de scène, et il apparaîtrait juste sur la scène, mais je pourrais toujours entrer dans la production et je pourrais voir cette sortie là-dedans et je pourrais dire d'accord, utilisez celui qui est sur scène, et je pouvais les connecter, ce qui est encore une fois très flexible pour pouvoir ajouter des environnements illimités et modifier les fichiers de verrouillage en conséquence. C'est très gentil. Comme, vous savez, vous pourriez créer presque comme un environnement de gel de code. Il s'agit donc toujours de production, mais vous pouvez simplement appeler un nouveau gel de code dès que nous atteignons le gel de code, c'est l'environnement vers lequel nous allons nous diriger. C'est le gelé, dont nous savons qu'il est solide et stable. Et nous pouvons également configurer un autre environnement qui ressemble à une sécurité intégrée.

Donc, si dans le gel du code, quelque chose ne va pas et que nous devons revenir en arrière, nous pourrions aimer l'assurance qualité du test de combat, une sauvegarde, vous savez, comme la configuration de l'application, si nous devons faire quelque chose d'urgence, nous pourrions simplement y aller placez et dites, d'accord, production, vous allez maintenant lire l'environnement de sauvegarde, vous savez, gelé. Et maintenant, la prochaine invocation qui écoutera tout cela, mais je peux aller échanger ces choses à la volée, et vous savez, réaffecter ce qu'est cet environnement, ou créer une autre copie de cet environnement, lui appliquer des modifications, et faites-le remarquer, vous savez, une configuration différente et plus robuste. C'est-à-dire, ce qui est vraiment sympa. Comme, vous savez, imaginez si nous avions des environnements personnels. Et si j'avais, comme l'environnement de Zack ici. Et alors j'ai eu un remplacement à l'intérieur de ma demande initiale. Donc, si je vais en production et que j'ai la balise d'environnement Zack's use X, la production fera une réponse unique avec un paragraphe configuré pour l'ensemble de l'application. Je n'ai donc pas besoin d'aller modifier la production pour voir ce qui se passe ou de remplacer chaque télécommande individuellement. Mais je pourrais simplement dire, hé, utilisez mon environnement personnel, exécutez ma fédération, une sorte de schéma contre un Lambda quelque part qui est géré par Medusa. Mais c'est aussi très bien si vous voulez dire avoir quelque chose de personnalisé, comme si je travaillais avec quatre équipes différentes sur la mise en œuvre de la même fonctionnalité. Et nous sommes tous dans des référentiels séparés, où nous pourrions créer, vous savez, un environnement de tickets JIRA. Et maintenant, localement sur scène, partout où vous allez avoir le code de chaque partie contributrice rassemblé juste pour ces fonctionnalités que vous pouvez tous regarder et travailler dessus facilement. Et vous ne faites que pointer vers un environnement que vous pourrez ensuite supprimer plus tard. Mais vous savez, cela vous donne une tonne de flexibilité pour faire des choses comme ça, juste retravailler ou, vous savez, ou d'autres choses où je pourrais dire, hé, d'accord, je pourrais utiliser l'environnement de Zack comme connexion, et je peux ouvrir un local tunnel sur ma machine afin que vous obteniez réellement votre télécommande est en fait la version locale de mon ordinateur qui vous sert via un tunnel.

Maintenant, s'ils sont connectés à mon environnement, j'agis en quelque sorte comme leur télécommande et je peux éditer des choses pendant qu'ils travaillent sur ma fonctionnalité, mais nous pouvons travailler à distance en tandem. Avec nos changements poussés et tirés sans Git, à chaque fois qu'ils appuient sur Enregistrer, je vois le changement apparaître lorsque j'actualise ma page, je n'ai pas besoin d'être tiré ou de faire quoi que ce soit. C'est donc aussi un impact potentiel très puissant pour des choses comme celle-ci qui pourraient aider à changer notre façon de travailler et de collaborer, en particulier dans les systèmes distribués ou dans les systèmes paléolithiques, où il y a généralement de nombreuses pièces mobiles qui doivent s'assembler. Mais il devient très difficile d'échafauder, comment ces pièces mobiles s'assemblent-elles parfaitement pour développer n'importe quel cas d'utilisation sans créer une tonne d'infrastructure et de travail manuel, pour recréer 10 services ici, juste que nous pouvons les personnaliser ? Ce que je veux vraiment, c'est que je veux créer un lien vers 10 dossiers différents que d'habitude. Je n'ai pas réellement besoin de 10 serveurs disponibles et ainsi de suite pour le faire. Mais traditionnellement, c'est ainsi que nous devrions le faire dans les environnements fémoraux.

Victoria Luri :

Et en parlant d'environnements multiples et illimités, combien pensez-vous que Medusa et Module Federation peuvent aider à économiser sur l'infrastructure de déploiement ?

Zak Jackson :

Cela a donc été important pour moi. J'ai personnellement été sur ce sujet. Peut-être que j'ai raison, peut-être que je me trompe de tangente. Mais je pense aussi que si vous avez déjà lu quoi que ce soit de Tyson, il a travaillé avec moi sur Aegis et Node Federation, en fait. Mais Tyson avait un très bon point de vue lorsqu'il a commencé à travailler avec des backends fédérés. Et il a en quelque sorte dit que lorsque vous avez quelque chose comme Medusa et Module Federation ensemble, le concept de CI commence à perdre son sens comme s'il n'y avait plus vraiment de CI. C'est juste une livraison continue. Et, vous savez, la majeure partie de l'infrastructure de construction et de déploiement est en quelque sorte éradiquée sous un système comme celui-ci, car la raison pour laquelle ces choses deviennent si compliquées est que tout est basé sur le téléchargement d'un fichier Zip avec tout ce dont il a besoin sur cette machine. Et si vous avez besoin d'autre chose, vous devez lui donner un nouveau fichier Zip. Et donc cela signifie que vous avez besoin de beaucoup de Lambdas uniques, etc., car ils ne peuvent faire qu'un seul travail à la fois. Mais si nous dissocions le système de fichiers de la primitive de calcul, ce que fait la fédération, vous savez, en théorie, une très grande entreprise pourrait avoir tout son contrôle qualité, tous ses environnements inférieurs pourraient n'être qu'une étape appelée Lambda. Et chaque fois que vous atteignez l'étape, cela devient une base de code différente à la volée juste pour vous, et répond en conséquence. Je n'ai pas besoin d'environnements éphémères ou de quoi que ce soit, car la scène n'a pas de système de fichiers auquel elle est couplée, c'est à peu près une façon d'y penser comme, imaginez, si vous avez tout sur GitHub en tant que Symlink dossier.

Alors, tout ce que je fais, c'est dire, d'accord, pour cette exécution, changez le lien vers ce dossier et allez exiger la même chose. Et c'est un peu ce que webpack et Federation nous donnent, c'est cette capacité à dire, eh bien, les systèmes de fichiers n'importe quoi, et nous pouvons le changer à tout moment. Et si c'est vrai, nous n'avons pas besoin de centaines d'environnements Lambda et éphémères, et vous savez, d'un gros système de déploiement à gérer, parce que fondamentalement, il n'y a pas grand-chose à faire, comme, je n'ai pas besoin d'un environnement fémoral, car la seule raison pour laquelle j'en ai un est que j'ai besoin d'un fichier Zip différent. Donc, vous savez, vous pourriez n'avoir que deux étapes Lambda en production, et cela répondrait probablement à toutes vos exigences de développement pour l'équipe de 500 personnes. Et ce ne sont que deux Lambda. Cela simplifie donc énormément la maintenance et offre aux entreprises des choses comme le modèle géré. Donc, comme, vous savez, comment Vercel gère l'hébergement, vous connectez simplement le référentiel Git et vous n'avez pas à penser à grand-chose d'autre. La fédération vous offre la possibilité de créer votre propre service géré. Donc, tout le monde veut, disons, un SSR Next.js, frontal. Mais tout ce qu'ils veulent vraiment, c'est qu'ils veulent juste créer une page, ils ne veulent pas vraiment toute l'application Next et la maintenir, et pour avoir un Lambda et tout le CI/CD, ils veulent juste la page et un peu environnement de développement. Et puis une fois que cela quitte leur ordinateur, tant qu'il fonctionne, c'est un peu ce que tout le monde veut.

Donc, ce genre d'avenues vous permet d'offrir cela là où c'est comme, hé, vous créez simplement l'application React, téléchargez des actifs statiques et c'est la fin de tout ce que vous faites. Et il n'y a qu'un ou deux serveurs ici qui sont en fait de vrais serveurs Lambda. Et leur seul travail est de faire tout ce que Webpack leur dit de faire par exécution. Donc, si vous avez ce genre de modèle, vous n'avez pas besoin d'autant d'infrastructure, vous l'éradiquez simplement naturellement, il n'y a tout simplement pas besoin du problème que beaucoup d'infrastructures lourdes et coûteuses résolvent. C'est ce que j'ai le plus aimé, car j'ai toujours été frustré. Pourquoi est-ce tellement de travail, juste pour télécharger du JavaScript. Si on pense avant le rendu serveur, et avant pas de JS, on pense comme WordPress, et jQuery, c'était super simple. Comme vous changez quelque chose en PHP, et vous le faites simplement glisser sur le serveur et vous actualisez la page et il apparaît tout de suite, un peu comme un rechargement à chaud. Dès qu'il est là-haut, vous l'avez. Il n'y avait pas de concept comme une construction ou quelque chose comme ça. C'est donc très simple, il vous suffit de FTP et la prochaine invocation et tout ce que vous avez fait au PHP est mis à jour. Et puis du côté frontal, nous avions des trucs comme jQuery ou autre, où vous pouviez ajouter un widget jQuery à la page. Et, vous savez, j'ai l'impression que nous pourrions probablement créer des sites qui ne pourraient pas évoluer éternellement. Mais vous pourriez créer une expérience assez robuste assez rapidement, simplement à cause de la facilité d'utilisation de ces pièces. Il n'y a pas de builds et rien de complexe n'était nécessaire. C'est juste quelques lignes de js. Et voilà. Et j'ai vraiment aimé ce modèle, parce qu'il était si simple. Comme, vous savez, il a fallu quelques minutes pour télécharger une interface, car vous savez, c'était juste un dossier à l'intérieur d'un serveur PHP. Et ce n'était que quelques widgets jQuery qui se trouvent sur un CDN. Mais nous avons perdu beaucoup de cela lorsque nous sommes passés aux applications construites. Donc, vous savez, où je vois en quelque sorte tout cela comme, hé, cela nous ramène simplement à une époque plus simple, mais nous permet de continuer à utiliser des systèmes plus avancés. Mais le type de dépenses opérationnelles ne doit pas continuer à gonfler à mesure que la technologie devient plus compliquée. Donc, en voyant la simplification, et vous savez, si je n'ai que deux ou trois Lambda, je peux maintenant me concentrer plutôt que sur la mise à l'échelle, les Lambda et la gestion des équilibreurs de charge et de la route 53. Et tous les autres éléments réseau qui vont avec. Je pourrais probablement concentrer la majeure partie de cet effort sur quelque chose comme des déploiements multi-régions.

Ainsi, au lieu de tout déployer dans une ou deux zones de disponibilité, ce qui devient difficile à faire lorsque vous avez 40, 50, 60 bases de code différentes qui doivent toutes être déployées dans plusieurs régions, c'est juste beaucoup de pièces à gérer et beaucoup de réseau répéter 60 fois. Mais imaginez si nous n'avons qu'un ou deux Lambdas, le déployer dans plusieurs régions change simplement le YAML comme, vous savez, le laboratoire Get ou le fichier TerraForm dans une seule base de code. Et maintenant je peux déployer cette application à travers vous savez, 50 disponibilités aux États-Unis. Je pourrais donc le mettre à l'échelle beaucoup plus rapidement, beaucoup plus que ce que vous pourriez habituellement, car il n'y a plus de gros coûts de gestion du changement. C'est en quelque sorte géré. Donc, vous faites le changement, tout le monde l'obtient, vous n'avez pas besoin de demander à qui que ce soit d'aller le faire. Et ils veulent juste construire leur page ou leur fonctionnalité. C'est tout ce qui les intéresse. Et c'est exactement ce qu'ils obtiennent un endroit stable pour construire la page. Mais toutes les difficultés de gestion se trouvent désormais dans un endroit centralisé et plus intelligent. Donc, cela rend la vie plus facile. Comme je ne peux pas imaginer travailler sur un système non alimenté par la Fédération après avoir travaillé avec un.

Victoria Luri :

Donnez du sens. Et auriez-vous encore besoin de deux Lambda si vous utilisez Netlify Edge ?

Zak Jackson :

Peut-être pas. Donc, je pense que lorsqu'il s'agit d'Edge, la seule chose à laquelle vous devez penser est ce que votre application utilise. Donc, si vous avez besoin de faire quelque chose comme utiliser fs, qui est le système de fichiers Node, comme l'accesseur de package. Si j'ai besoin d'utiliser fs, c'est une API de nœud uniquement et les travailleurs de périphérie sont juste V8. C'est donc juste le moteur JavaScript de Chrome, ce n'est pas réellement Node lui-même, c'est juste le seul gestionnaire JavaScript. Donc, il ne sait pas vraiment ce qu'est un besoin ou des choses comme ça. Cela dépend donc de ce que vous essayez de faire. Dans certains cas, il se peut que j'aie besoin de Node pour gérer ces trois ou quatre charges de travail. Mais peut-être que 70% de l'application est juste vous savez, des composants React standard ou quelque chose de simple, cool, n'utilisez Node que pour ce qui est nécessaire et propagez automatiquement tout ce qui est possible vers Edge. Et si vous voyez que les réseaux Edge deviennent lents à répondre, regroupés sur l'un des processus sur le nœud.

Alors maintenant, Node n'a plus à attendre un appel réseau vers Edge, c'est juste en mémoire, et il peut faire instantanément ce qu'il veut. Mais être capable de revenir en arrière et d'avancer selon les besoins capacité par capacité est également un très gros problème à avoir. Si nous disons que vous avez une application plus agnostique, comme disons que ce n'est pas quelque chose comme Next.js, qui a beaucoup d'implémentations spécifiques à Node, alors, comme si nous utilisions Remix, Remix est assez agnostique d'avoir besoin de Node ou de s'exécuter sur Dino ou autre. Donc, avec quelque chose comme ça, je dirais qu'avec les capacités de fédération sur Netlify, vous n'avez pas vraiment besoin d'un nœud, comme un véritable serveur de nœud. Sauf si vous en avez besoin d'un qui a du sens. Comme ma façon de procéder par défaut serait similaire à la façon dont j'aborde Rspack. Je vais commencer par Edge. Et si Edge atteint sa limite et que je dois faire cette seule chose, je peux simplement basculer cette partie vers Node, mais je n'ai pas à réimplémenter tout mon système. Maintenant, pour Node, ça pourrait bien aller, eh bien, cela ne fonctionnera plus pour moi ici. Et je viens de le déposer dans un endroit différent. Et je suis toujours prêt à partir. Mais je peux toujours les déplacer d'avant en arrière dans le futur. Il maintient simplement cette interopérabilité là-bas. Ainsi, vous pouvez utiliser le système le mieux géré pour répondre à tous les besoins que vous souhaitez. Comme disons que nous avons utilisé Edge et nous avons eu Lambda pour quelques choses. Et imaginons que nous ayons aussi Docker. Maintenant, nous avons le calcul persistant d'EC2, qui est toujours en ligne, toujours chaud. Nous avons Edge super proche de l'utilisateur, mais pas extrêmement, comme une ressource puissante. Et nous avons Lambda, qui est un peu comme entre les deux, c'est moins cher, mais un peu plus lent à démarrer. Mais vous savez, c'est bon pour, vous savez, des chargements en rafale.

Alors maintenant, imaginez si nous avons quelque chose à dire comme un point de terminaison GraphQL, et nous voulons pousser GraphQL vers Edge. Et nous voyons en fait que nous n'obtenons pas le niveau de mise en cache ou d'optimisation que nous souhaitons avec GraphQL à la périphérie, car il y a trop d'invocations sur différents processeurs, il ne peut donc pas créer de cache interne. Alors vous pouvez dire, d'accord, eh bien, revenons plutôt sur les conteneurs où ils sont toujours chauds. Et ils peuvent avoir une grande mémoire cache de données et donc à travers des systèmes comme celui-ci, vous pouvez simplement dire, d'accord, nous allons l'envoyer ici au conteneur Docker. Et maintenant Docker devient GraphQL. Pour moi, et vous savez, tout mon rendu, déplaçons-le vers Edge. Et oh, eh bien, ce petit gestionnaire Lambda doit faire quelques choses. C'est un peu lourd en mémoire, mais nous allons le mettre sur Lambda pour l'instant. Et puis peut-être que si nous l'optimisons à l'avenir, nous le renverrons à un autre bord. Mais imaginez faire cela avec presque comme une interface utilisateur où vous pourriez simplement faire glisser et déposer des briques dans un seau comme si je voulais que cette télécommande s'exécute ici et celle-là là-bas. Et vous n'avez pas vraiment besoin de penser à la mise en réseau et au câblage, mais si c'était quelque chose d'aussi simple que vous le savez, faites glisser le carré sur le type de machine que vous souhaitez faire fonctionner. Voilà, ou peut-être qu'un plus amélioré serait un, nous essayons de trouver automatiquement le meilleur endroit pour l'exécuter. Et nous apprenons de chaque exécution réussie. Et nous pouvons ajuster la façon dont les choses sont calculées en fonction de leur fonctionnement et trouver le chemin le plus optimisé qui vous donne le plus de performances. Et si quelque chose change dans l'infrastructure, le système pourrait alors réagir immédiatement à ce changement, comme une panne sur nous sur AWS. Nous pourrions dire, d'accord, nous allons passer de Lambda à Edge, ce n'est peut-être pas parfait, mais nous allons simplement réaffecter tout le calcul quelque part où nous savons fonctionner pendant qu'AWS rencontre des échecs, ce qui est plutôt agréable. Et généralement, cela doit être fait via le multi-cloud. Tout est basé sur une infrastructure pour le faire, généralement en téléchargeant des fichiers Zip à plusieurs endroits différents. Mais sous ce type de modèle, c'est plus juste bien, voici un ordinateur zombie et dites-lui quoi faire.

Alors maintenant, tout ce qui vous intéresse, c'est la volonté, quelle est la commande dont je vais lui dire de s'occuper à ce moment-là.

Victoria Luri :

D'accord, merci pour le partage. C'était vraiment super intéressant et utile.