Quoi, quoi et comment

Nous adorons repousser les limites sur le 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 que signifie-t-elle pour votre flux de travail et quand cela a-t-il un sens dans vos projets?

De notre Smashing Membership nous organisons Smashing TV une série de webinaires en direct, toutes les semaines. Pas de fluff – juste des webinaires pratiques et exploitables avec un Q & A en direct, animé par des praticiens respectés du secteur. En effet, le programme télévisé de Smashing semble déjà assez dense et il est gratuit pour les membres Smashing, ainsi que les enregistrements – évidemment .

Nous avons gentiment demandé à Phil Hawksworth pour organiser un webinaire expliquant ce que JAMStack signifie réellement et quand cela fait sens, ainsi que son incidence sur l'outillage et l'architecture frontale. Le webinaire d'une heure est également disponible. Nous ne pouvions pas être plus heureux d’accueillir Phil et notre coprésident lors de notre SmashingConf Toronto (25-26 juin) à venir et de JAMStack_conf London que nous co-organisons les 9 et 10 juillet cette année aussi. Alors, allons-y!

Phil Hawksworth: Excellent, d’accord, alors allons-y. Juste pour faire un petit coucou, je veux dire, j’ai déjà dit bonjour, Scott m’a fait une bonne introduction. Mais oui, je travaille actuellement chez Netlify, je travaille dans l’équipe d’expérience développeur. Nous espérons avoir beaucoup de temps pour les questions-réponses, mais comme l'a mentionné Scott, si vous n'avez pas l'occasion de poser des questions ici, ou si vous préférez, vous pouvez les envoyer directement à moi par Twitter, alors mon compte Twitter C’est mon nom, c’est Phil Hawksworth, alors vous pouvez certainement me poser des questions sur JAMstack ou même sur Twitter.

Phil Hawksworth: Mais je voudrais commencer aujourd’hui simplement en revenant en arrière. temps un peu à cette citation qui résonne vraiment très, très fort avec moi. Ceci est une citation du merveilleux Aaron Schwartz qui, bien sûr, a beaucoup contribué à la création de Creative Commons et du Web ouvert. Il l’a écrit sur son blog en 2002, et il a déclaré: «Je me soucie de ne pas avoir à garder des Les serveurs AOL, Postgres et Oracle sont installés. ”Serveur AOL, je devais me lever pour me rappeler que c'était un serveur Web à code source ouvert à l'époque.

Phil Hawksworth: Mais cela sonne vraiment très fort avec moi. Je ne veux pas non plus entretenir l’infrastructure pour maintenir un blog en vie, et c’est ce dont il parlait. Et c’était dans son billet sur son propre blog, intitulé «Bake, Don't Fry». Il cherchait un terme que quelqu'un qui avait construit un système de gestion de contenu avait récemment commencé à utiliser et il a en quelque sorte popularisé ce terme sur la cuisson (Bake, Don’t Fry); Ce dont il parle, c'est le pré-rendu plutôt que le rendu à la demande. Cuisez donc le contenu à l'avance, plutôt que de le cuire à la demande lorsque les gens le demandent, évitant ainsi de perdre du temps à la demande.

Phil Hawksworth: Lorsque nous parlons de pré-rendu et de rendu, nous entendons par là que nous parlons de générer un 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 ce genre de termes à la mode. J'ai été appelé il y a quelques années lors d'une conférence intitulée Frontiers Conference à Amsterdam, alors que je parlais du rendu sur le serveur. Quelqu'un m'a dit: «Vous voulez dire générer du HTML? C'est juste quelque chose qui génère du HTML? ”Et bien sûr, ce que je veux dire.

Phil Hawksworth: Mais tout cela contribue grandement à simplifier la pile. Quand nous pensons à la pile à partir de laquelle nous servons des sites Web; J'essaie de simplifier les choses, je suis très désireux 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 un peu cela. Le «JAM» dans JAMstack est synonyme de JavaScript, d'API et de 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 environ, Je voudrais développer un peu cette définition et donner une description plus détaillée de ce que JAMstack est. 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 comme raison pour laquelle nous pourrions le choisir. En cours de route, je vais essayer de mentionner quelques-uns des outils et services qui seront utiles et, espérons-le, je vais conclure avec quelques ressources que vous voudrez peut-être approfondir et peut-être mentionner quelques premières étapes pour vous aider. en cours.

Phil Hawksworth: C'est donc 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 gens qui rejoignent cette vidéo ou qui sont venus regarder cette vidéo plus tard, vous avez peut-être une idée de ce que JAMstack est, ou Peut-être que c'est un terme complètement nouveau et que vous êtes simplement curieux. Mais, au final, il y a déjà beaucoup de piles. Vous pouvez créer un site Web de nombreuses façons. Nous avons l’impression de construire depuis très longtemps différents types d’infrastructures, qu’il s’agisse d’une pile LAMP ou de la pile MAMP, ou de la pile – je ne sais pas – la pile MEAN. Un certain nombre d’entre eux flottent à l’écran ici. Il y en a des tas.

Phil Hawksworth: Alors, pourquoi aurions-nous besoin d'un autre? Comme je l'ai mentionné, JAMstack est JavaScript / API / Balisage, mais si nous essayons d'être un peu plus descriptif, JAMstack se veut une architecture moderne, permettant de créer des sites rapides et sécurisés et des applications dynamiques avec JavaScript / Les API et les balises prédéfinies, servies sans serveurs Web, constituent ce dernier élément qui le distingue et qui le rend peut-être un peu plus intéressant, plutôt 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 trouverons quoi au cours du processus. Mais pour essayer de faire la lumière sur ce sujet et de le décrire un peu plus en détail, il est parfois utile de le comparer à ce que nous pourrions penser de pile traditionnelle, ou de manière traditionnelle de servir des choses sur le Web. Alors, faisons cela juste une seconde. Voyons peut-être à quoi pourrait ressembler une requête car elle est traitée dans une pile traditionnelle.

Phil Hawksworth: Dans ce scénario, nous avons donc demandé à quelqu'un d'ouvrir un navigateur Web et de créer une demande de voir une page. Et peut-être que cette demande frappe un CDN, mais probablement plus probablement, elle touche une autre infrastructure que nous hébergeons – en tant que propriétaires du site. Peut-être avons-nous essayé de nous assurer que cela va évoluer sous beaucoup de charge parce que nous voulons évidemment un spectacle très populaire et réussi. Nous avons donc peut-être un équilibreur de charge doté d'une logique, qui servira cette demande à l'un des serveurs Web sur lesquels nous avons mis en service, configuré et déployé des ressources. Il peut y avoir un certain nombre de ces serveurs.

Phil Hawksworth: Et ces serveurs exécuteront une logique pour dire: «Bon, voici notre modèle, nous devons le renseigner avec des données." récupérez nos données auprès d'un des nombreux serveurs de base de données qui effectuent une certaine logique pour rechercher certaines données, les renvoient au serveur Web, créent une vue que nous transmettons ensuite à l'équilibreur de charge. Peut-être, en cours de route, appelez-vous CDN et stockez-vous certaines ressources dans le CDN, et je devrais préciser, un CDN est un réseau de distribution de contenu (Content Delivery Network), donc un réseau de machines distribuées sur Internet pour essayer d'obtenir un service de demande aussi proche que possible à l'utilisateur et ajouter des éléments, tels que la mise en cache.

Phil Hawksworth: Nous pourrions donc y placer des éléments d'actif et, à terme, renvoyer une vue dans le navigateur, à la vue de l'utilisateur, qui obtiendra faire ensuite l'expérience du site que nous avons construit. Donc, évidemment, il s’agit d’une simplification excessive ou d’une vision très générale de la manière dont nous pourrions traiter une demande dans une pile traditionnelle. Si nous comparons cela au JAMstack, qui offre des services légèrement différents, voici à quoi cela pourrait ressembler.

Phil Hawksworth: Alors, encore une fois, nous partons du même scénario. navigateur web. Nous demandons une vue 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 voir les différences ici en termes de complexité. En termes d’endroits où nous devons gérer du code, profondément du code, toutes ces choses différentes. Ainsi, pour moi, l’un des principaux attributs d’un JAMstack est que cela signifie que vous construisez un site capable de servir directement à partir d’un CDN, voire d’un serveur de fichiers statique. CDN est quelque chose que nous pourrions vouloir mettre en place pour gérer la charge, mais qui pourrait finalement être servi directement à partir de n'importe quel type de serveur de fichiers statique, sorte d’infrastructure d’hébergement statique.

Phil Hawksworth: JAMstack , en quelque sorte, offre l’occasion de réduire la complexité. En comparant ces deux parties du diagramme sur lesquelles nous reviendrons à quelques reprises, au cours de la prochaine demi-heure, vous constaterez qu’il s’agit d’une opportunité de réduire la complexité et les risques. Cela signifie donc que nous pouvons commencer à profiter des avantages de la gestion des actifs statiques, et je vais vous en parler un peu plus tard. Mais vous pouvez peut-être regarder cela et penser: «Bien, bien, mais n'est-ce pas simplement le nouveau nom des sites Web statiques?». C'est une chose raisonnable à me reprocher quand je dis: «Nous allons servir les choses statiquement. ”

Phil Hawksworth: Mais je veux revenir à cela. Je veux en parler un peu plus, mais tout d’abord, je veux, en quelque sorte, parler de cette notion de piles et de ce qu’est une pile, de toute façon? Et je pense à une pile en tant que couches de technologie qui fournissent votre site Web ou votre application. Et nous ne parlons pas du pipeline de construction, ni du processus de développement, mais la façon dont nous desservons les sites peut 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 fournissent réellement votre site Web et votre application aux utilisateurs. Faisons donc une autre petite comparaison. Parlons de la pile LAMP pendant une seconde.

Phil Hawksworth: La pile LAMP, vous vous en souvenez peut-être, est constituée d’un serveur Web Apache permettant d’effectuer des tâches telles que le routage HCP et la distribution de actifs statiques. PHP, pour certains pré-traitements, donc joli traitement hyper-textuel; appliquer la logique, peut-être créer les vues pour les modèles et ainsi de suite. Et a quelques accès à vos données, par ma NISQL, et alors LINUX est le système d’exploitation qui se cache derrière tout cela, qui maintient tout cela en respiration. Nous pouvons regrouper cela théoriquement en tant que serveur Web. Et nous pouvons avoir beaucoup de ces serveurs, en quelque sorte, assis ensemble pour servir un site Web.

Phil Hawksworth: C'est un genre de regard traditionnel sur la pile LAMP, et si nous comparons cela à le JAMstack, eh bien, ici, il y a un changement critique. Ici, nous progressons plutôt que de penser au système d’exploitation et à la façon dont nous gérons la logique de création d’un site Web. Nous supposons ici que nous allons servir ces choses de manière statique. Nous effectuons donc le routage ACP et la distribution d’actifs à partir d’un serveur statique. Cela peut être raisonnablement fait. Au fil des ans, nous avons très bien réussi à créer des moyens de créer des sites Web statiques ou des actifs statiques.

Phil Hawksworth: Il pourrait s'agir d'un CDN, et nous en reparlerons dans les suivants: un instant. Mais le domaine d’intérêt pour nous, se passe plus dans le navigateur. Donc, ici, c'est ici que notre balisage est livré et analysé. C'est ici 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 de disposer du moteur d'exécution dans l'infrastructure du serveur, nous avons maintenant déplacé ce niveau plus haut, plus près de l'utilisateur, dans le navigateur.

Phil Hawksworth: Lorsqu'il s'agit d'accéder à des données Eh bien, cela se produit éventuellement via des API externes, en passant des appels via JavaScripts à ces API externes pour obtenir un accès au serveur, ou nous pouvons considérer les API comme des API de navigateur, étant en mesure d’interagir avec JavaScript avec des fonctionnalités présentes directement dans votre navigateur. 19659005] Phil Hawksworth: Quoi qu'il en soit, la clé ici du JAMstack est que nous parlons d'éléments prédéfinis: ils sont servis de manière statique et ensuite, ils peuvent être progressivement améliorés dans le navigateur. pour utiliser les API de navigateur, les JavaScripts, etc.

Phil Hawksworth: Alors, faisons simplement cette petite comparaison côte à côte ici. Encore une fois, je tiens simplement à rappeler que le JAMstack est passé au niveau supérieur du navigateur. Et si nous voyons les deux côtés de ce diagramme, avec la pile LAMP à gauche et effectivement, le JAMstack à droite, vous pourriez même penser que, même si nous construisions des choses avec la pile LAMP, nous sommes toujours sortie de balisage. Nous produisons encore du JavaScript. Nous sommes peut-être toujours en train d'accéder aux API. Donc, à bien des égards, le JAMstack est presque comme un sous-ensemble de ce que nous construisions auparavant.

Phil Hawksworth: J'avais l'habitude de parler de JAMstack en tant que pile assurée, car elle assure un ensemble de outils et technologies dont nous avons besoin pour créer un site. Mais, dans les deux cas, c’est une manière très simplifiée de créer un site qui élimine en quelque sorte la nécessité d’exécuter et d’exécuter une 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 revenir à ce diagramme de temps en temps. Si nous réfléchissons à la façon dont nous déployons notre code et notre site, nous procédons pour chaque déploiement, du tout premier au cycle de développement complet, tout au long de la vie du site. Sur la pile traditionnelle, nous devrons peut-être modifier la logique et le contenu de chaque encadré de ce diagramme.

Phil Hawksworth: Alors que, dans le JAMstack, lorsque nous parlons de déploiement, nous vous parlez d’obtenir des informations sur le CDN, d’obtenir des informations sur le serveur statique, et c’est ce que le déploiement implique. La construction, le type de logique qui l'exécute – peut s'exécuter n'importe où. Il n’est pas nécessaire de s’exécuter dans le même environnement que celui qui héberge le serveur Web. En fait, ce n’est pas le cas! Il commence la clé du JAMstack. Nous plaçons la séparation à ce qui se passe au moment de la demande, en servant ces actifs statiques, par rapport à ce qui se passe au moment de la construction, ce qui peut être votre logique que vous exécutez pour construire puis pour le déploiement.

Phil Hawksworth: Ce type de découplage est donc un élément clé et je reviendrai sur ce point plus tard. Nous sommes très doués pour la gestion de fichiers statiques, et transférer des fichiers sur un CDN ou des systèmes de fichiers (le serveur de fichiers) est un domaine dans lequel nous avons assisté à un énorme progrès, au cours des dernières années. Il existe à l'heure actuelle de nombreux outils et processus qui peuvent nous aider à bien faire cela. Juste pour appeler quelques services qui peuvent bien gérer les actifs statiques et donner des workflows pour intégrer votre build à cet environnement, ce sont les suspects habituels de l’imagination des grands fournisseurs d’infrastructure cloud, tels que Azure, AWS et Google Cloud. 19659005] Phil Hawksworth: Mais alors, il y en a d'autres. Ainsi, en 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 dans leur environnement d'hébergement. Netlify, le prochain en bas, est mon lieu de travail et nous faisons pratiquement la même chose, mais nous avons également une automatisation différente. Je pourrais entrer dans une autre fois. Et celui du bas, un autre site d’environnement d’hébergement statique, appelé Now.

Phil Hawksworth: Il existe donc de nombreuses options pour cela, et tous ces espaces fournissent des outils différents pour obtenir au CDN, le plus rapidement possible. Faites en sorte que vos sites soient déployés de la manière la plus transparente possible. Et ils ont tous quelque chose en commun: ils s’appuient sur le principe d’exécution locale. 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 éléments tels que le contenu et les modèles, et peut-être des données de différents services, et génère un élément pouvant être servi de manière statique.

Phil Hawksworth: Nous pouvons prévisualiser cela localement sur notre serveur statique. C'est quelque chose qui est simple à faire sur n'importe quel environnement de développement local, puis le processus de déploiement qui le transmet à l'environnement d'hébergement et, idéalement, à un CDN afin de prendre de l'ampleur. Donc, avec ce type de fondation, je veux aborder une idée fausse commune en ce qui concerne les sites de JAMstack. Et je ne me suis pas rendu service en décrivant les sites de JAMstack comme des scripts JavaScript, des API et des balises. L'idée fausse commune est que chaque site de JAMstack doit être constitué de JavaScript, d'API et de balisage, mais ce genre de choses que nous avons négligé est que nous n'avons pas à utiliser les trois. Chacun de ces sites 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 dans le passé des choses qui sont servies par un serveur Apache, sur une machine Linux, et j’utilise PHP, mais je n’ai pas touché à une base de données et je ne commencerais pas à renommer une pile. nécessairement pour cela.

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

Phil Hawksworth: Cela pourrait être de nouveau extraire du contenu et organiser des fichiers Markdown. Cela pourrait être enrichissant avec les appels aux API, les API de GraphQL. Il peut s'agir de choses dans le navigateur, comme l'hydratation JavaScript de modèles remplis directement dans le navigateur. Et il pourrait être servi sur Amazon S3. Est-ce un site de JAMStack? Oui, 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 des API externes et peut-être l'hébergement sur Google Cloud. Est-ce que c'est JAMstack? Absolument! Vous voyez, je construis sur un thème ici. En utilisant quelque chose comme Nuxt, un autre générateur de site statique, désormais intégré à l'écosystème View. Peut-être que cela tire le 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 bien ça!

Phil Hawksworth: Mais on pourrait même y aller, vous savez, aller également de ce côté de l'échelle. Et pensez à une application Web progressive et faite à la main que nous avons construite de manière artisanale, avec le code JavaScript que nous avons créé nous-mêmes. Nous l’emballons avec webpack. Nous utilisons peut-être des jetons Web JavaScript et appelons les API pour procéder à l'authentification, en interagissant avec différentes API de navigateur, en l'hébergeant 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 étant JAMstack, car elles partagent un attribut commun et n'en ont aucune. d'entre eux sont servis avec un serveur d'origine. Aucun d'entre eux ne doit toucher un serveur qui exécute une logique au moment de la demande. Ils sont ensuite servis en tant qu'actifs statiques, puis enrichis en JavaScript et en appels aux API.

Phil Hawksworth: Je tiens donc à réitérer qu'un JAMstack signifie qu'il est capable d'être servi. directement à partir du CDN. Donc, je voudrais simplement souligner quelques impacts et implications de ceci, 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 (revenons à cet ancien diagramme), aux endroits où nous pourrions avoir à faire face à une attaque, nous devons sécuriser des éléments tels que l'équilibreur de charge, les serveurs Web, les serveurs de base de données. Toutes ces choses, nous devons nous assurer que nous ne pourrons pénétrer dans aucune attaque et, en fait, le CDN.

Phil Hawksworth: Si nous pouvions en extraire plus de morceaux de ce casse-tête, moins il y a de lieux pouvant être attaqués et moins nous avons à 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 de JAMstack que vous pourriez imaginer, aucun d’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 volume de trafic énorme, cherchant des solutions comme WP Admin, cherchant des moyens d'entrer, cherchant des vecteurs d'attaque.

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

Phil Hawksworth: Ceci, bien sûr, a également un impact sur les performances. Pour revenir à notre vieil ami, les endroits où nous voudrions peut-être essayer d’améliorer les performances, alors que la logique doit être exécutée à ces différents endroits. Cela se produit souvent dans les piles traditionnelles: elles commencent à ajouter des couches, des couches statiques afin d'améliorer les performances. En d’autres termes, essayez donc de trouver des moyens de commencer à vous 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. Nous commençons donc à introduire des éléments tels que la mise en cache dans l'infrastructure et les endroits évidents que nous pourrions trouver à faire, c'est sur le serveur Web. Plutôt que de mettre en œuvre cette logique, nous souhaitons servir quelque chose immédiatement sans exécuter cette logique.

Phil Hawksworth: Donc, c'est un peu comme un pas en avant vers le 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 bas solde, tout le CDN peut être considéré comme une cache. Mais sur la pile traditionnelle, nous devons trouver un moyen de gérer ce cache, car tout ne sera pas mis en cache. Donc, il y a une certaine logique à propos de. Ce qui doit être rempli dynamiquement par rapport à ce qui peut être mis en cache. Et dans le modèle JAMstack, tout est mis en cache. Tout est mis en cache à partir du moment où le déploiement est terminé, de sorte que nous pouvons y penser de manière tout à fait différente.

Phil Hawksworth: Cela commence alors à, en quelque sorte, à un passage à l'échelle, ainsi . Et à l’échelle, je parle, comment gérons-nous de gros volumes de trafic? Les piles traditionnelles vont commencer à ajouter une infrastructure pour pouvoir évoluer. Donc, oui, à la mise en cache. Nous commençons à mettre en place notre pile traditionnelle. Cela aidera – dans une certaine mesure. Ce qui se passe habituellement, c’est que, pour gérer de gros volumes de trafic, nous commençons à développer l’infrastructure et à ajouter de plus en plus de serveurs, plus d’éléments pour traiter ces demandes, ce qui coûte de l’argent et estimerait la charge être un casse-tête pour quiconque fait de l'architecture technique. C’était certainement pour moi. C’est pourquoi j’ai commencé à miser beaucoup plus sur l’approche de JAMstack, où je sais que tout est servi par le CDN, conçu par défaut pour gérer l’échelle, afin de gérer les performances dès le départ.

Phil Hawksworth: Je souhaite également faire un clin d'œil à l'expérience des développeurs et à l'impact que cela peut avoir. Aujourd'hui, l'expérience des développeurs ne doit jamais être vue comme une expérience qui surpasse 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 grandes expériences utilisateur!

Phil Hawksworth: Ainsi, lorsque nous réfléchissons au lieu où réside l'expérience du développeur et aux domaines de préoccupation de celui-ci: ici, dans une pile traditionnelle, nous devrions peut-être réfléchir à la manière dont le code est fourni. toutes ces différentes parties de l’infrastructure et la manière dont elles jouent toutes ensemble. Dans le monde de JAMstack, en réalité, ce dont nous parlons, c’est la boîte située en bas. Vous savez, comment avons-nous géré la construction et comment, comment automatisons-nous un déploiement pour que quelque chose soit servi au départ? Et la bonne chose est que, dans le modèle JAMstack, ce que vous faites dans cette construction est entièrement à vous.

Phil Hawksworth: C'est un problème très bien défini, parce que finalement, vous ' essayez de construire quelque chose que vous pouvez servir directement à partir d’un CDN. Vous voulez pré-rendre quelque chose, en utilisant les outils de votre choix: qu’il s’agisse d’un générateur de site statique construit en Ruby ou Python ou en JavaScript ou en Go ou en PHP, vous avez la liberté de faire ce choix. Cela peut donc créer un environnement beaucoup plus agréable pour votre travail. De plus, cela crée une opportunité d’avoir une réelle confiance des développeurs car un attribut réel des sites JAMstack est qu’ils peuvent être beaucoup plus facilement utilisés en tant que déploiement immuable et atomique.

Phil Hawksworth: Et je veux, en quelque sorte, m'éloigner des diapositives un instant pour décrire ce que cela signifie, car un déploiement immuable et un déploiement atomique peuvent… (cela peut simplement Cela ressemble un peu au marketing), mais ce que je vais faire, c’est que je vais sauter dans mon navigateur. Maintenant… en fait, je vais y retourner une seconde. Laissez-moi… faire juste ceci.

Phil Hawksworth: Nous y sommes. Ce sera plus facile. Saut droit dans la page. Maintenant, Scott, vous me direz, Scott, si vous ne pouvez pas voir mon navigateur, j’espère. Maintenant, en supposant que tout le monde puisse voir mon navigateur.

Scott: Tout va bien

Phil Hawksworth: Excellent! Merci beaucoup!

Phil Hawksworth: Donc, ce que je fais ici, c’est d’utiliser Netlify comme exemple, comme exemple de service. Mais, il s'agit d'un attribut commun aux sites pouvant être hébergés, de manière statique. Ainsi, lorsque nous parlons de déploiement immuable, nous entendons par là que chaque déploiement de code doit toucher différentes parties de l’infrastructure et changer beaucoup de choses. Ici, nous ne modifions pas l’état du site. le serveur. Nous créons une instance entièrement nouvelle du site pour chaque déploiement effectué. Et nous pouvons le faire car le site est une collection d’actifs statiques.

Phil Hawksworth: Je regarde ici le déploiement qui a eu lieu à partir de mon propre site Web. Je vais vous donner un régal. Voilà à quoi ça ressemble. C’est juste un blog, cela ne ressemble à rien de particulièrement remarquable ou excitant. C’est un blog généré de manière statique, mais ce que j’ai ici, c’est que tous les déploiements qui se sont déjà déroulés se perpétuent, car c’est une collection d’actifs statiques servis à partir d’un CDN. Maintenant, je pourrais remonter aussi loin que mon histoire puisse me porter et aller voir le site, car il était de retour… quand était-ce? C'était en août 2016. Etant donné qu'il s'agit d'un ensemble d'actifs statiques, nous sommes en mesure d'héberger cette adresse sur sa propre URL, qui est conservée à perpétuité. Si je le voulais, je pouvais décider d'y aller et de la publier. déploiement.

Phil Hawksworth: Alors, si quelqu'un regarde mon site Web, si je retourne sur mon site ici, si j'actualise cette page, celui-ci est servi directement depuis le CDN avec le actifs qui étaient là avant. Maintenant, je peux naviguer à nouveau. Içi vous pouvez voir. Ecoutez, je cinglais à propos de ça, j’utilisais ces termes terribles comme rendu isomorphe et parlais de JAMstack en 2016. Donc, c’est maintenant ce qui est diffusé en direct sur mon site. Encore une fois, car il y a des déploiements mutuels qui vivent simplement pour toujours. Je vais me contenter de poser ma propre sorte de tranquillité d’esprit – est-ce la première page? Ouais. Je vais revenir à mon dernier déploiement. Je devrai me refermer et me ramener dans le monde réel. Laissez-moi juste m'assurer que tout va bien.

Phil Hawksworth: D'accord! Génial! So, then now, this is back to serving my previous version, or my latest version of the site. I’ll hop back to keynote. So, this is possible because things are immutable and atomic. The atomic part of that means, again, that the deployment is completely contained. So, you never get the point where some of the assets are available on the web server, but some of them won’t. Only when everything is there in context and everything is there, complete, do we toggle the serving of the site to the new version. Again, this is the kind of thing you can do much more easily if you’re building things out as a JAMstack site that serves directly from the CDN as a bunch of assets.

Phil Hawksworth: I noticed that my timer has reset, after going back and forward from keynote, so I think I have about six or seven minutes left. Tell me, Scott, if—

Scott: So, yeah, we’re still good for about ten minutes.

Phil Hawksworth: Ten minutes? Okay, wonderful!

Scott: There’s no rush.

Phil Hawksworth: Thank you, that should be good!

Phil Hawksworth: So, just switching gear a tiny bit and talking about APIs and services (since APIs is part of JAMstack), the kind of services that we then might be able to use is mostly JAMstack. You know, we might be using services that we built in-house, or we might be using bought-services. There are lots of different providers who can do things for us, and that’s because that’s their expertise. Through APIs, we might be pulling in content from content management systems as a service, and there’s a bunch of different providers for this, who specialize in giving a great content management experience and then, exposing the content through API, so you used to be able to pull them in.

Phil Hawksworth: Likewise, there are different ways that you can serve assets. People like Cloudary are great at this, for doing image optimization, serving assets directly to your sites, again, through APIs. Or what about e-Commerce? You know, there are places like Stripe or Snipcart that can provide us API, so that we don’t have to build these services ourselves and get into the very complex issues that come with trying to build an e-Commerce engine. Likewise, identity, from people like Auth0 who are using Oauth. There are lots of services that are available and we can consume these things through APIs, either in the browser or at build time, or sometimes, a combination of both.

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. Right? 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: I really like, because the term JAMstack can be really misleading, because it’s trying to cover so many different things and the point I was trying to, I probably hammered it many times in that slide, is that it can be all kinds of things. It’s so broad, but the key is pre-rendering and hosting the core of the sites statically. It’s very easy for us to get into religious wars about where it needs to be a React site. It has to be a React app, in order to be a JAMstack site, or it’s a React app, so it can’t be JAMstack. But, really, the crux of it is, whether you use JavaScript or not, whether you’re calling APIs or not, if you pre-render and get things into a static host that can be very performant, that’s the core of JAMstack.

Vitaly: Yes, absolutely.

Phil Hawksworth: We’re very fortunate that browser’s are getting so much more capable, and the APIs that are there within browser’s themselves can allow us to do much more as well. So, that kind of opens the doors even further, but it doesn’t mean that everything that we build as a JAMstack site has to make use of everything. Depending on what we’re trying to deliver, that’s how we should start to choose the tools that we’re playing with to deploy those things.

Vitaly: Absolutely. We have Doran here. Doran, I think I know, Doran. I have a feeling that I know Doran. He’s asking, “Do you expect serverless to be gravitating towards seamless integration with JAMstack from [inaudible 00:44:36]? What is referred to as the A in JAM.

Phil Hawksworth: That’s a great question, because I think, serverless functions are — they just go so well with JAMstack sites, because in many ways, in fact, I think someone once asked me if JAMstack sites are serverless, and so I squirmed about that question, because serverless is such a loaded term. But, in many ways, it’s bang-on because I was talking, time and time again, about there’s no origin server. There’s no server infrastructure for you to manage. In fact, I once wrote a blog post called “Web Serverless,” because the world needs another buzz term, doesn’t it?

Phil Hawksworth: And really, the kind of point of that was, yes, we’re building things without servers. We don’t want to have to manage these servers, and serverless functions, or functions as a service, just fits into that perfectly. So, in the instances that you do need an API that you want to make a request to, where really it’s not sensible for you to make that request directly from the browser. So, for instance, if you’ve got secrets, or keys, in that request, you might not want those requests — that information — ever exposed in the client. But we can certainly proxy those things, and typically, traditionally, what we need to do then, is spin-up a server, have some infrastructure that was effectively doing little more than handling requests, adding security authentication to it and passing those requests on, proxying them back.

Phil Hawksworth: Serverless functions are perfect for that. They’re absolutely ideal for that. So, I sometimes think of serverless functions, or functions of a service, almost as like an escape hatch, where you just need some logic on a server, but you don’t want to have to create an entire infrastructure. And you can do more and more with that, and stipe the development pipelines for, development workflows, for functions as a service is maturing. It’s getting more accessible for JavaScript developers to be able to build these things out. So, yeah, I really think those two things go together very nicely.

Vitaly: All right, that’s a very comprehensive answer. Actually, I attended a talk just recently, where a front-end engineer from Amazon was speaking about serverless and Lamda functions they’re using — I was almost gone. He was always speaking about Docker, and Kubernetes, and all those things, Devox World, I was sitting there, thinking, “How did he end up there. I don’t understand what’s going on!” I had no idea what’s going on.

Phil Hawksworth: Exactly, but the thing is, it used to be the… I was… I accepted that I didn’t understand any of that world, but I didn’t have any desire to, since that was for an entirely different discipline. And that discipline is still really important. You know, people who are designing infrastructure — that’s still really key. But, it just feels, now, that I’m tempted. As someone with a front-end development background, as a JavaScript developer, I’m much more tempted to want to play in that world, because the tools are coming, kind of, closer to me.

Phil Hawksworth: It’s much more likely that I might be able to use some of these things, and deliver things kind of safely, rather than just as an experiment of my own, which is where I used to be dappling. So, it feels like we’re becoming more powerful as web developers, which is exciting to me.

Vitaly: Like Power Rangers, huh?

Vitaly: One thing I do want to ask you, though, and this is actually something we discussed already, maybe, a week ago, but I still wanted to bring it up, because the one thing that you mentioned in the session was the notion of having a stand-alone instance of every single deploy, which is really cool. The question, though, is if you have a large assignment, with tens of thousands of pages, you really don’t want to redeploy every thing, every single time. So, essentially, if you have, like, if you’re mostly using the static side of things. So, we had this idea for a while and I know this is actually something that you brought up last time. The idea of atomic deployments.

Vitaly: Where you actually, literally, were served some sort of div between two different versions of snapshots of the set-up. So, if you say, change the header everywhere, then, of course, every single page has to be redeployed. But if you change, maybe, a component, like let’s say, carousel, that maybe effects only a 1000 pages, then it would make sense to redeploy 15000 pages. But only this 1000. So, can we get there? Is it a magical idea that’s out there, or is it something that’s quite tangible, at this point?

Phil Hawksworth: I think that is, probably, the Holy Grail for static site generators and this kind of model because, certainly, you’ve identified probably the biggest hurdle to overcome. Or the biggest ceiling that you bump into. And that is websites that have many, tens of thousands or hundreds of thousands, or millions of URLs — the notion that the build can become very long. Being able to detect which URL’s will change, based on a code change, is a challenge. It’s not insurmountable, but it’s a big challenge. Understanding what the dependency graph is across your entire site and then, intelligently deploying that — that’s really tough to do.

Phil Hawksworth: Because as you mentioned, a component change might have very far-reaching implications but you — it’s difficult, always, to know how that’s going to work. So, there are a number of static site generators, the projects that are putting some weight behind that challenge, and trying to figure out how they do partial-regeneration and incremental builds. I’m very excited that the prospect that that might get solved day, but at the moment, it’s definitely a big challenge. You can start to do things like try to logically sharred your site, and think about, again, kind of similar to the migration issue. Well, this section I know is independent in terms of its, kind of, some of the assets that it uses, or the type of content that lives there, so I can deploy them individually.

Phil Hawksworth: But that’s not ideal to me. That’s not really the perfect scenario. One of the approaches that I’ve explored a little bit, just as a proof of concept, is thinking about how you do things, like, making intelligent use of 404s. So, for instance, a big use case for very large signs, maybe news sites is, when they need a URL when a breaking news story happens, they need to be first to get it deploy out there. They need to get a URL up there. Things like the BBC News, you’ll see that the news story will arrive on the website, and then overtime, they’ll add to it, incrementally, but getting there first is key. So, having a build that takes 10 minutes, 20 minutes, whatever it’s going to be, that could be a problem.

Phil Hawksworth: But, if they’re content is abstracted and maybe used to have been called from an API. I mentioned content management systems that are abstracted, like Contentful, or Sanity, or a bunch of those. Anything that has a content API changes to that content structure that will trigger a build and we’ll go through the run, but the other thing that could happen is that, well, if you publish your URL for that, and then publicize that URL, even if the build hasn’t run, if someone hicks that URL, if the first stop on its 404 is instead of saying, “We haven’t got it,” is actually to hit that API directly, then, you can say, “Well, the build hasn’t finished to populate that yet, but I can do it in the client.” I can go directly to the API, get that, populate it in the client.

Vitaly: Hmm, interesting.

Phil Hawksworth: So, even while the build is still happening, you can start populating those things. And then, once the build’s finished, of course it wouldn’t hit a 404. You would hit that statically running page. So, there are techniques and there are strategies to tackle it, but still, it’s a very long, rambling answer, I’m sorry, but my conclusion is, yeah, that’s a challenge. Fingers crossed we’ll get better strategies.

Vitaly: Yeah, that’s great. So, I’m wondering, so, at this point, we really aren’t thinking, not just what the performance in terms of the content delivering, but those in performance in terms of the build speed. Like building deployment. So, this is also something that we’ve been looking into for, quite a bit of time now, as well.

Vitaly: One more thing I wanted to ask you. So, this is interesting, like this technique that you mentioned. How do you learn about this? This is just something people tend to publish on their own blogs or, is it some medium or is there a central repository where you can get some sort of case studios, of how JAMstack—how companies moved while unloading, or have failed to move to JAMstack.

Phil Hawksworth: So, it’s kind of maturing this landscape a little bit, at the moment. I mean, some of these examples, I think, I’m in a very fortunate position, I work somewhere that I’m in a role that I’m playing with the toys, coming up with interesting ways to use it and start experimenting with them. So, these proofs of concepts are, kind of, things that I get to experiment with and try to address these challenges. But the, I kind of mentioned earlier, a case study that was shown at the JAMstack conference in New York, and certainly, events like that, we’re starting to see best practices or industry practices and industry approaches being talked about at those kind of events. And certainly, I want to see more and work on more case studies to get in places like on Smashing Magazines, so that we can share this information much more readily.

Phil Hawksworth: I think, large companies and the enterprise space, is gradually adopting JAMstack, in different places, in different ways, but the world is still sloped to get out there, so I think, each time a company adopts it and shares their experience, we all get to learn from that. But I really want to see more and more of these case studies get published, so that we can lean particularly about how these kind of challenges are overcome.

Vitaly: Alright, so, then, maybe just the last question from me, because I always like to read questions. So, the JAMstack land, if you could change something, maybe there is something that you desperately would love to see, beyond deployments. Anything else that would be really making you very happy? That would make your day? What would that be? What’s on your wishlist, for JAMstack?

Phil Hawksworth: What a question. I mean, had we not talked about incremental builds, that would be—

Vitaly: We did. That’s too late, now. This card has been passed, already. We need something else.

Phil Hawksworth: So—

Vitaly: What I mean, like on a platform, if you looked at the back platform, there are so many exciting things happening. We have Houdini, we have web components coming, and everything, since you could be changing the entire landscape of all the right components. On the other side, we have all this magical, fancy world with SS NGS, and, of course, obviously, we also have single-page applications and all. What are you most excited about?

Phil Hawksworth: I’m going to be obtuse here, because there is so much stuff that’s going on, it’s exciting, and there is so many new capabilities that you can make use of in the browser. The thing that I really get excited about is people showing restraint (laughs) and as I said, dull answer, but I love seeing great executions that are done with restraint, in a thoughtful — about the wider audience. It’s really good fun, and gratifying to build with the shiniest new JavaScript library or the new browser API that does, I don’t know, scratch and sniff capabilities in the browser, which we desperately need, any day now.

Phil Hawksworth: But I really like seeing things that I know are going to work in many, many places. They’re going to be really performant, are going to be sympathetic to the browsers that exist — not just on the desks of CEOs and CTOs who got the snazzy toys, but also people who have got much lower-powered devices, or they’ve got challenging network conditions and those kinds of things. I like seeing interesting experiences, and rich experiences, delivered in a way that are sympathetic to the platform, and kind of, compassionate for the wider audience, because I think the web reaches much further than us, the developers, who build things for it. And I get excited by seeing interesting things done, in ways that reach more people.

Phil Hawksworth: That’s probably not the answer you were necessarily—

Vitaly: Oh, that’s a nice ending. Merci beaucoup. No, that’s perfect, that really is. All right, I felt everything went good! Thank you so much for being with us! I’m handing out to Scott!

Phil Hawksworth: Great!

Vitaly: I’m just here to play questions and answers. So, thank you so much, Phil! I’m still here, but Scott, the stage is yours, now! Maybe you can share with us what’s coming up next on Smashing TV?

Scott: I will, but first, Phil, I can’t wait to see how the implementation of scratch-and-sniff API work. Sounds very interesting. And, Vitaly, JAMstackify is already taken.

Vitaly: (dejected) Taken?! Can we buy it?

Scott: No, it exists!

Vitaly: Well, that’s too late. I’m always late.

Phil Hawksworth: That’s exciting in its own way.

Vitaly: That’s the story of my life. I’m always late.

Scott: Members coming up next, I believe, Thursday, the 13th, we have my ol’ pa, Zach Leatherman, talking about what he talks about best, which is fonts. So, he’s talking about the Five Y’s of Font Implementations. And then, I’m also very interested in the one we have coming up on the 19th, which is editing video, with JavaScript and CSS, with Eva Faria. So, stay tuned for both of those.

Scott: So, that is again, next Thursday, with Zach Leatherman, and then on the 19th, with Eva, who will be talking about editing video in JavaScript and CSS. So, on that note, Phil, I can’t see you anymore, are you still there?

Phil Hawksworth: I’m here!

Scott: On that note, thank you very much everyone! Also, is anybody in the, kind of, close to Toronto area? Or anybody that’s ever wanted to visit Toronto? We have a conference coming up at the end of June, and there’s still a few tickets left. So, maybe we’ll see some of you there.

Vitaly: Thank you so much, everyone else!

Vitaly: Oh, by the way, just one more thing! Maybe Phil mentioned it, but we also have the JAMstack Conference in London, in July. So, that’s something to watch out for, as well. But I’m signing off and going to get my salad! Not sure what you—

Scott: Okay, goodbye, everybody!

Vitaly: All right, bye-bye, everyone.

That’s A Wrap!

We kindly thank Smashing Members from the very bottom of our hearts for their continuous and kind support — and we can’t wait to host more webinars in the future.

Also, Phil will be MCing at SmashingConf Toronto 2019 next week and at JAMstack_conf — we’d love to see you there as well!

Please do let us know if you find this series of interviews useful, and whom you’d love us to interview, or what topics you’d like us to cover and we’ll get right to it.

(ra, il)