Démystifier JAMstack : une entrevue avec Phil Hawskworth

Certains d'entre vous ont peut-être entendu parler de JAMstack, et peut-être même de la façon de passer de WordPress à Hugo, mais est-ce que JAMstack est une option viable pour tout type de projet ?

J'ai parlé avec Phil Hawksworth, un ingénieur front-end qui (après 9 ans de travail dans des agences est revenu travailler sur un produit autonome) se concentre maintenant sur le développement de stratégies pour les technologies JAMstack afin de rendre la construction pour le Web plus simple, plus rapide et plus sécurise. Phil co-animera également JAM_stack ldn, une conférence dédiée aux générateurs de sites statiques, sans serveur et JAMstack à Londres, les 9 et 10 juillet.

Vitaly : Alors bonjour et bienvenue dans l'une de nos conversations avec nos conférenciers à Smashing Conf et des gens généralement sympas. Vous vous souvenez peut-être de l'époque où FTP était une grande chose et peut-être êtes-vous encore en train de déployer pourquoi FTP est un espace parfaitement sûr, vous n'avez donc pas à vous en soucier. Mais les changements sont importants, vous n'utilisez plus FTP et passez plutôt à des flux de travail basés sur Git, et probablement à un déploiement continu. Tous ces sifflets et cloches fantaisistes. Et donc aujourd'hui, je suis très heureux d'accueillir Phil Hawksworth qui travaille actuellement chez Netlify, relations avec les développeurs [inaudible 00:10:00]. Bonjour Phil. Comment vas-tu aujourd'hui?

Phil : Je vais bien, comment vas-tu Vitaly ? Ça me fait plaisir de te voir.

Vitaly : Aw, je vais très bien. C'est toujours un plaisir de vous voir. Vous êtes comme un soleil qui diffuse Netlify et Jump Stack et tout.

Phil : J'essaie. Je ne suis même pas marqué, quelle occasion manquée.

Vitaly : C'est bon, c'est bon. Mais tu dois me le dire, pour que ce bijou ou jen ou jeet, genre, jem ? C'est jem ?

Phil : Confiture. C'est de la confiture. Tout tourne autour de la confiture.

Vitaly : C'est de la confiture. Donc la pile JAM. Pour les développeurs ou les concepteurs, en fait, jamais entendu le terme auparavant. Si vous vouliez peut-être résumer ce que c'est et pourquoi c'est bon et quels en sont les avantages en premier lieu. Pourquoi voudriez-vous jamais passer de votre bonne vieille pile traditionnelle à JAMstack. Peut-être pourriez-vous le résumer brièvement.

Phil : Laissez-moi voir si je peux essayer, car il est tentant de dire simplement, JAMstack, le JAM signifie Javascript, API et mockup. Mais cela en soi n'explique pas grand-chose, juste savoir ce que cela signifie. Donc, vraiment, JAMstack est un moyen de déployer et de servir des sites Web qui ne reposent pas sur un serveur d'origine, ils ne reposent pas sur des requêtes frappant un serveur actif tout le temps.

Phil : Donc, vous connaissez peut-être mieux les piles comme la pile LAMP qui était Linux, Apache, MySQL et PHP, c'était le genre de pile qui servait votre site là-bas. Avec JAMstack, cela devient un peu différent parce que nous avons en quelque sorte progressé d'un niveau, loin du serveur et plus près du navigateur, donc il pense beaucoup à entrer dans un navigateur aussi vite que possible, puis à utiliser les technologies du navigateur pour l'améliorer et l'augmenter plus tard. Donc, JAMstack consiste à pré-rendre les sites, à les intégrer au navigateur, puis peut-être à les améliorer, à les augmenter, l'expérience avec Javascript exécuté dans votre navigateur, peut-être à faire des requêtes aux API et ce genre de choses.

Phil : C'est donc le modèle, essayer d'éviter d'avoir un serveur que vous devez entretenir parce que je sais que l'entretien d'un serveur est difficile. Je ne sais pas pour vous, mais j'ai beaucoup de sites qui ont disparu quand je leur ai tourné le dos pendant quelques années. J'avais besoin de mettre à jour PHP, ce qui signifiait que je devais mettre à jour la version de Linux, ce que j'ai fait une fois dans une lune bleue. Il est donc difficile de maintenir les serveurs, donc l'idée de JAMstack est d'essayer de rendre aussi simple que possible le service des sites en tant qu'actifs statiques, puis de tirer le meilleur parti de toutes les API et incapacités du navigateur à faire des augmentations et à faire plus de choses avec Là-bas.

Vitaly : C'est logique. Eh bien, en fait, nous sommes passés à JAMstack il y a environ 2 ans maintenant.

Phil : Deux ans ?

Vitaly : Oui, c'était tout un voyage pour nous. Et bien sûr, nous avons appris quelques leçons en cours de route. Mais je me demande, diriez-vous que pratiquement chaque projet pourrait bénéficier d'une manière ou d'une autre du déplacement ou du déplacement de certaines parties de celui-ci vers JAMstack ou similaire, où voyez-vous ses limites? Est-ce quelque chose que chaque développeur pourrait potentiellement utiliser dans un projet ou est-ce quelque chose qui est en quelque sorte dédié à un groupe particulier de sites Web ou à un groupe de projets ?

Phil : Ouais, je veux dire, c'est tentant de dire, oh ouais, vous pouvez l'utiliser pour tout, mais je pense que vous devriez faire attention en disant cela à propos de n'importe quelle technologie. Vous savez, vous devez vraiment choisir les cas d'utilisation et vous assurer qu'ils sont bien adaptés. Je dirais le premier instinct lorsque vous pensez à un site JAMstack et que vous pensez peut-être à quelque chose qui est servi comme des actifs statiques, peut-être directement à partir d'un CDN. Vous pourriez penser, eh bien, ce n'est bon que pour les sites qui ne changent pas très souvent, ils sont devis sur devis, statiques, ils ne changent pas. Mais en réalité, ce n'est pas vraiment le cas car il existe maintenant de nombreux outils qui peuvent réduire les frictions lors du déploiement des choses.

Phil : Vous pouvez déployer plusieurs fois par jour, ou plusieurs fois par heure si vous le souhaitez et rendre les choses beaucoup plus dynamiques qu'auparavant. Donc, certains de ces cas d'utilisation où vous pensez qu'ils ne seraient pas appropriés ; ceux-ci entrent également dans le giron. Le moment où cela devient difficile, cependant, c'est peut-être lorsque nous créons des sites qui ont de nombreuses pages, des centaines de milliers ou des millions de pages, car le modèle JAMstack a vraiment beaucoup de sens lorsque vous pouvez pré-générer votre site vous utilisez peut-être un générateur de site statique. Ceux-ci ont vraiment en vogue en ce moment; ceux-ci sont vraiment très populaires.

Phil : Mais bien sûr, ils doivent faire un travail à chaque fois qu'ils déploient une mise à jour, donc si vous avez un site, peut-être comme un site de journal, qui contient plusieurs millions de pages, le travail nécessaire pour le régénérer peut être assez, vous savez, cela peut prendre beaucoup de temps, c'est à ce moment-là que vous commencez à vous heurter à certaines des limitations de l'endroit où JAMstack peut être, en quelque sorte, simplement utilisé. Vous pouvez commencer à devenir un peu rusé et commencer à contourner cela si, vous savez, vous êtes très très rusé, mais cela présente certainement des défis.

Phil : Une des choses que je commence à voir à partir d'une variété de différents générateurs de sites statiques comme Gatsby par exemple ou React Static, et aussi Hugo. Les équipes derrière ces générateurs de sites statiques commencent à explorer les moyens de générer progressivement les pages. En d'autres termes, vous ne redéployez pas l'intégralité du site ou ne régénérez pas l'intégralité du site à chaque fois que quelque chose change, mais essayez de trouver des moyens. pour faire des builds incrémentiels. C'est une sorte de problème difficile à surmonter, mais il y a du travail en cours là-dessus en ce moment, ce qui aidera également à essayer de briser cette barrière. Mais, certainement pour le moment, trouver des moyens d'utiliser un site JAMstack pour un site Web qui compte plusieurs millions de pages ou plusieurs centaines de milliers de pages, c'est là que cela peut être un peu difficile en ce moment.

Vitaly : Oh, c'est intéressant. Donc, en fait, l'idée d'être alors au service d'une div de l'état que vous avez et essentiellement que tout ce que vous avez à construire, comme un nouveau portail, doit être en quelque sorte paginé dedans, donc c'est intéressant de voir cela se produire. Parce que vous aussi, tout récemment, je pense qu'il y a deux semaines, il y avait un article de Jason Pamental à venir où l'idée était en fait très similaire où vous chargeriez réellement les polices, puis vous chargez la première page dont vous avez besoin et ensuite vous chargez la seconde, puis vous les fusionnez de manière à créer une nouvelle police, comme également le chargement de police incrémentiel.

Phil : Intéressant.

Vitaly : Ce serait vraiment intéressant d'explorer cela.

Phil : Ouais, et ce n'est pas tant le chargement, c'est la génération-

Vitaly : La génération, la construction.

Phil : Ouais, exactement.

Vitaly : Je comprends. Mais selon vous, quels sont les types de défis communs auxquels la plupart des développeurs sont confrontés ? Eh bien, je veux dire, laissez-moi reculer d'abord. Si vous n'avez jamais travaillé sur JAMstack auparavant et que vous êtes très à l'aise et satisfait de votre pile LAMP et que vous vouliez peut-être explorer les possibilités et les avantages tels que la sécurité et les performances de JAMstack. Comment commenceriez-vous réellement? Que déplaceriez-vous, qu'est-ce que cela signifie de changer de flux de travail ?

Phil : Donc, les changements apportés au flux de travail peuvent en fait être assez profonds parce que vous enlevez une grande partie de l'infrastructure dont vous dépendriez normalement et dites en fait que nous pouvons nous en débarrasser et commencer à déployer des choses directement sur un CDN. Mais en ce qui concerne la façon dont quelqu'un pourrait commencer à expérimenter cela, il y a de fortes chances qu'il en utilise déjà certains aspects. Vous savez, même sur des manières traditionnelles de construire des choses pour le Web.

Phil : Si vous réfléchissez à la façon dont vous pourriez construire quelque chose sur la pile LAMP, il y a de fortes chances que votre PHP soit là, vous faites des choses comme écrire un modèle qui récupère les données d'une source de données, dans ce cas, la base de données MySQL ou une sorte de la base de données, en rendant ces choses visibles et en les faisant ensuite servir. Et c'est un peu similaire au fonctionnement des générateurs de sites statiques. Ils ont des modèles, ils récupèrent des données quelque part qui pourraient être une sorte de données structurées dans des fichiers ou qui pourraient toucher une sorte de base de données ou une API de contenu. Quoi qu'il en soit, il saisit des données, combine ces données avec des modèles, génère des vues et la seule différence est qu'il ne le fait pas à la demande, il le fait à l'avance. Ainsi, certaines des étapes logiques de ce type d'étapes cognitives pour un développeur ne sont peut-être pas si énormes.

Phil : Le plus grand changement est de penser à la façon dont vous déployez les choses. Parce que ce que vous déployez vraiment, c'est l'intégralité de vos ressources créées et rendues chaque fois que vous souhaitez effectuer un déploiement. Cela commence à rassembler des choses comme la gestion du contenu et la gestion du code au même endroit, de sorte que des choses comme la vision contrôlent toutes ces choses ensemble. Cela commence donc à être une façon légèrement différente de penser à la façon dont vous pourriez développer et gérer des sites et le contenu qu'ils contiennent. Il y a donc quelques changements. Mais la bonne chose est que beaucoup de générateurs de sites statiques peuvent être assez simples pour commencer à expérimenter et la bonne chose est que vous n'avez pas besoin d'une tonne d'infrastructure pour le faire. Donc, ce qui est bien, c'est que vous pouvez vraiment commencer à créer des choses directement sur votre machine locale. Vous exécutez un générateur de site statique directement sur votre machine et vous pouvez avoir une très bonne idée du résultat sans avoir à vous appuyer sur de nombreuses autres infrastructures.

Phil : Donc, ce genre de première étape, la rampe d'accès, peut être assez superficielle pour que vous commenciez à dire : « Eh bien, je vais essayer cet ensemble d'outils en particulier. Je peux les faire fonctionner localement. Et vous aurez une bonne confiance que lorsque vous déployez la sortie de cela quelque part, ce sera exactement la même là où vous la déployez que ce serait localement. C'est l'une des choses que j'aime dans le rendu des choses qui sont statiques parce que vous ne dépendez pas de beaucoup d'infrastructures et de pièces mobiles pour les servir. Vous pouvez les regarder sur le serveur statique de votre propre machine et penser, "ouais, c'est comme ça que ça fonctionnera quand ça passera à un CDN."

Vitaly : Mm-hmm (affirmatif) ; Et aussi l'infrastructure quand nous regardons, par exemple, la façon dont nous construisons [inaudible 00:10:07], et il y a un grand nombre d'options de ce que vous pourriez faire. Pour le serveur, pour le client et tout le reste.

Phil : Ouais.

Vitaly : Et donc, je pense, dans notre cas parce que nous construisons en quelque sorte un squelette et il sert directement à travers CDI avec du contenu et tout et amélioré avec Javascript. C'était en fait assez raisonnable et assez, je ne dirais pas facile, mais il était logique de passer à ce type de configuration. Car au final, c'est juste du contenu qui part sur la page. C'est juste du HTML avec quelques zones de commentaires et un champ de recherche et quelques autres choses. Mais si vous vous dirigez vers une application vraiment autonome, peut-être même une application financière, une banque en ligne, ce genre de choses. Pensez-vous toujours que JAMstack serait une bonne option à considérer si vous avez quelque chose qui demande beaucoup de logique ? A-t-il besoin d'un serveur ou pas ?

Phil: Eh bien, je déteste répéter la vieille phrase "ça dépend". Mais ça dépend un peu. Cela dit, il existe de nombreuses applications qui fonctionnent aussi bien en tant qu'application Javascript qu'en ayant un composant côté service. Je dis cela avec une certaine prudence car je suis un peu de la vieille école en matière de développement Web et j'aime vraiment mettre les choses dans le navigateur au format HTML autant que possible, puis avoir un filigrane très élevé à partir duquel vous améliorez progressivement à partir de. Donc, personnellement, je n'aime pas tout faire en Javascript et simplement expédier une balise body vide, puis tout exécuter via Javascript.

Phil : Cela dit, il y a des fois où c'est parfaitement acceptable. Si vous envisagez un certain type d'application qui, bien sûr, dépendrait fortement de Javascript et que vous connaissez votre public. Cela peut être tout à fait raisonnable. Il y a des choses qui ont été expédiées récemment. Je pense en fait à quelque chose qui a été livré à Google IO car, par exemple, l'équipe Chrome a créé un jeu qui était très fortement Javascript et qui fonctionnait parfaitement de manière statique. Il existe de nombreux cas d'utilisation où cela peut fonctionner.

Phil : Pour en revenir à votre exemple financier, j'avais l'habitude de travailler, mon tout premier travail en fait, consistait à mettre des chiffres sur les écrans pour que les commerçants échangent en utilisant les technologies Web et c'était avant les sockets Web, c'était avant Ajax, c'était avant tout vraiment cela a été utile pour vous aider à faire cela et c'est un peu difficile, mais plus récemment, vous feriez beaucoup de choses de ce genre en Javascript et cela est parfaitement logique. Vous pouvez commencer à envoyer des requêtes sécurisées aux API directement depuis le navigateur. Il existe maintenant de nombreux modèles pour effectuer l'authentification et l'autorisation directement à partir de votre navigateur. Donc, à bien des égards, cela peut simplifier la pile pour les institutions financières qui souhaitent développer certaines de ces choses, car la façon dont elles peuvent découpler certaines de ces choses peut les rendre beaucoup plus gérables. Je pense donc certainement que le modèle JAMstack pourrait parfaitement fonctionner dans ce scénario également.

Vitaly : Ok, alors peut-être revenir maintenant pour explorer ce monde de JAMstack et de front-end. Qu'est-ce qui t'excite le plus ces jours-ci, Phil ? Si vous regardez JAMstack et le front-end en général, est-ce quelque chose qui vous tient vraiment éveillé la nuit où vous vous réveillez le matin en espérant que oui, je vais travailler là-dessus un jour. Un jour je le ferai. Avez-vous [diaphonie 00:13:33]

Phil : Ouais, et c'est le genre de chose où votre réponse peut être différente de jour en jour parce qu'on a l'impression que ce monde bouge si vite. Et cela en soi est l'une des choses qui m'excite tant. Maintenant que nous commençons à voir les API du navigateur commencer à vraiment progresser et le genre de choses que nous pouvons faire directement dans le navigateur sans avoir à les implémenter nous-mêmes. C'est plutôt excitant pour moi. Je suis toujours très con quand il s'agit de SVG. Je devrais expliquer le mot duffer, si quelqu'un qui n'est pas anglais et qui regarde ça, ça veut dire un imbécile. Ça veut dire que je suis loin derrière la courbe.

Phil : Mais je me trouve vraiment vouloir faire plus avec les SVG et les animations sont le genre de choses sur lesquelles je suis juste en retard et je veux jouer avec ça. Mais des choses comme les API du navigateur, que ce soit des choses hors ligne ou pour améliorer les performances et en particulier en ce moment où le chargement des polices semble devenir de plus en plus accessible afin que nous puissions commencer à vraiment créer des choses visuellement très riches et plus proches de ce que nous pourrions vouloir faire avec la typographie. Je suis un peu un nerd pour ce genre de choses, j'aime ce genre de choses donc je veux jouer de plus en plus avec ça.

Vitaly : Alors Phil, en train de parler de JAMstack conf à Londres. Pouvez-vous également expliquer en quelques mots de quoi il s'agira, quel est l'objectif et à qui s'adresse-t-il et quel est votre rôle là-bas ? Juste dans les coulisses, en prenant soin du contenu et de tout. Quel est votre rôle là-bas ?

Phil : J'ai donc eu la partie amusante du travail. J'ai donc eu l'occasion de sortir et de trouver des conférenciers et de trouver du contenu intéressant, donc je suis vraiment enthousiasmé par la façon dont les programmes s'articulent. Nous avons des gens comme Chris Coia qui vont parler de l'autonomisation des développeurs front-end et de tout ce que nous pouvons faire avec les technologies front-end désormais basées sur ce modèle JAMstack. Nous avons des gens comme Jake Archibald et Surma de l'équipe Google Chrome qui vont parler de choses comme les performances dans le front-end et des façons dont nous pouvons vraiment générer des expériences très performantes soit avec un hébergement statique ou une infrastructure ou un code qui s'exécute directement dans le navigateur.

Phil : Nous allons également avoir Yuna Kravitz qui parlera de choses à faire avec CSS et Houdini et tout ce genre de choses. Et bien plus encore. Nous parlerons également des choses à faire avec le changement culturel qu'un modèle JAMstack peut avoir sur votre organisation et sur vos projets afin qu'il atteigne vraiment partout. Je suis donc un peu excité à ce sujet. J'aurai également l'occasion de présenter toutes ces personnes parce qu'elles m'ont laissé devenir sauvage et être également le MC, ce qui signifie que je peux parler à ces personnes et poser quelques questions et ce genre de choses. Je pense donc que cela devrait être très intéressant pour tous ceux qui s'intéressent au développement frontal et également aux nouveaux modèles de livraison de projets sur le Web de manière très efficace.

Vitaly : Oh, alors tu aimes être sous les projecteurs sur scène, hein ?

Phil : Je suis un chercheur d'attention. Tu devrais le savoir maintenant, Vitaly.

Vitaly : Oh, en fait j'ai toujours pensé que tu étais une personne très humble et gentille et gentille, apparemment j'étais-

Phil : C'est un acte, c'est un acte.

Vitaly : D'accord, ça va. Phil, nous nous reverrons dans quelques minutes, en fait, demain.

Phil : Je te verrai bientôt pour un autre événement mais sinon je te verrai en juillet, les 9 et 10 juillet.

Vitaly : [inaudible 00:16:52] Donc, dans cet esprit, merci Phil et signature. Au revoir tout le monde.

Phil : A bientôt.

C'est un Wrap !

Nous sommes impatients d'accueillir Phil à SmashingConf Toronto 2019, avec une session en direct sur JAMstack. Nous serions ravis de vous y voir aussi!

Faites-nous savoir si vous trouvez cette série d'entretiens utile, et qui vous aimeriez que nous interviewions, ou quels sujets vous aimeriez que nous abordions et nous y reviendrons !