Smashing Podcast Épisode 29 Avec Leslie Cohn-Wein : Comment Netlify Dogfood The Jamstack ?

Dans cet épisode, nous demandons à quoi ressemble le dogfood du Jamstack chez Netlify. Pouvez-vous déployer une application entière sur un CDN ? Drew McLellan s'entretient avec l'ingénieur du personnel de Netlify, Leslie Cohn-Wein, pour le savoir.

Afficher les remarques

• Le site personnel de Leslie
• Leslie sur Twitter
• Netlifier

Mise à jour hebdomadaire

• Une plongée dans React et Three.js à l'aide de react-three-fiber
  écrit parFortune Ikechi
• Meilleures pratiques pour la conception d'interface utilisateur de commerce électronique
  écrit par Suzanne Scacca
• Authentification des applications React avec Auth0
  écrit par Nefe Emadamerho-Atori
• De la part des experts : Développements mondiaux de l'accessibilité numérique pendant la COVID-19
  écrit parRobin Christopherson
• Quoi de neuf dans Vue 3 ?
  écrit par Timi Omoyeni

Transcription

Drew McLellan : C'est une spécialiste du frontend primée originaire d'Austin, mais qui vit maintenant à Dallas, au Texas, via un passage à New York. Pendant cette période de travail pour des agences, elle a créé des sites pour des clients tels que Nintendo, WorldPride et Jerry Seinfeld. Elle est maintenant ingénieure frontend chez Netlify, où elle travaille, entre autres, à développer l'application que les clients utilisent pour gérer leur service et leurs déploiements. Donc, nous savons qu'elle est une ingénieure front-end accomplie, mais saviez-vous que lorsqu'elle vivait à New York, elle a été juge adjointe de la cuisine du chili trois années de suite. Et celui-là est en fait vrai. Mes chers amis, veuillez accueillir Leslie Cohn-Wein. Salut, Leslie. Comment vas-tu?

Leslie Cohn-Wein : Je suis fracassant.

Drew: Je voulais vous parler aujourd'hui de la façon dont Netlify mange en quelque sorte sa propre nourriture pour chien, pour utiliser cette expression charmante, lorsqu'il s'agit de s'appuyer sur le Jamstack. Je devrais mettre cela un peu en contexte en disant que jusqu'à il y a quelques mois, nous travaillions ensemble dans la même équipe chez Netlify. Et quand je suis arrivé là-bas, le processus de développement m'était en fait vraiment étranger, même après 20 ans en tant que développeur. Je pensais que c'était vraiment fascinant et qu'il valait la peine d'être exploré un peu, avec un public plus large. Je devrais probablement souligner que nous parlons de cela parce que cela fait une étude de cas vraiment intéressante et ce n'est pas une grande publicité sponsorisée pour Netlify. Tout le monde devrait visiter Vercel. Mais je pense qu'il y a beaucoup de choses précieuses qui peuvent être apprises en en discutant, en particulier du point de vue de Jamstack. Parce que Netlify est un très grand partisan de l'approche Jamstack et que le service est en quelque sorte offert au client et est construit autour de cette idée de construire des projets Jamstack. Mais le service est également construit en utilisant ces principes lui-même. N'est-ce pas?

Leslie : Ça l'est, ouais. Beaucoup de gens pensent en quelque sorte à cette architecture Jamstack comme à des sites statiques, mais nous sommes vraiment en train de comprendre ce que cela signifie de créer une application Jamstack avec l'interface Netlify. Parce que c'est une application React qui est une application Jamstack complète que nous déployons Netlify sur Netlify donc… Oui, nous l'essayons vraiment et repoussons les limites de ce qui est possible.

Drew: Je pense qu'il y a parfois cette idée que Jamstack est idéal pour les sites statiques, comme vous le dites, et l'aspect API entre en jeu si vous souhaitez envoyer un formulaire à une adresse e-mail et vous pouvez simplement faire quelque chose de simple comme ça, mais vous peut éventuellement créer une application Web complète de cette façon. Mais, vous faites ça, n'est-ce pas ?

Leslie : Oui, absolument. Notre application, qui parle spécifiquement de ce que vous voyez si vous vous connectez à app.netlify.com, est alimentée par… nous avons une API REST interne, mais l'interface, comme je l'ai dit, est du pur Jamstack. Nous avons donc notre propre étape de construction, nous regardons l'application au fur et à mesure qu'elle se construit dans l'application et nous la déployons sur notre propre système.

Drew : Donc, lorsqu'il y a un processus backend impliqué, et qu'il y aura toujours une sorte de processus backend, vous savez, des données persistantes ou, dans le cas de Netlify, en commençant par un déploiement ou quoi que ce soit d'autre, ce backend juste est en quelque sorte construit comme une série d'API qui peuvent ensuite être consommées par le frontend ?

Leslie : Oui, il existe donc plusieurs modèles différents pour que cela fonctionne. Dans la plupart des cas, dans notre application, nous utilisons la récupération côté client avec React, n'est-ce pas ? Ainsi, nous servons une sorte de shell statique de l'application, puis nous récupérons les informations de l'utilisateur à partir de notre API REST interne au moment de la demande. Jamstack est intéressant car il y a certaines choses que vous pouvez pré-construire, et nous essayons de nous y fier quand nous le pouvons. Et puis, lorsque nous parlons de certaines des données les plus dynamiques, nous utiliserons cette récupération côté client afin de nous assurer que nous extrayons les données les plus récentes.

Drew : Je pense que cela m'a surpris, lorsque j'ai commencé à travailler sur l'application, à quel point le front-end était réalisé, en particulier en ce qui concerne l'interaction avec les API externes et autres. Je sais que lorsque Netlify interagit avec votre fournisseur Git, il va donc sur GitHub et obtient une liste de la liste des dépôts, tout se passe entre votre navigateur et GitHub. Et à part peut-être le… passer par une fonction sans serveur qui met des secrets sur la demande ou quelque chose de léger comme ça, la plupart de cela se passe simplement d'une manière Jamstack-y. Il ne passe pas par une sorte d'infrastructure dorsale de base de Netlify. Donc, c'est assez fascinant. Cela va vraiment bien au-delà d'un simple site statique avec quelques appels d'API pour faire de petites choses. C'est cette véritable fonctionnalité de base, n'est-ce pas, qui est implémentée dans le navigateur ?

Leslie : Absolument. Cela pousse vraiment, je pense, ce concept de ce qu'est un ingénieur développeur frontend, n'est-ce pas? Et c'est quelque chose qui me pousse, en tant qu'ingénieur frontend, à être meilleur et à réfléchir davantage à ce genre de… la couche API, qui n'est pas quelque chose dont j'ai toujours été aussi proche. Je travaille davantage dans l'interface utilisateur, les couleurs et les systèmes de conception, et donc c'est vraiment… J'ai en fait découvert que travailler sur une application Jamstack à grande échelle m'a poussé à être un meilleur développeur.

Drew : Être un développeur front-end, ce n'est pas connaître le CSS à l'envers, bien que cela en fasse partie. Il ne s'agit pas de connaître le HTML à l'envers, mais cela en fait partie. C'est aussi s'égarer dans ce territoire qui était traditionnellement l'apanage d'un ingénieur backend, ce qui est assez intéressant. Netlify utilise-t-il un nouveau rendu côté serveur pour-

Leslie : Pas que je sache.

Drew : Donc, tout est littéralement fait, comme vous le dites, vous servez un shell, puis il est rempli de requêtes vers différents points de terminaison d'API pour en quelque sorte tout remplir.

Leslie : Exactement.

Drew : Et vous dites que c'est une application React ?

Leslie : Oui. Oui. Réagir. Nous utilisons React Redux en ce moment, et en ce moment nous sommes PostCSS, mais nous expérimentons également notre architecture CSS.

Drew : Ne le sommes-nous pas tous ? Donc, vous construisez l'application dans React puis vous la déployez sur Netlify ?

Leslie : Oui. Peut-être que ma partie préférée de tout ce processus est la magie de Deploy Previews, que nous obtenons via Netlify. Donc, ce qui se passe, c'est que vous allez… vous travaillez dans GitHub, vous augmentez vos relations publiques. Ainsi, vous ouvrez votre PR dans GitHub, et cela va créer automatiquement une version de votre aperçu de déploiement de l'application. Donc, nous utilisons en fait Deploy Previews de l'application elle-même pour tester, pour nous assurer que tout fonctionne comme il se doit. Nous effectuons nos tests. C'est ce que nous utilisons pour vérifier manuellement lors de la révision du code. Donc, nous avons en quelque sorte tout ce déploiement continu mis en place directement depuis GitHub.

Leslie : Et puis l'une des autres choses intéressantes que nous avons mises en place est que nous avons en fait quelques sites Netlify différents qui tirent du même référentiel où se trouve notre application. Donc, nous avons tous les deux notre application, nous avons une instance de Storybook qui contient en quelque sorte nos composants d'interface utilisateur pour l'application. Donc, nous avons à la fois notre application elle-même, nous avons les composants de l'interface utilisateur Storybook et nous avons essentiellement un site Netlify qui affiche notre interface utilisateur Storybook. Et puis nous avons également un troisième site qui exécute un analyseur de bundles Webpack. Donc, c'est une interface utilisateur visuelle qui vous donne une carte arborescente, une visualisation de tous les ensembles d'applications, et nous pouvons en quelque sorte évaluer leur taille, et c'est juste un rappel pour nous de revérifier en quelque sorte. À chaque déploiement de l'application, nous pouvons vérifier et nous assurer que nous ne faisons rien de bizarre avec la taille de notre bundle. Ainsi, ces trois sites sont générés dans une seule demande d'extraction de l'application. Ainsi, vous obtiendrez des liens pour prévisualiser, vos aperçus de déploiement essentiellement, à la fois de l'application Storybook et de ce profil d'application pour que nous puissions vérifier.

Drew : Et avec les aperçus de déploiement, cela devient essentiellement votre environnement de mise en scène, n'est-ce pas ?

Leslie : Exactement. Nous n'exécutons pas vraiment un environnement de mise en scène traditionnel, car nous sommes convaincus que nos aperçus de déploiement sont essentiellement ce qui va être mis en ligne lorsque nous appuierons sur ce bouton de fusion et lancerons la version officielle de notre branche principale dans notre application principale. Donc, j'aime le fait que nous puissions compter sur Deploy Previews comme environnement de staging. Nous espérons vraiment que cela correspondra à la production. Nous le construisons avec toutes les variables de production, tout ce qui… les variables d'environnement, tout cela est intégré dans l'aperçu de déploiement. Donc, c'est à peu près comme une situation sans souci. Tant que votre aperçu de déploiement fonctionne, vous savez que l'application fonctionnera également.

Drew : Et je suppose qu'en tant qu'organisation, si votre aperçu de déploiement ne correspond pas à ce qui est mis en ligne, alors c'est un problème de service que Netlify veut résoudre. Donc, cela fonctionne plutôt bien de ce point de vue. Donc, vous avez passé en revue un aperçu de déploiement, tout a l'air génial, le PR est fusionné. Que se passe-t-il alors ?

Leslie : Donc, étant donné que Netlify gère l'ensemble de notre déploiement continu, nous avons essentiellement tout connecté pour que toute fusion dans notre branche principale déclenche automatiquement un déploiement de production officiel avec l'application. Donc, généralement, si vous êtes le développeur qui a fusionné votre propre PR, vous entrerez dans le réel… vous devez vous assurer de vérifier vos onglets, car si vous avez un aperçu de déploiement de l'application ouverte et l'application, vous devez vous assurer que… vous voulez généralement suivre dans la vraie application. Donc, vous devez vérifier votre onglet. Mais, oui, dans l'application, vous entrez généralement, vous pouvez regarder les journaux de construction pour cette fusion que vous venez de lancer, donc tout est automatique. Et puis dès que ces journaux de construction sont terminés et que le site est en ligne, tout ce que vous avez à faire est d'actualiser la fenêtre de votre navigateur et vous verrez que tout ce que vous venez de déployer devrait être mis à jour dans l'application.

Drew : Et disons que vous détectez un problème une fois qu'il est en ligne, que faites-vous alors ?

Leslie : C'est une très bonne question. Et peut-être que l'une de mes choses préférées à propos de l'utilisation de Netlify avant même de travailler chez Netlify, c'était comme un peu de magie pour moi, car Netlify a en quelque sorte intégré, ce que nous appelons, des retours en arrière. Donc, essentiellement chaque déploiement sur Netlify… parce que nous utilisons cette architecture Jamstack, chaque déploiement est atomique. Donc, cela signifie que vous avez cet historique complet de chaque type de déploiement que vous avez effectué sur un site, et que vous pouvez instantanément revenir à l'un d'entre eux. Donc, si nous déployons accidentellement un bogue ou si quelque chose est cassé, la première chose que nous faisons généralement est d'arrêter cette intégration continue. Donc, nous allons entrer et c'est juste un bouton dans l'interface utilisateur Netlify que vous dites, "Arrêtez la publication automatique", et ce que cela fera, c'est qu'il arrête cette connexion avec GitHub. Donc, si mon coéquipier fusionne soudainement aussi son PR, nous n'allons pas réintroduire le bogue, rien de tel ne se produira.

Leslie : Donc, nous arrêtons tous ces déploiements automatiques. Et puis tout ce que j'ai à faire est de revenir dans ma liste de déploiements et de trouver le dernier déploiement fonctionnel, d'appuyer sur un autre bouton indiquant "Publier celui-ci" et il est mis en ligne. Donc, ce que cela fait, c'est qu'il enlève cette pression pour pouvoir vraiment revenir en arrière, regarder le code, comprendre ce qui s'est réellement passé. Parfois, cela signifie faire un retour Git sur votre branche principale et remettre la branche principale là où elle devait être. Et parfois, c'est un correctif ou vous partez sur une branche et vous la réparez et vous n'avez même pas vraiment besoin de vous soucier de revenir en arrière dans Git. Et puis, lorsque vous êtes prêt à revenir en arrière, vous vous assurez que tout fonctionne sur votre aperçu de déploiement de l'application, et vous pouvez simplement réinitialiser tout cela. Ainsi, dès que vous démarrez ces déploiements automatiques, vous êtes essentiellement de retour aux affaires.

Drew : Donc, j'ai repéré un problème ici.

Leslie : Euh oh.

Drew : Vous utilisez Netlify pour déployer des modifications dans l'application Netlify. Que se passe-t-il si le bogue que vous avez déployé vous empêche de revenir en arrière ? Que faites-vous alors?

Leslie : J'ai des cauchemars. Non. En fait, nous avons plusieurs façons de gérer cela. Ainsi, si nous supprimons l'application et que nous ne pouvons pas utiliser l'interface utilisateur pour suivre ce processus, nos aperçus de déploiement s'exécutent en fait sur notre API de production. Donc, ce que cela signifie, c'est que même si l'application ne fonctionne pas, nous avons toujours ces déploiements atomiques. Donc, si vous avez un lien de GitHub, peut-être d'un PR ancien ou récent, et que vous avez cette URL de déploiement de l'aperçu, vous pouvez en fait accéder à l'aperçu du déploiement de l'application et apporter les modifications dont vous avez besoin, revenir en arrière et publier un ancien déploiement à partir de l'aperçu du déploiement. Et il frappe toujours notre API de production, donc cela affectera toujours l'application, puis cela ramènera l'application. C'est comme une sorte d'emoji cérébral qui explose là-bas, mais c'est une façon de le faire. Nous pourrions également publier un déploiement plus ancien à partir de certains de nos systèmes principaux. Nous pourrions demander à nos ingénieurs backend de publier cela pour nous. Ou vous pouvez toujours utiliser Git pour revenir en arrière et essayer de pousser cela, mais c'est un peu effrayant parce que vous ne pouvez pas regarder ce que vous faites.

Drew : Je suppose que vous avez juste besoin d'un esprit très clair pour gérer cette situation.

Leslie : Ouais.

Drew : Mais c'est totalement récupérable, ça y ressemble.

Leslie : Ouais. Eh bien, et une fois que vous avez publié votre déploiement de travail, toute la pression est retombée. C'est vraiment la partie la plus agréable. Et j'ai aussi trouvé cela en travaillant dans des agences. Pouvoir revenir en arrière a vraiment été une bouée de sauvetage pour… Cela vous rend également moins inquiet à l'idée de publier de nouvelles modifications. Si vous cassez quelque chose, il faut une seconde pour le faire reculer, ce qui correspond très bien au type de mouvement rapide et de modèle de sortie des choses.

Drew : Absolument. Je pense que généralement, ce type de flux de travail complet fonctionne mieux lorsque vous traitez de très petits changements. Je veux dire, idéalement, vous voulez créer une branche, mettre en œuvre un petit changement, créer un PR, puis le faire fusionner le plus rapidement possible. Ce qui fonctionne évidemment bien pour les ajustements et les corrections de bogues et de petites choses, mais cela ne fonctionne pas si bien pour le travail majeur sur les fonctionnalités lorsque cette fonctionnalité peut prendre des semaines, voire des mois, à partir du moment où elle est prête à être déployée. Comment gérez-vous ce genre de processus?

Leslie : Oui, c'est une excellente question. Nous avons donc récemment commencé à utiliser un peu plus les indicateurs de fonctionnalité. Avant de parler un peu plus de la façon dont nous procédons, je vais parler de ce que nous faisions auparavant. Donc, avant que nous n'utilisions des drapeaux de fonctionnalité, je pense que tout le monde est en quelque sorte familier avec l'idée de la branche de fonctionnalité à long terme. Nous les détestons tous, n'est-ce pas ? Mais nous travaillerions sur nos petits PR. Nous fusionnerions chacun de ceux-ci individuellement, après la révision du code, dans cette branche de fonctionnalités plus longue. Ainsi, vous auriez simplement toutes vos nouvelles fonctionnalités au même endroit, vous pourriez avoir un aperçu de déploiement avec lequel vous pouvez tester cette nouvelle fonctionnalité. Parfois, ce type de modèle nécessitait des déploiements coordonnés entre d'autres équipes. Ainsi, lorsque nous étions prêts à dire : « D'accord, cette branche de fonctionnalités, nous sommes prêts à la fusionner et à la mettre en ligne », cela signifiait parfois : « D'accord, vous devez vous assurer que le backend a déjà déployé son changement », donc peu importe Le travail d'API que nous effectuons dans notre fonctionnalité est prêt à démarrer. S'il y a des documents sur notre site de documentation qui doivent être mis en ligne en même temps que la fonctionnalité, vous devez en quelque sorte vous coordonner et appuyer sur les boutons en même temps.

Leslie : Ce modèle est… il a fonctionné pour nous, mais vous avez raison, ce n'était peut-être pas le plus fluide. C'est en fait assez drôle, notre co-fondateur et PDG de Netlify, Matt Biilmann, a en fait lancé notre fonction d'analyse en utilisant ce processus sur scène à Jamstack Conf London l'année dernière. Ainsi, il a utilisé notre fonction de déploiement de verrouillage pour prendre l'aperçu du déploiement de la nouvelle fonctionnalité d'analyse et la publier en direct sur scène. Donc, c'était plutôt cool.

Leslie : Mais, comme tu l'as dit, c'est… tu as un peu moins confiance en toi. Tout est encore en quelque sorte caché dans cette Pull Request. Cela devient un peu lourd. Quelqu'un doit approuver cette demande d'extraction finale qui est généralement assez volumineuse. C'est un peu écrasant. Donc, de nos jours, nous utilisons principalement des indicateurs de fonctionnalité. Nous utilisons un service appelé LaunchDarkly, qui nous permet essentiellement d'envelopper notre nouvelle interface utilisateur avec ces indicateurs, afin que nous puissions continuer à fusionner du code en continu, même si l'interface utilisateur n'est pas quelque chose que nous voulons que les clients voient. Donc, vous vous assurez simplement dans l'environnement de production que votre indicateur de fonctionnalité est désactivé, nous pouvons déployer le code, le fusionner, et personne... en supposant que vous êtes un utilisateur général, vous ne verrez pas cette nouvelle interface utilisateur.

Drew : Donc, un indicateur de fonctionnalité est fondamentalement comme un commutateur dans le code qui dit : "Si cette fonctionnalité est activée, utilisez ce nouveau code, sinon utilisez cet ancien code."

Leslie : Exactement.

Drew : Cela signifie-t-il que vous obtenez une sorte de base de code désordonnée avec tous ces forks en place ? Comment gérez-vous cela?

Leslie : Ouais, je pense que c'est… toute personne qui utilise des drapeaux de fonctionnalité est probablement habituée à ce genre de bataille de quand nettoyez-vous les drapeaux de fonctionnalité ? Combien de temps les laisses-tu là ? Nous avons en quelque sorte atterri environ deux semaines après la sortie d'une fonctionnalité majeure, c'est que nous avons des rappels. Heureusement, LaunchDarkly a récemment mis en place une fonctionnalité qui notifiera Slack. Donc, vous pouvez le connecter à Slack, et il vous dira simplement : « Hé, votre drapeau de fonctionnalité a été… Vous êtes en production depuis deux semaines. Il est temps d'aller vous assurer de nettoyer votre drapeau dans le code.

Leslie : Donc, nous essayons de le nettoyer assez rapidement, mais c'est, entre-temps, c'est bien de savoir que le drapeau est toujours là. Même si vous avez publié la fonctionnalité, cela signifie qu'encore une fois, en un clic, vous pouvez entrer et désactiver ce drapeau, il y a un bogue, s'il y a quelque chose qui apparaît. Donc, nous aimons les laisser un peu, juste pendant que la fonctionnalité est vraiment en train de cuire, pendant que les gens s'y habituent, pour s'assurer qu'il n'y a pas de problèmes majeurs. Mais ensuite, nous essayons de revenir dans le code et c'est un peu de nettoyage, donc ce n'est pas un processus idéal, mais généralement supprimer le drapeau ne prend pas très longtemps, vous supprimez simplement quelques lignes de code.

Drew : Donc, je suppose que l'approche la plus simple pour implémenter un indicateur de fonctionnalité pourrait simplement être une... comme une variable de configuration dans votre application qui dit : "Cette fonctionnalité est activée ou désactivée", mais vous avez besoin d'un moyen de vous assurer que il est allumé pour les bonnes personnes et éteint pour les bonnes personnes. Et je suppose que c'est là qu'un service comme LaunchDarkly entre en jeu, parce qu'il faut que… Je veux dire, il faut essentiellement ce qui active et désactive une variable à un niveau extrême, n'est-ce pas ?

Leslie : Oui. Oui. C'est exactement ça. Donc, nous aurions pu, même sans LaunchDarkly, configurer nous-mêmes une variable de configuration que nous gérons en quelque sorte de notre côté. L'une des choses que j'aime à propos de LaunchDarkly est qu'il existe différents environnements. Donc, ce que nous pouvons faire, c'est essentiellement activer un indicateur de fonctionnalité pour nos aperçus de déploiement. Ainsi, toute personne qui consulte en interne chez Netlify, un aperçu du déploiement de l'application peut avoir accès à la nouvelle fonctionnalité, peut la tester, mais encore une fois, dès qu'elle est mise en production, ce drapeau est éteint. Donc, il y a très peu… encore une fois, vous devez en quelque sorte vérifier votre onglet et vous assurer que vous êtes conscient du segment dans lequel vous vous trouvez, car vous ne voulez pas vous surprendre et penser que vous avez lancé quelque chose qui vous ne l'avez pas fait, vous devez être un peu prudent là-bas. Mais, en général, cela fonctionne assez bien, et LaunchDarkly vous permet également de faire ces déploiements sélectifs. Ainsi, vous pouvez déployer une fonctionnalité sur un certain pourcentage de votre base de code ou sur un segment d'utilisateurs spécifique, des personnes avec un type de plan spécifique ou un type d'utilisateur spécifique. Donc, cela vous permet beaucoup plus de contrôle sur qui vous libérez en quelque sorte.

Drew : Ouais. Cela peut être très puissant, je suppose, en particulier avec de nouvelles fonctionnalités ou fonctionnalités dont vous pourriez vous attendre à résoudre un problème. Peut-être que vous améliorez une fonctionnalité pour la rendre plus compréhensible, vous pouvez peut-être l'essayer avec 10 % des utilisateurs et voir s'ils rencontrent les mêmes problèmes et…

Leslie : Exactement. C'est aussi un excellent moyen d'obtenir des commentaires, oui.

Drew : Je suppose qu'utiliser LaunchDarkly de cette manière, plutôt que de lancer votre propre solution, est un autre aspect de l'approche Jamstack, n'est-ce pas ? Il s'agit simplement d'utiliser une API qui vous donne cette fonctionnalité sans avoir à vous soucier de la façon dont vous l'implémentez vous-mêmes et comment la développer et comment la maintenir et la conserver afin que vous puissiez simplement l'externaliser, dites : "Bien, nous sommes va utiliser cette API et tout le reste est pris en charge.”

Leslie : Oui. Oui, exactement.

Drew : Donc, cette approche vous permet de mettre en production essentiellement de petites parties de nouvelles fonctionnalités, mais elles sont en quelque sorte cachées derrière le drapeau. Et puis, quand tout est prêt, vous pouvez simplement retourner le drapeau et le remettre rapidement en place si quelque chose ne va pas.

Leslie : Oui, exactement. Cela rend nos lancements un peu moins excitants. Auparavant, vous appuyiez sur ces gros boutons et il y a tout ce code qui est fusionné et vous regardez vos journaux de construction et c'est ce moment d'anticipation. Et maintenant, vous sautez sur un appel Zoom, vous cliquez sur un bouton, et c'est en direct.

Drew : Ouais. Je pense que le dernier lancement de fonctionnalité, j'ai travaillé sur un Netlify, nous avons utilisé cette approche. Et cela avait été des semaines de travail pour toute une équipe de personnes, et nous avons eu un appel Zoom pour coordonner la sortie, et tout le monde a confirmé que leurs pièces étaient prêtes. Et puis j'ai retourné l'indicateur de fonctionnalité et l'ai activé pour tous les utilisateurs, et c'était tout.

Leslie : C'est fait.

Drew : Et c'était fini en quelques minutes et c'était vraiment décevant.

Leslie : Ouais, c'est un peu triste.

Drew : Il n'y avait pas de mains moites, il n'y avait rien, ce qui est bien sûr exactement ce que vous voulez, n'est-ce pas ? C'est ainsi que vous savez que vous disposez d'un processus robuste, si activer quelque chose pour tout le monde n'est tout simplement pas un gros problème.

Leslie : Exactement. Et si vous devez l'annuler, encore une fois, c'est aussi simple que cela, c'est ce clic. Cela soulage une partie de cette pression, de cette anxiété.

Drew : Donc, probablement, je veux dire, tous les changements ne seront pas seulement des changements frontaux. Parfois, il y aura des changements de backend, et ils ont probablement leurs propres indicateurs de fonctionnalité également dans la plupart des systèmes backend. Donc, vous avez également mentionné les documents. Y a-t-il un moyen de coordonner tout cela ensemble? Est-ce que tout le monde retourne son drapeau en même temps ? Ou comment ça marche ?

Leslie : Ouais. Donc, c'est un domaine sur lequel nous travaillons activement dans toutes les équipes en ce moment chez Netlify, nous travaillons sur une solution qui nous permettrait peut-être de tout lier à un seul drapeau dans LaunchDarkly, que tous nos systèmes utilisent , toutes nos bases de code utilisent. Ainsi, dans un monde idéal, nous serions en mesure de retourner un indicateur et de dire : " D'accord, il s'agit de basculer sur le nouveau point de terminaison de l'API qui est également consommé sur le frontend avec cette nouvelle interface utilisateur qui est enveloppée dans un indicateur de fonctionnalité, ainsi que cette partie du site doc, qui contient de nouvelles informations sur cette nouvelle fonctionnalité. Et vous retournez ce drapeau qui a un impact sur tous ces référentiels. Nous n'en sommes pas encore là. Nous y travaillons, mais je suis ravi de voir en quelque sorte si nous sommes en mesure de coordonner tout cela et de le faire fonctionner.

Drew : Netlify, en tant que service, est en quelque sorte adapté aux chantiers de cette manière. Le travail que vous et votre équipe faites avec le produit a-t-il réellement influencé le développement du produit ?

Leslie : Je dirais que c'est définitivement le cas. Tout le monde dit toujours que vous n'êtes pas votre utilisateur, ce qui, je pense, est vrai la plupart du temps, sauf parfois lorsque vous êtes votre utilisateur. Ce qui est drôle chez Netlify car je pense que la plupart des membres de l'équipe frontend en particulier sont des personnes qui ont déjà utilisé Netlify en tant que produit. Et certainement parce que nous utilisons Netlify pour déployer Netlify, nous rencontrons les mêmes défis que je pense que certains de nos utilisateurs rencontrent. Donc, d'une certaine manière, si nous rencontrons un problème, nous essaierons de le signaler au reste de l'entreprise. Nous le mentionnerons lors d'un appel technique ou nous demanderons à notre CTO de dire : « Hé, c'est quelque chose avec lequel nous nous débattons. Y a-t-il quelque chose que nous pourrions intégrer au produit qui faciliterait cela pour nous et pour tous nos utilisateurs qui déploient des choses similaires à nous ? » C'est donc une position unique, mais c'est amusant de voir comment la feuille de route du produit est développée.

Drew : Je suppose qu'il y a probablement peu de gens qui utilisent Netlify de manière aussi intensive que Netlify lui-même.

Leslie : Ouais. Ouais. Je pense que c'est à peu près juste. Je regarde Netlify à la fois quand je le construis et quand je le déploie, donc je le connais assez bien.

Drew : Et puis le week-end, vous travaillez sur un projet parallèle et vous vous retrouvez à nouveau dans Netlify.

Leslie : Ouais. C'est en fait très vrai. Ouais. Oui. Oui en effet.

Drew : Avez-vous des exemples de la manière dont la direction du produit a été influencée par le travail effectué par l'équipe ?

Leslie : Ouais. Ainsi, nous avons récemment lancé un nouveau type de tableau de bord d'atterrissage pour l'application que nous appelons The Team Overview. Ainsi, autrefois, lorsque vous vous connectiez à Netlify, vous atterrissiez sur la page du site, qui consistait essentiellement en une longue liste de vos sites. Et nous voulions donner aux gens un peu plus une zone de contrôle de mission où ils peuvent en quelque sorte voir beaucoup d'informations importantes en un coup d'œil, accéder aux choses qui leur seront les plus utiles. Et donc, c'était une nouvelle fonctionnalité que nous avons construite. Dans l'itération initiale, nous essayons de le sortir rapidement, nous avons une petite carte sur cette interface utilisateur qui renvoie à vos dernières versions. Il vous montre toute construction de toute votre équipe, devrait apparaître dans cette carte.

Leslie : Et au début, nous n'avions en fait pas lié ceux-ci à la construction… le journal d'affichage lui-même. Donc, c'était juste une liste où vous pouviez la vérifier. Vous pouvez cliquer sur la page des versions pour obtenir une sorte de vue similaire. Mais je travaillais en fait sur quelque chose pendant le week-end, un site personnel, et j'avais cette vue d'ensemble de l'équipe activée et j'étais ennuyé parce que j'ai réalisé que je me suis connecté à Netlify et que je voulais aller voir cette version qui se passait de mon projet, et je ne pouvais pas simplement cliquer dessus et y accéder directement. J'ai dû cliquer sur la page des versions, puis cliquer à nouveau. Donc, le lendemain au travail, je suis entré et j'ai ajouté ce changement et j'ai lié ces versions parce que cela me dérangeait. Donc, c'était un exemple d'une sorte de réalisation en utilisant le produit, qu'il y avait une très petite opportunité de l'améliorer. Et on a pris ça.

Leslie : Mais nous avons aussi d'autres exemples. Probablement un peu plus percutant. La première est que nous avons en quelque sorte ajouté cette fonctionnalité de détection de formulaire. Donc, un peu de contexte, si vous n'êtes pas familier, les formulaires Netlify sont une fonctionnalité de Netlify qui vous permet de créer un formulaire frontal. Et Netlify fait en quelque sorte tout le travail de gestion des soumissions. C'est un peu comme votre base de données pour votre formulaire que vous avez construit sur votre frontend. Cela signifie que vous n'avez pas à écrire de code côté serveur ni beaucoup de code JavaScript supplémentaire pour gérer les soumissions de formulaires. Vraiment n'importe quel site que vous avez déployé sur Netlify, au fur et à mesure de votre construction, nos robots de construction analysent le code HTML de votre site au moment du déploiement pour détecter essentiellement si vous avez un formulaire Netlify auquel Netlify doit prêter attention et gérer. Et cette détection de formulaire, recherchée par le bot de construction, est activée par défaut.

Leslie : Mais ce que cela signifie, c'est que, comme vous pouvez l'imaginer, cela prend un peu de votre temps de construction parce que les bots doivent chercher cette étape supplémentaire. Donc, l'application Netlify elle-même, en fait, nous n'utilisons pas, nous n'avons pas de formulaires Netlify sur l'application pour le moment. Donc, c'est une étape qui ajoute un peu à notre temps de construction, mais cela n'a pas nécessairement besoin de se produire. Ainsi, Netlify a en fait construit une nouvelle fonctionnalité qui permet à tout utilisateur de désactiver cette détection de formulaire. Cela signifie que vous pouvez désactiver ce paramètre dans les paramètres de votre site, les robots de construction se rendent compte qu'ils n'ont rien à rechercher, vous économisez donc ce peu de temps de traitement supplémentaire dans les versions.

Drew : Je suppose que c'est formidable en termes de productivité, car les choses se terminent juste un peu plus vite.

Leslie : Exactement.

Drew : Mais aussi, en tant que service au compteur, vous permet de tirer le meilleur parti du type d'allocations dont vous disposez.

Leslie : Oui. Exactement. Et donc, c'est quelque chose que nous avons également entendu de la part de certains de nos utilisateurs et clients, et c'est quelque chose que nous avons également remarqué. C'était : « Eh bien, nous n'avons pas besoin de cette étape supplémentaire dans notre propre produit. Alors, y a-t-il un moyen, quelque chose que nous pourrions donner à tous nos utilisateurs pour rendre la vie de chacun un peu plus facile, rendre la construction de chacun un peu plus rapide s'ils n'utilisent pas cette fonctionnalité ? »

Drew : Y a-t-il un danger… Je veux dire, vous dites que vous n'êtes pas votre utilisateur, mais avec Netlify vous êtes souvent votre utilisateur. Y a-t-il un danger qu'avec l'intensité avec laquelle vous utilisez le produit, vous pourriez négliger le type d'utilisateurs qui ne l'utilisent que très légèrement et tout pourrait devenir trop complexe et trop avancé, et il deviendrait simplement très difficile d'obtenir commencé avec ?

Leslie : C'est une excellente question. Nous avons également vraiment développé notre fonction de recherche d'utilisateurs chez Netlify et notre fonction de science des données, et je pense que, dans l'ensemble, nous leur faisons beaucoup plus confiance que mon expérience anecdotique d'utilisation et de déploiement de l'application. Mais je pense que toutes ces données se rassemblent pour nous permettre d'avoir une meilleure idée de qui utilise Netlify, à quel type d'utilisateur parlons-nous ? Il y a des gens avec différents types de besoins. Nous avons des gens dans nos équipes de démarrage qui gèrent des blogs et des sites personnels, et nous avons également d'énormes entreprises, qui lancent de grandes campagnes de marketing et de grandes applications Web, pas si différentes de Netlify lui-même. Donc, c'est excitant de voir la base d'utilisateurs grandir et de réfléchir à tous ces cas d'utilisation et de comprendre comment nous pouvons répondre à tous ces utilisateurs. Et certainement en utilisant davantage nos fonctionnalités de recherche pour comprendre qui sont ces utilisateurs, et pas seulement notre expérience interne.

Drew : Parlez-moi, Leslie, du service de capture d'écran mis en place par Netlify ? Parce que j'ai trouvé ça vraiment intéressant.

Leslie : Ouais. Dans l'interface utilisateur que nous avons… lorsque vous déployez un site sur Netlify, dans l'interface utilisateur, nous avons une petite capture d'écran qui vous montre généralement à quoi ressemble la page d'accueil du site que vous avez ressentie. C'est en fait drôle que nous en ayons parlé, car j'écoutais Chris Coyier son épisode sur Serverless il n'y a pas si longtemps, et il parlait également de la façon dont ils font des captures d'écran dans CodePen, ce qui n'est en fait pas si différent de la façon dont Netlify le fait. Mais fondamentalement, nous exécutons Puppeteer pour capturer cette capture d'écran du site utilisateur, et la façon dont tout est exécuté est qu'il est configuré avec une fonction Netlify. Donc, c'est encore une fois un exemple de nous qui mangeons notre propre produit. Donc, essentiellement, nous utilisons ce point final qui est une fonction Netlify dans notre propre application pour renvoyer l'URL de cette image de la capture d'écran, que nous pouvons ensuite utiliser dans l'application.

Drew : Donc, les fonctions Netlify sont l'implémentation par Netlify d'une fonction Serverless, n'est-ce pas ? Où vous déposez simplement un fichier JavaScript dans un dossier désigné dans le cadre de votre source, puis cela devient disponible pour être exécuté en tant que fonction cloud.

Leslie : Oui, exactement.

Drew : Super intelligent, n'est-ce pas ?

Leslie : Ouais. C'est brilliant. This is one of those areas where it really pushes me as a frontend engineer to really be more of this JavaScript or Serverless engineer, and think a little bit more about how you're basically writing like an internal API end point for yourself when you create one of these Serverless functions. So, it's exciting because there's so much you can do, but that can make it a little intimidating also because there's so much you can do.

Drew: I sort of find it funny how it's like… that's seemingly a core piece of functionality for Netlify, displaying images alongside your site of what it looks like, yet, it's just implemented with another Netlify feature. And you wonder how far you go before it all disappears in on itself in a big cloud of smoke.

Leslie: Yeah. Ouais.

Drew: This sounds like a really nice way to be working, and a very modern way to we're working, but it can't be without its challenges, can it?

Leslie: Absolutely not. I think I've spoken a little bit about what it means sort of as a frontend engineer pushing into sort of some new areas just for me to be thinking about in terms of Serverless and how can we leverage this in the product? I think for me, mastering that sort of back of the frontend side has been an exciting challenge, but certainly there's a lot to learn there. An example of that in our app right now, is that we use Cypress for end-to-end testing of some of the critical flows in our app, and right now we have that set up so that the Cypress end-to-end tests are running on our Deploy Previews in Pull Requests using a GitHub action. So, we use the GitHub action to run those Cyprus tests against the Deploy Previews of the app.

Leslie: Which is really cool, but there's probably a better way to do this than actually using a GitHub action. I actually think that we could use a Netlify Serverless function because those can be triggered on certain events, like a deploy succeeded event. So, there's an opportunity there for us to actually leverage again, Netlify, a little bit more, instead of relying on some of these other tools that maybe we're more familiar with or more comfortable using. So, in terms of challenges, I think it's opening our minds to what this sort of new model of development allows us to do and trying to leverage it.

Drew: Yes, there's so many different ways on there to… with the tooling that's available, to be able to attack a particular problem. At Smashing, we probably shouldn't say there's more than one way to skin a cat.

Leslie: Yikes.

Drew: What's interesting about the workflow as well, is that it's really intensively Git based, which I think suits… it's really developer friendly, isn't it? As a frontend engineer, something that's Git based kind of just feels like home. So, is that all great or are there any problems that come in with that?

Leslie: I think as a developer Git is wonderful. I think in general it solves big, big problems and I'm very happy to have it. But, because we rely on it so heavily and as our internal team has grown as well, you end up having the same problems that Git has when you're talking about Netlify in this workflow, right? So, you end up with a bug on your main branch, yes, it's really easy to roll back the app itself, we talked through what that looks like, and then go in the code and fix it. But what if someone else on your team is working from a broken version of that main branch? Everyone's going to have to rebase, everyone's going to have to communicate, or at least be aware of what happened. And so, it's not so much a Jamstack problem or a Netlify problem, but more of just the age old, how do you coordinate on a team of human beings and how do you use the technology to do that properly?

Drew: And of course, as you add more tools and infrastructure in around what you're doing, then you've got the problem of everything taking a long time to run. I mean, you mentioned Cypress is one thing. I know Cypress is a real headache with the amount of time those end-to-end tests can take to run. Is there other challenges around that growing build time?

Leslie: Yeah, I think that's one of the other things that Jamstack… You're introducing this build time, which for developers is not great. I always try and think about it as what I sort of eat up in that build time, my users are saving in the performance of what they're getting. So, I always try to keep that in mind when I'm frustrated about how long something is taking to build, but certainly I think that's an area of opportunity and a challenge, is figuring out how to keep those build times fast, how to make sure that we can deploy as quickly as possible. Some of it is this sort of tension between wanting to run all your tests, wanting to make sure that you don't deploy a build if a test fails, but at the same time, then you've got to run all those tests.

Leslie: So, it's this constant sort of back and forth between wanting to keep the build times fast, while also making sure that you feel like you're doing your due diligence before you actually deploy something. And we're playing around with some ideas here as well about potentially moving our Cypress tests to be running against production and having some alerting setup that would let us know after the fact, if something had failed. Which is sort of an interesting model, too. So yeah, stay tuned.

Drew: I certainly know that, yes, the dangers of growing build times, just from a developer point of view, from productivity point of view, that if something takes too long to run, you context switch, you start working on something else, and then it just… you lose all the momentum, and maybe you forget to go back and find out whether the build succeeded because you're then so far into the next task.

Leslie: Yeah, definitely.

Drew: So, I guess this isn't the ultimate workflow as it stands at the moment. There must be further we can take it. What sort of opportunities might lie ahead for this way of working?

Leslie: Yeah. So, I think for me, and Netlify in particular, is sort of the thought of collaboration for larger teams. I mean, I know a lot of developers are sort of… have used Netlify for side projects and other things that they're working on, on their own, but thinking about how it can be leveraged on larger teams, like mine. As we get larger and we're growing, more of us are in the app, more of us are using Netlify to deploy our own services, and so everything from even more robust audit logs so that you can go and see who changed this site setting, or who was the last person to deploy something. I think having the ability to organize your sites within your Netlify dashboard, even knowing… assigning someone to a build is sort of an interesting idea to me. Could that be helpful if I knew that my teammate had worked on this build, but then I realized they had to roll it back? And maybe I'm just aware of who's managing that process could be a really useful thing within Netlify itself.

Leslie: And one thing that I've seen sort of thrown around a little bit is perhaps the ability to link to a specific log line in build log. So, for debugging, if you have your build log of your Deploy Preview, and there's an error that got thrown, either from Netlify or from your own code, it'd be nice to be able to link directly to that log line. So, that's sort of a fun, small improvement that I've been thinking about a bit. And that's not even to say we have some new features at Netlify as well, that are pretty exciting. Edge handlers and background functions. I'm still trying to wrap my head around what they all do and exactly how they work, but I know that edge handlers are going to give us the opportunity to do some things with localized content, which could be… have some interesting implications for features we could build in the Netlify app as well.

Drew: Yeah, it's really exciting. I think there are all sorts of people within the Jamstack community who are pushing this the whole thing forward. But I think Netlify, as a service, is one that is really behind it and doing exciting things. And, as I say, I didn't want this to be a big ad for Netlify, but I think you and I both really love the service, so it is exciting to talk about isn't it? If listeners want to get more engaged with learning how to build Jamstack sites or want to get more into this ecosystem, is there a good place to go to learn this stuff?

Leslie: I feel like it's exploding right now. I would certainly point you to the Netlify blog. We try and post some tips and tricks there and announce new features as well. I would give a shout out too, to Learn With Jason. My coworker, Jason Lengstorf does sort of a live stream show, and he does cover… he covers a range of topics, but does some Jamstack specific ones as well. And it's a fun hour of live coding and picking that out. Twitter, I think, is huge, too. So check out Jamstack hashtag.

Drew: Good advice. So, we've been learning all about how Netlify builds Netlify on Netlify. What have you been learning about, Leslie?

Leslie: Oh, that's always a big question. I mentioned Cypress before, we've been working through some of our processes around exactly how we want to run our end-to-end tests, and so I would say that, in general, I've been thinking a lot about that workflow. So, less about the technology itself, but more about what workflows exist for end-to-end testing on the frontend, and what makes sense sort of in this Jamstack model. So, that's been a fun sort of side tangent. And then, on the CSS side of things, we talked a bit about CSS architecture, and I'm starting to get my hands dirty with Tailwind, which has been a fun and exciting and lots to learn and lots of class names to memorize and… Yeah.

Drew: That's exciting stuff. If you, dear listener, would like to hear more from Leslie, you can find her on Twitter where she's @lesliecdubs, and her personal site is leslie.dev. Thanks for joining us today, Leslie, did you have any parting words?

Leslie: Have a great day?