Fondamentaux de JAMstack : quoi, quoi et comment

Nous adorons repousser les limites du Web, et nous avons donc décidé d'essayer quelque chose de nouveau. Vous avez probablement entendu parler de JAMstack - la nouvelle pile Web basée sur JavaScript, les API et le balisage - mais qu'est-ce que cela signifie pour votre flux de travail et quand cela a-t-il un sens dans vos projets ?

Dans le cadre de notre adhésion Smashing, nous organisons Smashing TV , une série de webinaires en direct, chaque semaine. Pas de fioritures - juste des webinaires pratiques et exploitables avec une session de questions-réponses en direct, animés par des praticiens respectés de l'industrie. En effet, le programme Smashing TV semble déjà assez dense, et il est gratuit pour les membres Smashing, ainsi que les enregistrements - évidemment .

Nous avons gentiment demandé à Phil Hawksworth d'organiser un webinaire expliquant ce que JAMStack signifie réellement et quand cela a du sens, ainsi que comment cela affecte l'outillage et l'architecture frontale. Le webinaire d'une heure est désormais également disponible. Nous ne pourrions pas être plus heureux d'accueillir Phil pour coanimer notre prochaine SmashingConf Toronto (25-26 juin) et organiser JAMStack_conf London, que nous co-organisons également les 9 et 10 juillet de cette année. Alors, allons-y !

Phil Hawksworth : Excellent, d'accord, eh bien, allons-y alors. En guise de salut très rapide, je veux dire que je vous ai déjà dit bonjour, Scott m'a fait une belle présentation. Mais oui, je travaille actuellement chez Netlify, je travaille dans l'équipe d'expérience développeur là-bas. Nous espérons avoir beaucoup de temps pour les questions-réponses, mais, comme Scott l'a mentionné, si vous n'avez pas la possibilité de poser des questions là-bas, ou si vous préférez, vous pouvez me les envoyer directement sur Twitter, donc mon compte Twitter est mon nom, c'est Phil Hawksworth, donc à tout moment, vous pouvez certainement me poser des questions sur JAMstack ou sur n'importe quoi sur Twitter.

Phil Hawksworth: Mais je veux commencer aujourd'hui juste en remontant un peu dans le temps jusqu'à cette citation qui résonne vraiment très, très fortement en moi. Ceci est une citation du merveilleux Aaron Schwartz qui, bien sûr, a tant contribué aux Creative Commons et au Web ouvert et il l'a écrit sur son blog en 2002, et il a dit: «Je me soucie de ne pas avoir à maintenir grincheux Installations du serveur AOL, Postgres et Oracle. Serveur AOL, j'ai dû lever les yeux pour me rappeler que c'était un serveur Web open source à l'époque.

Phil Hawksworth: Mais cela me parle vraiment beaucoup. Je ne veux pas non plus entretenir une infrastructure pour maintenir un blog en vie, et c'est de cela qu'il parlait. Et c'était dans ce billet de blog sur son propre blog et il était intitulé « Bake, Don't Fry ». Il choisissait un terme que quelqu'un qui avait récemment créé un CMS avait commencé à utiliser, et il a en quelque sorte popularisé ce terme sur la cuisson (Bake, Don't Fry) ; ce dont il parle ici, c'est du pré-rendu plutôt que du rendu à la demande, donc cuire le contenu à l'avance, plutôt que de le faire frire à la demande lorsque les gens viennent le demander - en éloignant les choses du moment de la demande et en un temps de construction.

Phil Hawksworth : Et lorsque nous parlons de pré-rendu et de rendu, nous entendons par là que nous parlons de générer du balisage. Je me sens un peu gêné de parler parfois de type de rendu de serveur ou de rendu isomorphe ou de beaucoup de ces termes à la mode ; J'ai été appelé il y a quelques années lors d'une conférence, Frontiers Conference à Amsterdam, alors que je parlais de rendu sur le serveur et quelqu'un m'a dit : « Vous voulez dire générer du HTML ? Juste quelque chose qui génère du HTML ? » Et c'est bien sûr ce que je veux dire.

Phil Hawksworth : Mais tout cela contribue grandement à simplifier la pile. Lorsque nous pensons à la pile à partir de laquelle nous servons des sites Web ; Je suis tout à essayer de simplifier les choses, je suis super désireux d'essayer de simplifier la pile. Et c'est en quelque sorte au cœur de cette chose appelée "JAMstack" et je veux essayer d'expliquer cela un peu. Le « JAM » dans JAMstack signifie JavaScript, API et balisage. Mais cela ne suffit pas vraiment pour nous aider à comprendre ce que cela signifie - qu'est-ce que cela signifie vraiment ?

Phil Hawksworth: Eh bien, ce que je veux essayer de faire dans la prochaine demi-heure, c'est que je veux en quelque sorte développer cette définition et donner une description plus détaillée de ce qu'est JAMstack. Je veux parler un peu de l'impact et des implications de JAMstack et, vous savez, réfléchir à ce que cela peut nous donner pour expliquer pourquoi nous pourrions le choisir. En cours de route, je vais essayer de mentionner certains des outils et services qui seront utiles, et j'espère que je terminerai avec quelques ressources que vous voudrez peut-être approfondir et peut-être mentionner quelques premières étapes pour vous aider en cours.

Phil Hawksworth : Donc, c'est le plan pour la prochaine demi-heure. Mais, je veux, en quelque sorte, revenir à cette notion de simplification de la pile, car, espérons-le, les personnes qui rejoignent cela ou sont venues regarder cette vidéo plus tard, peut-être avez-vous une idée de ce qu'est JAMstack, ou c'est peut-être un terme complètement nouveau, et vous êtes simplement curieux. Mais, en fin de compte, il y a déjà beaucoup de piles là-bas. Il existe de nombreuses façons de proposer un site Web. On a l'impression que nous construisons différents types d'infrastructures depuis très longtemps, que ce soit une pile LAMP ou la pile MAMP, ou la — je ne sais pas — la pile MEAN. Il y en a un tas qui flottent sur l'écran ici. Il y en a beaucoup et beaucoup.

Phil Hawksworth : Alors, pourquoi diable en aurions-nous besoin d'un autre ? Eh bien, JAMstack est, comme je l'ai mentionné, JavaScript/API/Markup, mais si nous essayons d'être un peu plus descriptifs, JAMstack est destiné à être une architecture moderne, pour aider à créer des sites rapides et sécurisés et des applications dynamiques avec JavaScript/ Les API et le balisage pré-rendu, servis sans serveurs Web, et c'est ce dernier point qui est, en quelque sorte, quelque chose qui le distingue et peut-être le rend un peu plus intéressant et inhabituel.

Phil Hawksworth : Cette idée de servir quelque chose sans serveurs Web, cela semble magique ou ridicule, et j'espère que nous découvrirons quoi en cours de route. Mais pour essayer de faire la lumière là-dessus et de le décrire un peu plus en détail, il est parfois utile de le comparer à ce que nous pourrions considérer comme une pile traditionnelle ou une manière traditionnelle de servir les choses sur le Web. Alors, faisons cela juste une seconde. Passons en revue, peut-être, à quoi pourrait ressembler une demande lorsqu'elle est traitée dans une pile traditionnelle.

Phil Hawksworth : Donc, dans ce scénario, nous avons quelqu'un qui ouvre un navigateur Web et fait une demande pour voir une page. Et peut-être que cette demande touche un CDN, mais probablement, plus probablement, qu'elle touche une autre infrastructure que nous hébergeons - comme les propriétaires de ce site. Peut-être avons-nous essayé de nous assurer que cela évoluera sous beaucoup de charge parce que nous voulons, évidemment, une vue très populaire et réussie. Donc, nous avons peut-être un équilibreur de charge, qui a une certaine logique, qui servira cette demande à l'un des nombreux serveurs Web que nous avons provisionnés, configurés et déployés. Il pourrait y avoir un certain nombre de ces serveurs.

Phil Hawksworth : Et ces serveurs exécuteront une logique pour dire : "D'accord, voici notre modèle, nous devons le remplir avec des données." Nous pouvons obtenir nos données à partir de l'un des nombreux serveurs de base de données qui exécuteront une logique pour rechercher certaines données, les renvoyer au serveur Web, créer une vue que nous transmettrons ensuite à travers l'équilibreur de charge. Peut-être, en cours de route, appeler CDN, stocker certains actifs dans le CDN, et je devrais clarifier, un CDN est un réseau de diffusion de contenu, donc un réseau de machines réparties sur Internet pour essayer d'obtenir un service de demande aussi proche que possible à l'utilisateur et ajouter des éléments, comme la mise en cache.

Phil Hawksworth : Nous pourrions donc y stocker des ressources et, en fin de compte, renvoyer une vue dans le navigateur, dans les yeux de l'utilisateur, qui pourra ensuite découvrir le site que nous avons construit. Donc, évidemment, c'est soit une simplification excessive, soit une vue très générale de la façon dont nous pourrions traiter une demande dans une pile traditionnelle. Si nous comparons cela au JAMstack, qui gère les choses d'une manière légèrement différente, voici à quoi cela pourrait ressembler.

Phil Hawksworth : Donc, encore une fois, même scénario, nous commençons dans un navigateur Web. Nous faisons une demande d'affichage de la page, et cette page est déjà dans un CDN. Il sert de manière statique à partir de là, il est donc renvoyé à l'utilisateur, dans le navigateur, et nous avons terminé. Donc, évidemment, une vue très simplifiée, mais tout de suite, vous pouvez commencer à voir les différences ici en termes de complexité. En termes d'endroits dont nous avons besoin pour gérer le code, coder en profondeur, toutes ces différentes choses. Donc, pour moi, l'un des principaux attributs d'un JAMstack, c'est que cela signifie que vous construisez un site capable d'être servi directement à partir d'un CDN, ou même d'un serveur de fichiers statique. CDN est quelque chose que nous pourrions vouloir mettre en place pour gérer la charge, mais en fin de compte, cela pourrait être servi directement à partir de n'importe quel type de serveur de fichiers statique, type d'infrastructure d'hébergement statique.

Phil Hawksworth : JAMstack, en quelque sorte, offre une opportunité de réduire la complexité. Rien qu'en comparant ces deux parties du diagramme sur lesquelles nous reviendrons quelques fois, au cours de la prochaine demi-heure, vous pouvez voir que c'est une opportunité de réduire la complexité et de réduire les risques. Et donc, cela signifie que nous pouvons commencer à profiter de certains des avantages de servir des actifs statiques, et je vais parler de ce que c'est un peu plus tard. Mais vous regardez peut-être cela et pensez: "Eh bien, super, mais n'est-ce pas juste le nouveau nom des sites Web statiques?" C'est une chose raisonnable à me dire quand je dis: "Nous allons servir les choses de manière statique."

Phil Hawksworth : Mais je veux revenir là-dessus. Je veux en parler un peu plus, mais tout d'abord, je veux, en quelque sorte, parler de cette notion de piles et qu'est-ce qu'une pile, de toute façon ? Et je considère une pile comme les couches de technologie qui fournissent votre site Web ou votre application. Et nous ne parlons pas du pipeline de construction ou du processus de développement, mais la façon dont nous desservons les sites peut certainement avoir un impact important sur la façon dont nous développons et déployons les choses, etc.

Phil Hawksworth : Mais ici, nous parlons de la pile technologique, des couches de technologie, qui livrent réellement votre site Web et votre application aux utilisateurs. Alors, faisons une autre petite comparaison. Parlons un peu de la pile LAMP.

Phil Hawksworth : La pile LAMP, vous vous en souvenez peut-être, est composée d'un serveur Web apache, pour faire des choses comme le routage HCP et le service des actifs statiques. PHP, pour certains pré-traitements, donc joli traitement hyper-texte ; appliquer la logique, peut-être construire les vues pour les modèles et ce que vous avez. Et a un certain accès à vos données, par mon NISQL, puis LINUX est le système d'exploitation qui se trouve sous tout cela, maintient tout cela en vie. Nous pouvons résumer cela théoriquement en tant que serveur Web. Et nous pouvons avoir plusieurs de ces serveurs, en quelque sorte, assis ensemble pour servir un site Web.

Phil Hawksworth : C'est une sorte de regard traditionnel sur la pile LAMP, et si nous comparons cela à la pile JAM, eh bien, ici, il y a un changement critique. Ici, nous montons en fait au niveau supérieur, plutôt que de penser au système d'exploitation et à la façon dont nous exécutons la logique pour fournir un site Web. Ici, nous supposons que nous allons servir ces choses de manière statique. Donc, nous faisons le routage ACP et le service des actifs à partir d'un serveur statique. Cela peut être raisonnablement fait. Nous sommes devenus très bons dans ce domaine, au fil des ans, en créant des moyens de fournir des sites Web statiques ou des actifs statiques.

Phil Hawksworth : Cela pourrait être un CDN, et encore une fois, nous en reparlerons dans un instant. Mais le domaine qui nous intéresse, se passe davantage dans le navigateur. Donc, ici, c'est là que notre balisage est livré et analysé. C'est là que JavaScript peut s'exécuter, et cela se passe dans le navigateur. À bien des égards, le navigateur est devenu le moteur d'exécution du Web moderne. Plutôt que d'avoir le runtime dans l'infrastructure du serveur elle-même, nous avons maintenant déplacé cela d'un niveau, plus près de l'utilisateur et dans le navigateur.

Phil Hawksworth : En ce qui concerne l'accès aux données, eh bien, cela se passe éventuellement via des API externes, en effectuant des appels via JavaScript à ces API externes pour obtenir l'accès au serveur, ou nous pouvons considérer les API comme les API du navigateur, pouvant interagir avec JavaScript avec des fonctionnalités directement dans votre navigateur.

Phil Hawksworth : Quoi qu'il en soit, la clé ici à propos de JAMstack est que nous parlons de choses qui sont pré-rendues : elles sont servies de manière statique, puis elles peuvent être progressivement améliorées dans le navigateur pour utiliser les API du navigateur, JavaScripts , et qu'avez-vous.

Phil Hawksworth : Alors, faisons cette petite comparaison côte à côte ici. Encore une fois, je veux juste répéter que le JAMstack a grimpé d'un niveau vers le navigateur. Et si nous voyons les deux côtés de ce diagramme, avec la pile LAMP à gauche et effectivement, la pile JAM à droite, vous pourriez même penser que, eh bien, même lorsque nous construisions des choses avec la pile LAMP, nous sommes toujours balisage de sortie. Nous produisons toujours du JavaScript. Nous pourrions encore accéder aux API. Ainsi, à bien des égards, la JAMstack est presque comme un sous-ensemble de ce que nous construisions auparavant.

Phil Hawksworth : J'avais l'habitude de parler de JAMstack comme de la pile assurée, car elle assure un ensemble d'outils et de technologies dont nous avons besoin pour fournir un site. Mais, dans tous les cas, il s'agit d'une manière très simplifiée de fournir un site qui, en quelque sorte, élimine le besoin d'exécution et de logique sur le serveur au moment de la demande.

Phil Hawksworth : Donc, cela peut faire beaucoup de choses. Cela peut, en quelque sorte, simplifier les déploiements et encore une fois, je vais rappeler ce diagramme de temps en temps. Si nous réfléchissons à la façon dont nous déployons notre code et notre site, pour chaque déploiement, depuis le tout premier, tout au long du cycle de vie du développement, tout au long de la vie du site Web. Sur la pile traditionnelle, nous devrons peut-être modifier la logique et le contenu de chaque case de ce diagramme.

Phil Hawksworth : Alors que, dans le JAMstack, lorsque nous parlons de déploiement, nous parlons d'acheminer des choses vers le CDN, d'acheminer des choses vers le serveur statique, et c'est ce que le déploiement implique. La construction, le type de logique qui exécute la construction — qui peut s'exécuter n'importe où. Cela n'a pas besoin de s'exécuter dans le même environnement qui héberge le serveur Web. En fait, ce n'est pas le cas ! Il démarre la clé du JAMstack. Nous plaçons la séparation entre ce qui se passe au moment de la demande, en servant ces actifs statiques, et ce qui se passe au moment de la construction, qui peut être votre logique que vous exécutez pour la construction, puis pour le déploiement.

Phil Hawksworth : Donc, ce type de découplage est un élément clé, et j'y reviendrai plus tard. Nous sommes très bons pour servir des fichiers statiques, et faire parvenir des choses à un CDN ou faire parvenir des choses au système de fichiers (le serveur de fichiers) est un endroit où nous avons vu d'énormes progrès au cours des dernières années. Il existe maintenant de nombreux outils et processus qui peuvent nous aider à le faire très bien. Juste pour appeler quelques services qui peuvent bien servir les actifs statiques et donner des flux de travail pour obtenir votre build dans cet environnement, ce sont les suspects habituels que vous pourriez imaginer les grands fournisseurs d'infrastructure cloud, comme Azure, AWS et Google Cloud.

Phil Hawksworth : Mais alors, il y en a d'autres. Ainsi, celui du haut à droite est un service appelé Surge, qui existe depuis quelques années. Il vous permet d'exécuter une commande dans votre environnement de construction et de déployer vos actifs via leur environnement d'hébergement. Netlify, le suivant, est l'endroit où je travaille et nous faisons à peu près la même chose, mais nous avons également une automatisation différente. Je pourrais y revenir une autre fois. Et celui du bas, un autre site d'environnement d'hébergement statique, appelé Now.

Phil Hawksworth : Donc, il y a un tas d'options différentes pour faire cela, et tous ces espaces fournissent des outils différents pour accéder au CDN, aussi rapidement que possible. Déployez vos sites de la manière la plus transparente possible. Et ils ont tous quelque chose en commun où ils s'appuient sur le principe de gérer quelque chose localement. Je pense souvent à un générateur de site statique comme quelque chose que nous pourrions exécuter dans une version qui, lorsque nous l'exécutons, prend des choses comme du contenu et des modèles et peut-être des données de différents services et produit quelque chose qui peut être servi de manière statique.

Phil Hawksworth : Nous pouvons prévisualiser cela localement sur notre serveur statique. Quelque chose qui est assez simple à faire sur n'importe quel environnement de développement local, puis le processus de déploiement qui consiste à le faire parvenir à l'environnement d'hébergement et, idéalement, à un CDN afin d'obtenir, en quelque sorte, une échelle. Donc, avec ce genre de fondation, je veux aborder un peu une idée fausse commune en ce qui concerne les sites JAMstack. Et je ne me suis pas rendu service en ouvrant cela en décrivant les sites JAMstack comme étant du JavaScript, des API et du balisage. Parce que l'idée fausse commune est que chaque site JAMstack doit être JavaScript et des API, et du balisage, mais ce genre de chose que nous avons négligé est que nous n'avons pas besoin d'utiliser les trois - chacun d'entre eux est, en quelque sorte, , optionnel. Nous pouvons en utiliser autant ou aussi peu que nous le souhaitons. De la même manière qu'un site de pile LAMP n'aurait pas nécessairement besoin de toucher une base de données. Maintenant, j'ai construit des choses dans le passé qui sont servies par un serveur apache, sur une machine Linux, et j'ai utilisé PHP, mais je n'ai pas touché une base de données et je ne commencerais pas à renommer une pile forcément pour ça.

Phil Hawksworth : Donc, si nous pensons à ce qu'est un site JAMstack, cela pourrait être un tas de choses différentes. Il peut s'agir de quelque chose qui est construit avec un générateur de site statique, comme Jekyll, extrayant du contenu de fichiers YAML pour créer un site qui n'a pas de JavaScript, n'atteint pas du tout les API, et nous le servons sur quelque chose, comme GitHub Pages. Ou, ce serait un site JAMstack. Ou peut-être que nous utilisons un générateur de site statique, comme Gatsby, qui est plutôt dans un environnement Ruby pour Jekyll, maintenant c'est un générateur de site statique JavaScript construit dans l'écosystème React.

Phil Hawksworth : Il s'agit peut-être d'extraire à nouveau du contenu et d'organiser des fichiers Markdown. Cela pourrait être enrichissant avec des appels aux API, les API de GraphQL. Il peut s'agir de faire des choses dans le navigateur, comme faire l'hydratation JavaScript des modèles de remplissage directement dans le navigateur. Et il pourrait être servi sur Amazon S3. Est-ce un site JAMStack ? Ouais, absolument !

Phil Hawksworth : Passons à un autre générateur de site statique, Hugo, qui est construit avec Go ! Encore une fois, nous pourrions organiser le contenu dans des fichiers Markdown, en ajoutant des interactions dans le navigateur à l'aide de JavaScript. Peut-être ne pas appeler d'API externes et peut-être l'héberger sur Google Cloud. Est-ce JAMstack ? Absolument! Vous voyez, je suis en train de construire un thème ici. Utiliser quelque chose comme Nuxt, un autre générateur de site statique, désormais intégré à l'écosystème View. Peut-être que cela extrait du contenu de différents fichiers adjacents ? Encore une fois, nous pourrions utiliser des interactions JavaScript dans le navigateur, en appelant peut-être des API pour faire des choses comme le commerce électronique, en lui servant un autre site statique. Une autre infrastructure d'hébergement comme Netlify, est-ce un JAMstack ? Oui c'est le cas!

Phil Hawksworth: Mais nous pourrions même aller, vous savez, aller aussi de ce côté-ci de l'échelle. Et pensez à une application Web progressive faite à la main que nous avons construite artisanalement, roulée à la main, JavaScript que nous avons nous-mêmes construite. Nous l'emballons avec webpack. Nous utilisons peut-être des jetons Web JavaScript et appelons des API pour effectuer l'authentification, interagissant avec différentes API de navigateur, l'hébergant sur Azure. Oui, c'est aussi JAMstack !

Phil Hawksworth : Et, vous savez, toutes ces choses, et bien d'autres, peuvent être considérées comme JAMstack, car elles partagent toutes un attribut en commun et c'est qu'aucune d'entre elles n'est servie avec un serveur d'origine. Aucun d'entre eux n'a besoin d'atteindre un serveur qui exécute la logique au moment de la demande. Ceux-ci sont servis en tant qu'actifs statiques, puis enrichis de JavaScript et d'appels aux API, par la suite.

Phil Hawksworth : Donc, encore une fois, je veux juste répéter qu'un JAMstack signifie qu'il est capable d'être servi directement depuis le CDN. Donc, je veux simplement évoquer certains des impacts et des implications de cela, car pourquoi voudrions-nous faire cela ? Eh bien, la première notion concerne la sécurité, et nous avons ici une surface d'attaque considérablement réduite. Si nous pensons (en revenant encore à ce vieux diagramme), aux endroits où nous pourrions avoir à faire face à une attaque, nous devons sécuriser des choses comme l'équilibreur de charge, les serveurs Web, les serveurs de base de données. Toutes ces choses, nous devons nous assurer qu'elles ne peuvent être pénétrées par aucune sorte d'attaque et, en effet, le CDN.

Phil Hawksworth : Si plus nous pouvons retirer de pièces de ce puzzle, moins il y a d'endroits qui peuvent être attaqués et moins nous devons sécuriser. Avoir peu de pièces mobiles à attaquer est vraiment très précieux. Chez Netlify, nous exploitons nos propres CDN, nous avons donc le luxe de pouvoir surveiller le trafic qui le traverse, et même si tous les sites hébergés sur Netlify, tous les sites JAMstack que vous pourriez imaginer, aucun d'entre eux avoir une page d'administration WordPress dessus car elle est complètement découplée. Il n'y a pas d'administrateur WordPress, mais nous constatons un énorme volume de trafic, sondant des choses comme WP Admin, cherchant des moyens d'entrer, recherchant des vecteurs d'attaque.

Phil Hawksworth : J'aime vraiment certaines des choses que Kent C. Dodds a faites. Je ne sais pas si vous connaissez la communauté React, vous avez probablement rencontré Kent C. Dodds dans le passé. Il n'utilise pas WordPress, mais il route toujours cette URL, le WPAdmin. Je pense qu'il avait l'habitude de l'acheminer vers une vidéo de Rick Roll sur YouTube. Il a certainement traîné des gens qui sont allés le chercher. Mais, le fait est qu'en découplant les choses de cette manière et, en quelque sorte, en déplaçant les choses qui se produisent, en construisant du temps à partir de ce qui se passe au moment de la demande, nous pouvons simplement réduire considérablement notre exposition. Nous n'avons aucune pièce mobile au moment de la demande. Les pièces mobiles sont toutes complètement découplées au moment de la construction. Potentiellement, sur complètement, enfin, forcément sur des infrastructures complètement différentes.

Phil Hawksworth : Bien sûr, cela a également un impact sur les performances. Pour en revenir à notre vieil ami ici, les endroits où nous pourrions vouloir essayer d'améliorer les performances à travers la pile ici, quand il y a une logique qui doit être exécutée à ces différents endroits. La façon dont cela se produit souvent dans les piles traditionnelles est qu'elles commencent à ajouter des couches, à ajouter des couches statiques, afin d'améliorer les performances. Donc, en d'autres termes, essayez de trouver des façons de commencer à nous comporter comme si c'était statique. Ne pas avoir à exécuter cette logique à chaque niveau de la pile afin d'accélérer les choses. Donc, nous commençons à introduire des choses comme la mise en cache dans toute l'infrastructure et des endroits évidents que nous pourrions trouver à faire sur le serveur Web, plutôt que d'exécuter cette logique, nous voulons servir quelque chose immédiatement sans exécuter cette logique.

Phil Hawksworth: Donc, c'est un peu comme un pas vers, en quelque sorte, être pseudo-statique. De même dans les serveurs de base de données, nous souhaitons ajouter des couches de mise en cache aux requêtes cache-com. Même dans le solde bas, l'ensemble du CDN, vous pouvez le considérer comme un cache. Mais sur la pile traditionnelle, nous devons comprendre comment gérer ce cache, car tout ne sera pas mis en cache. Donc, il y a une certaine logique à propos. Ce qui doit être rempli dynamiquement par rapport à ce qui peut être mis en cache. Et le modèle JAMstack, tout est mis en cache. Tout est mis en cache à partir du moment où le déploiement est terminé, nous pouvons donc y penser complètement différemment.

Phil Hawksworth : Ceci, alors, commence à, en quelque sorte, faire allusion à la mise à l'échelle, aussi. Et par échelle, je parle, comment gérons-nous de gros volumes de trafic ? Les piles traditionnelles commenceront à ajouter de l'infrastructure afin d'évoluer. Donc, oui, à la mise en cache. On commence à se mettre en place dans notre stack traditionnel. Cela aidera – dans une certaine mesure. Ce qui se passe généralement, c'est que pour gérer de grandes charges de trafic, nous commencerons à étendre l'infrastructure et à ajouter plus de serveurs, plus de pièces pour gérer ces demandes, en chiffrant ces choses et en estimant la charge est une grosse surcharge et cela peut être un casse-tête pour quiconque fait de l'architecture technique. C'était certainement pour moi, c'est pourquoi je commençais à pencher beaucoup plus vers l'approche JAMstack où je sais juste que tout est servi à partir du CDN, qui est conçu par défaut pour gérer l'échelle, pour gérer les performances dès le départ .

Phil Hawksworth : Donc, je veux aussi faire un clin d'œil à l'expérience des développeurs et à l'impact que cela peut avoir là-bas. Maintenant, l'expérience de développeur ne devrait jamais être considérée comme quelque chose qui l'emporte sur l'expérience utilisateur, mais je pense qu'une bonne expérience de développeur peut réduire les frictions, peut permettre aux développeurs de faire un bien meilleur travail pour créer de superbes expériences utilisateur !

Phil Hawksworth : Donc, lorsque nous réfléchissons à l'endroit où vit l'expérience du développeur et où se trouvent les domaines de préoccupation d'un développeur : eh bien, dans une pile traditionnelle, nous devrons peut-être réfléchir à la manière dont nous obtenons le code pour tous ces différents parties de l'infrastructure, et comment elles fonctionnent ensemble. Dans le monde JAMstack, vraiment, ce dont nous parlons est cette boîte ici en bas. Vous savez, comment exécutons-nous la construction et eux, comment automatisons-nous un déploiement pour que quelque chose soit servi en premier lieu ? Et ce qui est bien, c'est que dans le modèle JAMstack, ce que vous faites dans cette version dépend entièrement de vous.

Phil Hawksworth : C'est un problème très bien défini, car en fin de compte, vous essayez de créer quelque chose que vous pouvez servir directement à partir d'un CDN. Vous voulez pré-rendre quelque chose, en utilisant les outils que vous aimez : qu'il s'agisse d'un générateur de site statique construit en Ruby ou Python ou JavaScript ou Go ou PHP, vous avez la liberté de faire ce choix. Et donc, cela peut créer un environnement beaucoup plus agréable dans lequel vous pouvez travailler. Et aussi, cela crée une opportunité d'avoir une réelle confiance des développeurs car un véritable attribut des sites JAMstack est qu'ils peuvent être beaucoup plus facilement servis comme déploiement immuable et atomique.

Phil Hawksworth : Et je veux, en quelque sorte, m'éloigner des diapositives juste un instant, pour décrire ce que cela signifie, car un déploiement immuable et un déploiement atomique peuvent... (cela peut ressembler un peu à du marketing) mais ce que je vais faire, c'est que je vais sauter dans mon navigateur. Maintenant… en fait, je vais revenir en arrière une seconde. Laisse-moi… juste faire ça.

Phil Hawksworth : Nous y sommes. Ce sera plus facile. Sauter directement dans la page. Maintenant, Scott, tu vas me dire, Scott, si tu ne peux pas voir mon navigateur, j'espère. Maintenant, en supposant que tout le monde puisse voir mon navigateur.

Scott : Tout a l'air bien.

Phil Hawksworth : Excellent ! Merci beaucoup!

Phil Hawksworth : Donc, ce que je fais ici, c'est que j'utilise Netlify comme exemple, comme exemple du service. Mais, c'est un attribut qui est commun aux sites qui peuvent être hébergés, de manière statique. Donc, quand on parle d'un déploiement immuable, ce que l'on veut dire, c'est que plutôt chaque déploiement de code devant toucher plein de parties différentes de l'infrastructure, et changer plein de choses, ici on ne fait pas muter l'état du site sur le serveur. Nous créons une toute nouvelle instance du site pour chaque déploiement qui s'est produit. Et nous pouvons le faire parce que le site est une collection d'actifs statiques.

Phil Hawksworth : Ici, je regarde le déploiement qui s'est produit à partir de mon propre site Web. Je vais te donner une friandise. Voilà, c'est à ça que ça ressemble. C'est juste un blog, il ne ressemble à rien de particulièrement remarquable ou passionnant. C'est un blog généré statiquement, mais ce que j'ai ici, c'est que chaque déploiement qui s'est produit, vit à perpétuité, car il s'agit d'une collection d'actifs statiques qui sont servis à partir d'un CDN. Maintenant, je pourrais remonter aussi loin que mon histoire peut me porter et aller voir le site, tel qu'il était à l'époque… c'était quand ? C'était en août 2016. Et du fait qu'il s'agit d'un ensemble d'actifs statiques, nous sommes en mesure de l'héberger sur sa propre URL qui vit à perpétuité et si je le voulais même, je pourrais décider d'entrer et de publier ça déploiement.

Phil Hawksworth : Donc, maintenant, quiconque regarde mon site Web, si je reviens sur mon site Web ici, si j'actualise cette page, maintenant cela est servi directement à partir du CDN avec les actifs qui s'y trouvaient auparavant. Maintenant, je peux naviguer à nouveau. Içi vous pouvez voir. Écoutez, je tapais dessus, j'utilisais ces termes terribles comme le rendu isomorphe et je parlais de la JAMstack en 2016. Donc, c'est maintenant ce qui est diffusé en direct sur mon site. Encore une fois, parce qu'il y a des déploiements mutuels qui perdurent pour toujours. Je vais juste mettre ma propre tranquillité d'esprit, je vais — est-ce la première page ? Ouais. Je vais revenir à mon dernier déploiement. Je vais devoir me refermer et me ramener dans le monde réel. Laissez-moi m'assurer que tout va bien.

Phil Hawksworth : D'accord ! Génial! Donc, maintenant, c'est de retour pour servir ma version précédente, ou ma dernière version du site. Je reviens au discours d'ouverture. Donc, c'est possible parce que les choses sont immuables et atomiques. La partie atomique de cela signifie, encore une fois, que le déploiement est complètement contenu. Ainsi, vous n'obtenez jamais le point où certains des actifs sont disponibles sur le serveur Web, mais certains d'entre eux ne le seront pas. Ce n'est que lorsque tout est là dans son contexte et que tout est là, complet, que nous basculons le service du site vers la nouvelle version. Encore une fois, c'est le genre de chose que vous pouvez faire beaucoup plus facilement si vous créez des choses en tant que site JAMstack qui sert directement à partir du CDN en tant que groupe d'actifs.

Phil Hawksworth : J'ai remarqué que mon chronomètre s'est réinitialisé, après avoir fait des allers-retours depuis le discours d'ouverture, donc je pense qu'il me reste environ six ou sept minutes. Dis-moi, Scott, si...

Scott : Donc, oui, nous sommes encore bons pour une dizaine de minutes.

Phil Hawksworth : Dix minutes ? D'accord, merveilleux !

Scott : Il n'y a pas d'urgence.

Phil Hawksworth : Merci, ça devrait être bien !

Phil Hawksworth : Donc, en changeant un peu de vitesse et en parlant d'API et de services (puisque les API font partie de JAMstack), le type de services que nous pourrions alors utiliser est principalement JAMstack. Vous savez, nous utilisons peut-être des services que nous avons construits en interne, ou nous utilisons peut-être des services achetés. Il y a beaucoup de fournisseurs différents qui peuvent faire des choses pour nous, et c'est parce que c'est leur expertise. Grâce aux API, nous pouvons extraire le contenu des systèmes de gestion de contenu en tant que service, et il existe un tas de fournisseurs différents pour cela, qui se spécialisent dans la fourniture d'une excellente expérience de gestion de contenu, puis dans l'exposition du contenu via l'API, donc vous étiez capable de les attirer.

Phil Hawksworth : De même, il existe différentes manières de servir les actifs. Des gens comme Cloudary sont excellents dans ce domaine, pour optimiser les images, fournir des actifs directement sur vos sites, encore une fois, via des API. Ou qu'en est-il du commerce électronique ? Vous savez, il existe des endroits comme Stripe ou Snipcart qui peuvent nous fournir des API, de sorte que nous n'avons pas à créer ces services nous-mêmes et à nous attaquer aux problèmes très complexes liés à la création d'un moteur de commerce électronique. De même, l'identité, de personnes comme Auth0 qui utilisent Oauth. De nombreux services sont disponibles et nous pouvons les consommer via des API, soit dans le navigateur, soit au moment de la construction, ou parfois, une combinaison des deux.

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. So, how do we do that?

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. Thanks, Scott.

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. Bonjour à tous. Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. Droit? It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Phil Hawksworth : J'aime beaucoup, parce que le terme JAMstack peut être vraiment trompeur, parce qu'il essaie de couvrir tellement de choses différentes et ce que j'essayais de faire, je l'ai probablement martelé plusieurs fois dans cette diapositive, c'est qu'il peut être de toutes sortes de choses. C'est tellement large, mais la clé est de pré-rendre et d'héberger le noyau des sites de manière statique. Il est très facile pour nous de nous lancer dans des guerres de religion pour savoir où il doit être un site React. Il doit s'agir d'une application React, afin d'être un site JAMstack, ou c'est une application React, donc ce ne peut pas être JAMstack. Mais, vraiment, l'essentiel est que vous utilisiez JavaScript ou non, que vous appeliez des API ou non, si vous pré-rendez et placez les choses dans un hôte statique qui peut être très performant, c'est le cœur de JAMstack.

Vitaly : Oui, tout à fait.

Phil Hawksworth : Nous sommes très chanceux que les navigateurs soient de plus en plus performants, et les API présentes dans les navigateurs eux-mêmes peuvent également nous permettre de faire beaucoup plus. Donc, ce genre d'ouverture ouvre encore plus les portes, mais cela ne signifie pas que tout ce que nous construisons en tant que site JAMstack doit utiliser tout. En fonction de ce que nous essayons de livrer, c'est ainsi que nous devrions commencer à choisir les outils avec lesquels nous jouons pour déployer ces choses.

Vitaly : Absolument. Nous avons Doran ici. Doran, je pense que je sais, Doran. J'ai l'impression de connaître Doran. Il demande : « Vous attendez-vous à ce que le serverless gravite vers une intégration transparente avec JAMstack à partir de [inaudible 00:44:36] ? Ce qu'on appelle le A dans JAM.

Phil Hawksworth : C'est une excellente question, parce que je pense que les fonctions sans serveur sont - elles vont si bien avec les sites JAMstack, parce qu'à bien des égards, en fait, je pense que quelqu'un m'a demandé un jour si les sites JAMstack sont sans serveur, et donc je me suis tortillé sur cette question, car sans serveur est un terme tellement chargé. Mais, à bien des égards, c'est parfait parce que je parlais maintes et maintes fois de l'absence de serveur d'origine. Vous n'avez aucune infrastructure de serveur à gérer. En fait, j'ai un jour écrit un article de blog intitulé « Web sans serveur », car le monde a besoin d'un autre terme à la mode, n'est-ce pas ?

Phil Hawksworth: Et vraiment, le genre de point de cela était, oui, nous construisons des choses sans serveurs. Nous ne voulons pas avoir à gérer ces serveurs, et les fonctions sans serveur, ou les fonctions en tant que service, s'intègrent parfaitement à cela. Ainsi, dans les cas où vous avez besoin d'une API à laquelle vous souhaitez faire une demande, il n'est vraiment pas judicieux pour vous de faire cette demande directement à partir du navigateur. Ainsi, par exemple, si vous avez des secrets, ou des clés, dans cette requête, vous ne voudrez peut-être pas que ces requêtes - ces informations - soient jamais exposées dans le client. Mais nous pouvons certainement proxy ces choses, et généralement, traditionnellement, ce que nous devons faire alors, c'est faire tourner un serveur, avoir une infrastructure qui ne faisait effectivement guère plus que gérer les demandes, y ajouter une authentification de sécurité et transmettre ces demandes sur , en les renvoyant par procuration.

Phil Hawksworth : Les fonctions sans serveur sont parfaites pour cela. Ils sont absolument idéaux pour cela. Donc, je pense parfois aux fonctions sans serveur, ou aux fonctions d'un service, presque comme une trappe d'évacuation, où vous avez juste besoin d'une logique sur un serveur, mais vous ne voulez pas avoir à créer une infrastructure entière. Et vous pouvez faire de plus en plus avec cela, et préparer les pipelines de développement pour, les flux de travail de développement, pour les fonctions en tant que service qui arrivent à maturité. Il devient de plus en plus accessible aux développeurs JavaScript de pouvoir créer ces éléments. Donc, oui, je pense vraiment que ces deux choses vont très bien ensemble.

Vitaly : D'accord, c'est une réponse très complète. En fait, j'ai assisté à une conférence récemment, où un ingénieur front-end d'Amazon parlait des fonctions sans serveur et Lamda qu'ils utilisent - j'étais presque parti. Il parlait toujours de Docker et de Kubernetes, et de toutes ces choses, Devox World, j'étais assis là, pensant: «Comment a-t-il atterri là-bas. Je ne comprends pas ce qui se passe !" Je n'avais aucune idée de ce qui se passait.

Phil Hawksworth : Exactement, mais le fait est qu'avant, c'était le... j'étais... j'acceptais que je ne comprenais rien de ce monde, mais je n'en avais aucune envie, puisque c'était pour une discipline entièrement différente. . Et cette discipline est toujours très importante. Vous savez, les gens qui conçoivent l'infrastructure — c'est toujours vraiment essentiel. Mais, j'ai juste l'impression, maintenant, que je suis tenté. En tant que personne ayant une formation en développement front-end, en tant que développeur JavaScript, je suis beaucoup plus tenté de vouloir jouer dans ce monde, car les outils se rapprochent, en quelque sorte, de moi.

Phil Hawksworth: Il est beaucoup plus probable que je puisse utiliser certaines de ces choses et livrer des choses en toute sécurité, plutôt que simplement comme une expérience de ma part, où j'avais l'habitude d'être tacheté. Donc, j'ai l'impression que nous devenons plus puissants en tant que développeurs Web, ce qui me passionne.

Vitaly : Comme les Power Rangers, hein ?

Vitaly : Une chose que je veux vous demander, cependant, et c'est en fait quelque chose dont nous avons déjà discuté, peut-être, il y a une semaine, mais je voulais quand même l'évoquer, parce que la seule chose que vous avez mentionnée dans la session était la notion d'avoir une instance autonome de chaque déploiement, ce qui est vraiment cool. La question, cependant, est que si vous avez une tâche importante, avec des dizaines de milliers de pages, vous ne voulez vraiment pas tout redéployer, à chaque fois. Donc, essentiellement, si vous avez, par exemple, si vous utilisez principalement le côté statique des choses. Donc, nous avons eu cette idée pendant un moment et je sais que c'est en fait quelque chose que vous avez évoqué la dernière fois. L'idée des déploiements atomiques.

Vitaly : Où vous avez littéralement reçu une sorte de div entre deux versions différentes d'instantanés de la configuration. Donc, si vous dites, changez l'en-tête partout, alors, bien sûr, chaque page doit être redéployée. Mais si vous changez, peut-être, un composant, comme disons un carrousel, qui n'affecte peut-être que 1000 pages, alors il serait logique de redéployer 15000 pages. Mais seulement ce 1000. Alors, pouvons-nous y arriver ? Est-ce une idée magique qui existe, ou est-ce quelque chose de tout à fait tangible, à ce stade ?

Phil Hawksworth : Je pense que c'est probablement le Saint Graal pour les générateurs de sites statiques et ce type de modèle car, certainement, vous avez probablement identifié le plus grand obstacle à surmonter. Ou le plus grand plafond auquel vous vous cognez. Et ce sont des sites Web qui ont plusieurs, des dizaines de milliers ou des centaines de milliers, ou des millions d'URL - la notion que la construction peut devenir très longue. Être capable de détecter quelles URL vont changer, sur la base d'un changement de code, est un défi. Ce n'est pas insurmontable, mais c'est un gros défi. Comprendre ce qu'est le graphique de dépendance sur l'ensemble de votre site, puis le déployer intelligemment - c'est vraiment difficile à faire.

Phil Hawksworth : Parce que, comme vous l'avez mentionné, un changement de composant peut avoir des implications très importantes, mais vous — il est toujours difficile de savoir comment cela va fonctionner. Il existe donc un certain nombre de générateurs de sites statiques, les projets qui mettent du poids derrière ce défi et essaient de comprendre comment ils procèdent à la régénération partielle et aux constructions incrémentielles. Je suis très excité à l'idée que cela puisse être résolu un jour, mais pour le moment, c'est définitivement un grand défi. Vous pouvez commencer à faire des choses comme essayer de partager logiquement votre site et penser, encore une fois, à un problème similaire à celui de la migration. Eh bien, cette section que je connais est indépendante en termes de, en quelque sorte, certains des actifs qu'elle utilise, ou le type de contenu qui y vit, donc je peux les déployer individuellement.

Phil Hawksworth : Mais ce n'est pas idéal pour moi. Ce n'est pas vraiment le scénario parfait. L'une des approches que j'ai un peu explorées, juste comme preuve de concept, consiste à réfléchir à la façon dont vous faites les choses, comme utiliser intelligemment les 404. Ainsi, par exemple, un cas d'utilisation important pour les très grands panneaux, peut-être que les sites d'actualités sont, lorsqu'ils ont besoin d'une URL lorsqu'une nouvelle de dernière heure se produit, ils doivent être les premiers à la déployer là-bas. Ils ont besoin d'obtenir une URL là-haut. Des choses comme BBC News, vous verrez que l'actualité arrivera sur le site Web, puis au fil du temps, ils y ajouteront progressivement, mais y arriver en premier est la clé. Donc, avoir une construction qui prend 10 minutes, 20 minutes, quoi que ce soit, cela pourrait être un problème.

Phil Hawksworth : Mais, si leur contenu est abstrait et peut-être utilisé pour avoir été appelé à partir d'une API. J'ai mentionné les systèmes de gestion de contenu qui sont abstraits, comme Contentful ou Sanity, ou un tas de ceux-là. Tout ce qui a une API de contenu change en cette structure de contenu qui déclenchera une construction et nous passerons par l'exécution, mais l'autre chose qui pourrait arriver est que, eh bien, si vous publiez votre URL pour cela, puis publiez cette URL , même si la construction n'a pas été exécutée, si quelqu'un hacke cette URL, si le premier arrêt sur son 404 est au lieu de dire "Nous ne l'avons pas", est en fait d'atteindre directement cette API, alors, vous pouvez dire , "Eh bien, la construction n'a pas encore fini de remplir cela, mais je peux le faire dans le client." Je peux aller directement à l'API, l'obtenir, la remplir dans le client.

Vitaly : Hmm, intéressant.

Phil Hawksworth : Donc, même pendant que la construction est encore en cours, vous pouvez commencer à remplir ces éléments. Et puis, une fois la construction terminée, bien sûr, cela ne toucherait pas un 404. Vous toucheriez cette page en cours d'exécution statique. Donc, il existe des techniques et des stratégies pour y faire face, mais c'est quand même une réponse très longue et décousue, je suis désolé, mais ma conclusion est, oui, c'est un défi. Croisons les doigts, nous aurons de meilleures stratégies.

Vitaly : Ouais, c'est super. Donc, je me demande, donc, à ce stade, nous ne pensons vraiment pas, non seulement aux performances en termes de contenu fourni, mais à celles en termes de performances en termes de vitesse de construction. Comme le déploiement du bâtiment. Donc, c'est aussi quelque chose que nous examinons depuis un certain temps maintenant également.

Vitaly : Encore une chose que je voulais vous demander. Donc, c'est intéressant, comme cette technique que vous avez mentionnée. Comment apprenez-vous cela? C'est juste quelque chose que les gens ont tendance à publier sur leurs propres blogs ou, est-ce un support ou existe-t-il un référentiel central où vous pouvez obtenir une sorte de studios de cas, de la façon dont JAMstack - comment les entreprises se sont déplacées pendant le déchargement, ou n'ont pas réussi à se déplacer vers JAMstack.

Phil Hawksworth: Donc, cela fait un peu mûrir ce paysage, pour le moment. Je veux dire, certains de ces exemples, je pense, je suis dans une position très chanceuse, je travaille quelque part dans un rôle que je joue avec les jouets, en trouvant des façons intéressantes de l'utiliser et de commencer à expérimenter avec eux. Donc, ces preuves de concepts sont, en quelque sorte, des choses que je peux expérimenter et essayer de relever ces défis. Mais, j'ai en quelque sorte mentionné plus tôt, une étude de cas qui a été présentée à la conférence JAMstack à New York, et certainement, des événements comme celui-là, nous commençons à voir les meilleures pratiques ou les pratiques de l'industrie et les approches de l'industrie dont il est question à ce genre d'événements. Et certainement, je veux en voir plus et travailler sur plus d'études de cas pour accéder à des endroits comme Smashing Magazines, afin que nous puissions partager ces informations beaucoup plus facilement.

Phil Hawksworth: Je pense que les grandes entreprises et l'espace d'entreprise adoptent progressivement JAMstack, à différents endroits, de différentes manières, mais le monde est toujours en pente pour sortir, donc je pense, chaque fois qu'une entreprise l'adopte et partage son expérience, nous apprenons tous de cela. Mais je veux vraiment que de plus en plus de ces études de cas soient publiées, afin que nous puissions nous pencher particulièrement sur la façon dont ce genre de défis sont surmontés.

Vitaly : D'accord, alors, peut-être juste ma dernière question, parce que j'aime toujours lire les questions. Donc, la terre JAMstack, si vous pouviez changer quelque chose, peut-être qu'il y a quelque chose que vous aimeriez désespérément voir, au-delà des déploiements. Y a-t-il autre chose qui vous rendrait vraiment très heureux ? Cela ferait de votre journée? Qu'est-ce que ce serait? Qu'y a-t-il sur votre liste de souhaits, pour JAMstack ?

Phil Hawksworth : Quelle question. Je veux dire, si nous n'avions pas parlé de builds incrémentiels, ce serait...

Vitaly : Nous l'avons fait. C'est trop tard, maintenant. Cette carte a déjà été passée. Nous avons besoin d'autre chose.

Phil Hawksworth : Alors...

Vitaly : Ce que je veux dire, comme sur une plate-forme, si vous regardez la plate-forme arrière, il se passe tellement de choses passionnantes. Nous avons Houdini, nous avons des composants Web à venir, et tout, car vous pourriez changer tout le paysage de tous les bons composants. De l'autre côté, nous avons tout ce monde magique et fantaisiste avec SS NGS, et, bien sûr, évidemment, nous avons aussi des applications d'une seule page et tout. Qu'est-ce qui vous passionne le plus ?

Phil Hawksworth : Je vais être obtus ici, car il se passe tellement de choses, c'est excitant, et il y a tellement de nouvelles fonctionnalités que vous pouvez utiliser dans le navigateur. Ce qui m'excite vraiment, ce sont les gens qui font preuve de retenue (rires) et, comme je l'ai dit, une réponse ennuyeuse, mais j'aime voir de grandes exécutions faites avec retenue, de manière réfléchie - à propos d'un public plus large. C'est vraiment très amusant et gratifiant de construire avec la nouvelle bibliothèque JavaScript la plus brillante ou la nouvelle API de navigateur qui fait, je ne sais pas, des capacités de scratch et de sniff dans le navigateur, dont nous avons désespérément besoin, n'importe quand maintenant.

Phil Hawksworth: Mais j'aime vraiment voir des choses dont je sais qu'elles fonctionneront dans de très nombreux endroits. Ils vont être vraiment performants, vont être sympathiques aux navigateurs qui existent - pas seulement sur les bureaux des PDG et des CTO qui ont les jouets snazzy, mais aussi des gens qui ont des appareils beaucoup moins puissants, ou ils ' Nous avons des conditions de réseau difficiles et ce genre de choses. J'aime voir des expériences intéressantes et des expériences riches, livrées d'une manière sympathique à la plate-forme et en quelque sorte compatissante pour le public plus large, car je pense que le Web va beaucoup plus loin que nous, les développeurs, qui construisons des choses pour lui . Et je suis excité en voyant des choses intéressantes réalisées, d'une manière qui touche plus de gens.

Phil Hawksworth : Ce n'est probablement pas la réponse à laquelle vous étiez nécessairement...

Vitaly : Oh, c'est une belle fin. Merci beaucoup. Non, c'est parfait, vraiment. Très bien, j'ai senti que tout s'était bien passé ! Merci beaucoup d'être avec nous! Je distribue à Scott !

Phil Hawksworth : Génial !

Vitaly : Je suis juste là pour jouer aux questions et réponses. Alors, merci beaucoup, Phil ! Je suis toujours là, mais Scott, la scène est à toi, maintenant ! Peut-être pouvez-vous partager avec nous ce qui s'en vient sur Smashing TV ?

Scott : Je le ferai, mais d'abord, Phil, j'ai hâte de voir comment fonctionne l'implémentation de l'API scratch-and-sniff. Cela semble très intéressant. Et, Vitaly, JAMstackify est déjà pris.

Vitaly : (abattu) Pris ? ! Pouvons-nous l'acheter?

Scott : Non, ça existe !

Vitaly : Eh bien, c'est trop tard. Je suis toujours en retard.

Phil Hawksworth : C'est excitant à sa manière.

Vitaly : C'est l'histoire de ma vie. Je suis toujours en retard.

Scott : Les membres viennent ensuite, je crois, le jeudi 13, nous avons mon vieux père, Zach Leatherman, qui parle de ce dont il parle le mieux, à savoir les polices de caractères. Donc, il parle des cinq Y des implémentations de polices. Et puis, je suis aussi très intéressé par celui qui arrive le 19, qui est le montage vidéo, avec JavaScript et CSS, avec Eva Faria. Alors, restez à l'écoute pour les deux.

Scott : Donc, c'est encore jeudi prochain, avec Zach Leatherman, puis le 19, avec Eva, qui parlera du montage vidéo en JavaScript et CSS. Donc, sur cette note, Phil, je ne peux plus te voir, es-tu toujours là ?

Phil Hawksworth : Je suis là !

Scott : Sur cette note, merci beaucoup à tous ! De plus, y a-t-il quelqu'un dans la, en quelque sorte, près de la région de Toronto? Ou quelqu'un qui a déjà voulu visiter Toronto ? Nous avons une conférence à venir fin juin, et il reste encore quelques billets. Alors peut-être qu'on y verra certains d'entre vous.

Vitaly : Merci beaucoup, tous les autres !

Vitaly : Oh, au fait, encore une chose ! Phil l'a peut-être mentionné, mais nous avons également la conférence JAMstack à Londres, en juillet. Donc, c'est aussi quelque chose à surveiller. Mais je me déconnecte et je vais chercher ma salade ! Je ne sais pas ce que vous—

Scott : OK, au revoir, tout le monde !

Vitaly : D'accord, au revoir, tout le monde.

C'est un Wrap !

Nous remercions chaleureusement les membres Smashing du fond du cœur pour leur soutien continu et aimable - et nous avons hâte d'héberger d'autres webinaires à l'avenir.

De plus, Phil sera MC à SmashingConf Toronto 2019 la semaine prochaine et à JAMstack_conf - nous serions ravis de vous y voir également !

Veuillez nous faire savoir si vous trouvez cette série d'entretiens utile, et qui vous aimeriez que nous interviewions, ou quels sujets vous aimeriez que nous couvrons et nous y reviendrons.