Smashing Podcast Épisode 22 Avec Chris Coyier : qu'est-ce que le sans serveur ?
Publié: 2022-03-10Aujourd'hui, on parle d'architectures Serverless. Qu'est-ce que cela signifie et en quoi cela diffère-t-il de la façon dont nous pourrions créer des sites actuellement ? J'ai parlé à Chris Coyier pour le savoir.
Afficher les remarques
- Le microsite de Chris La puissance du sans serveur pour les développeurs frontaux
- Chris sur Twitter
- Podcast de l'émission ShopTalk
Mise à jour hebdomadaire
- "Configuration de Redux pour une utilisation dans une application du monde réel",
par Jerry Navi - "Pouvez-vous concevoir un site Web pour les cinq sens ?"
par Suzanne Scacca - "Créer un blog statique avec Sapper et Strapi,"
par Daniel Madalitso Phiri - "Un guide pratique des visites de produits dans les applications React",
par Blessing Krofegha - "Comment créer une Porsche 911 avec Sketch ,"
par Nikola Lazarević
Transcription
Drew McLellan : C'est un concepteur et développeur Web que vous connaissez peut-être grâce à CSS-Tricks, un site Web qu'il a lancé il y a plus de 10 ans et qui reste une ressource d'apprentissage fantastique pour ceux qui créent des sites Web. Il est le co-fondateur de CodePen, le terrain de jeu de codage basé sur un navigateur et la communauté utilisée par les front-ends du monde entier pour partager ce qu'ils font et trouver l'inspiration de ceux qu'ils suivent. Aux côtés de Dave Rupert est le co-animateur de ShopTalk Show, un podcast sur la création de sites Web. Nous savons donc qu'il en sait beaucoup sur le développement Web, mais saviez-vous qu'il a déjà remporté un concours de mangeurs de hot-dogs en utilisant uniquement son charme ? Mes amis fracassants, veuillez accueillir Chris Coyier. Bonjour Chris, comment vas-tu ?
Chris Coyier : Hé, je suis fracassant.
Drew : Je ne voulais pas vous parler aujourd'hui de CodePen, et je ne veux pas nécessairement vous parler de CSS-Tricks, qui est l'une de ces ressources incroyables qui, je suis sûr que tout le monde le sait, apparaît tout en haut de Google. Résultats de la recherche lorsque vous cherchez des réponses à n'importe quelle question de développement Web. Votre visage apparaît et il y a un article de blog utile écrit par vous ou l'un de vos contributeurs invités.
Chris : Oh, j'avais l'habitude de faire ça. Il y avait un… Je ne sais pas, c'était probablement à l'époque où Google avait ce réseau social bizarre. Ca c'était quoi? Google Plus?
Drew : Oh, en plus, ouais.
Chris : Oui, où ils associaient un site Web à un compte Plus, et donc mon compte Plus avait un avatar, et l'avatar était moi, donc il s'affichait dans les résultats de recherche. Je pense que ces jours sont révolus. Je pense que si vous…
Drew : Je pense que oui, ouais-
Cris : Ouais.
Drew : Mais je voulais en quelque sorte vous parler de quelque chose qui a été un peu plus une sorte d'intérêt secondaire pour vous, et c'est ce concept d'architectures sans serveur.
Chris : Mm (affirmatif).
Drew : C'est quelque chose sur lequel vous en apprenez un peu plus depuis un petit moment. Est-ce correct?
Cris : Ouais, ouais. Je ne suis qu'un fan. Cela semble être un ajustement naturel à l'évolution du développement frontal, où j'ai l'impression d'avoir au moins une certaine expertise. Je me considère beaucoup plus comme un… beaucoup plus utile sur le front-end que sur le back-end, pas que je… je le fais tous ces jours-ci. Je suis là depuis assez longtemps pour ne pas avoir peur de regarder un peu de code Ruby, c'est sûr. Mais je préfère le frontal. Je l'ai étudié plus. J'ai participé à des projets plus à ce niveau, puis vient ce petit genre de nouveau paradigme qui dit : « Vous pouvez utiliser vos compétences en JavaScript sur le serveur », et c'est intéressant. Vous connaissez? C'est comme ça que je pense. Il y a beaucoup plus que cela, mais c'est pourquoi je m'en soucie, c'est parce que j'ai l'impression que les développeurs front-end ont creusé si profondément dans JavaScript. Et maintenant, nous pouvons utiliser ce même ensemble de compétences ailleurs. Mmm, plutôt cool.
Drew : On dirait qu'un tout nouveau monde s'est ouvert, alors que si vous n'étiez qu'un codeur frontal… Je dis, juste un codeur frontal, je ne devrais pas. Si vous êtes un codeur front-end et que vous avez l'habitude de travailler avec un collègue ou un ami pour vous aider dans l'implémentation back-end, cela s'est soudainement ouvert. Et c'est quelque chose que vous pouvez gérer vous-même sur l'ensemble de la pile.
Cris : Ouais, ouais. C'est ça.
Drew : S'adressant à l'éléphant dans la pièce, tout en haut. Nous parlons de sans serveur, et évidemment, nommer les choses est difficile. Nous savons tous que. L'architecture sans serveur ne signifie pas qu'il n'y a pas de serveurs, n'est-ce pas ?
Chris : Je pense que c'est obligatoire, comme si c'est le premier podcast dont vous entendez parler, ou dans le premier... vous n'entendez le mot « sans serveur » que la première douzaine de fois que vous l'entendez, il est obligatoire que vous avoir une réaction viscérale et avoir ce genre de "Oh, mais il y a encore des serveurs." C'est bon. Si cela vous arrive en ce moment, sachez simplement que c'est une étape obligatoire. C'est comme n'importe quoi d'autre dans la vie. Il y a des étapes pour comprendre. La première fois que vous entendez quelque chose, vous devez en quelque sorte le rejeter un peu, puis ce n'est qu'après une douzaine de fois environ, ou après qu'il vous a un peu prouvé sa valeur, que vous pouvez entrer dans les étapes suivantes de comprendre ici. Mais le mot a gagné, donc si vous vous battez toujours contre le mot "sans serveur", je déteste vous dire que le train a quitté la gare là-bas. Le mot a déjà du succès. Vous n'allez pas gagner celui-ci. Désolé.
Chris : Mais je pense que c'est intéressant que… ça commence à être comme, peut-être qu'il n'y a pas de serveurs impliqués parfois. Je pense que l'une des choses qui a verrouillé le sans serveur en tant que concept était AWS Lambda. Ils étaient en quelque sorte les premiers sur la scène. Un lambda est comme une fonction que vous donnez à AWS et il le place dans le ciel magique et ensuite… il a une URL, et vous pouvez l'appuyer et il exécutera cette fonction et renverra quelque chose si vous le souhaitez. Vous connaissez? C'est juste HTTP ou autre. C'est comme ça que ça marche, qui… la première fois que vous entendez ça, vous vous dites : « Pourquoi ? Je m'en fous. Mais alors, il y a des choses évidentes. Il pourrait connaître mes clés API auxquelles personne d'autre n'a accès. C'est pourquoi vous exécutez le back-end pour commencer, c'est qu'il connaît des éléments secrets qui n'ont pas besoin d'être dans le JavaScript côté client. Donc, s'il a besoin de parler à une base de données, il peut le faire. Il peut le faire en toute sécurité sans avoir à exposer les clés API ailleurs. Ou même où se trouvent ces données ou comment elles les obtiennent, c'est…
Chris : C'est plutôt cool. Je peux écrire une fonction qui parle à une base de données, obtenir des données, les renvoyer. Frais. Donc, Lambda c'est ça, mais AWS fonctionne. Vous devez choisir une région. Vous êtes comme, "Je ne sais pas. Où ça devrait être, Virginia ? Oregon? Dois-je choisir celui d'Australie ? Je ne sais pas." Ils en ont 20, 30. Je ne sais même pas combien ils en ont de nos jours, mais même les lambdas avaient des régions. Ils ont, je pense, ces jours-ci ont Lambda@Edge, ce qui signifie que c'est toutes les régions, ce qui est plutôt cool. Mais ils étaient les premiers, et maintenant tout le monde a quelque chose comme Lambda. Tous les services cloud. Ils veulent une sorte de service dans ce monde. L'un d'eux est CloudFlare. CloudFlare a des travailleurs. Ils ont beaucoup plus d'emplacements qu'AWS, mais ils l'ont exécuté à un moment différent aussi… comme un travailleur CloudFlare… c'est similaire à un lambda en ce sens que vous pouvez exécuter Node. Vous pouvez exécuter JavaScript. Vous pouvez également exécuter un certain nombre d'autres langages, mais… Je pense à ce genre de choses en grande partie, le langage le plus intéressant est JavaScript, juste à cause de sa prévalence.
Chris : Cela se produit uniquement au niveau du CDN, qui, je suppose, est un serveur, mais j'ai tendance à ne pas considérer les CDN comme un serveur. Pas aussi évidemment qu'autre chose. Il commence à se sentir encore plus sans serveur ces derniers temps. Un CDN est-il un serveur ? Je veux dire, je suppose que c'est un ordinateur quelque part, mais ça ressemble encore moins à un serveur.
Drew : On dirait que, oui, un CDN peut être un serveur, mais c'est la version la plus minimale d'un serveur. C'est comme un serveur léger, si vous voulez.
Cris : Ouais. Sûr.
Drew : D'accord. J'ai entendu dire… Je ne me souviens pas de la source à créditer, malheureusement, mais j'ai entendu dire que le sans serveur était « comme utiliser un service de covoiturage comme Uber ou Lyft » ou autre. Vous pouvez être sans voiture et ne pas posséder de voiture, mais cela ne signifie pas que vous n'utilisez jamais de voiture.
Chris : Ouais, ça ne veut pas dire que les voitures n'existent pas. Mmm, c'est gentil.
Drew : Vous n'en invoquez qu'un lorsque vous en avez besoin, mais en même temps, vous ne payez pas le coût d'achat initial d'une voiture. Vous ne payez pas l'entretien ou le carburant ou-
Chris : C'est vrai, et le prix a du sens aussi, n'est-ce pas ? C'est zonte. C'est une belle analogie, je pense. Et puis, parce que c'est aussi au niveau du CDN, il intercepte simplement les requêtes HTTP qui se produisent déjà, ce qui signifie que vous ne lui demandez pas… vous ne lui envoyez pas de requête et il renvoie une requête. Cela se produit naturellement pendant la demande, ce qui donne également l'impression d'être moins serveur. Je ne sais pas, c'est intéressant. C'est intéressant c'est certain. C'est donc un gros problème, cependant, que vous ayez soulevé la question des prix. Que vous ne payez que ce que vous utilisez. C'est important aussi, parce que… disons que vous êtes un développeur back-end, qui a l'habitude de faire tourner des serveurs toute sa vie. Et ils en assument les coûts : « J'ai besoin de ce type de serveur avec ce type de mémoire, ce type de processeur et ce type de spécifications. Et voici combien cela va coûter. Serverless arrive et coupe la tête de cette tarification.
Chris : Donc, même si vous êtes un développeur back-end qui n'aime pas trop ça, qu'il n'aime pas ça, comme si vos compétences étaient exactement ce qu'elles étaient au fil des ans, vous comparez le prix et vous êtes comme, "Quoi? Je pourrais payer 1 % de ce que je payais auparavant ? » Vous n'avez pas le droit de ne pas vous en soucier, n'est-ce pas ? Si vous êtes ce développeur back-end qui paie cent fois plus pour son service que ce qu'il doit payer, vous êtes alors un peu mauvais dans votre travail. Désolé de dire. Cela s'est produit et cela a fait voler en éclats les prix à bien des égards. Vous devez vous en soucier. Et c'est plutôt cool que quelqu'un d'autre le soit… Ce n'est pas comme si vous n'aviez pas du tout à vous soucier de la sécurité, mais ce n'est pas votre serveur. Vous n'avez pas… votre fonction lambda ou cloud, ou votre travailleur, ou quoi que ce soit, n'est pas assis sur un serveur qui se trouve juste à côté de données vraiment sensibles sur votre propre réseau. Ce n'est pas juste à côté de votre base de données.
Chris : Si quelqu'un écrit du code qui tente d'une manière ou d'une autre de s'éjecter du worker ou du lambda, ou autre, et essaie d'accéder à d'autres choses sur son chemin, il n'y a rien à obtenir. Donc, la sécurité est aussi un gros problème, donc encore une fois, si c'est votre travail en tant qu'administrateur du serveur, c'est de vous occuper de la sécurité de cette chose. En l'exécutant, en exécutant certaines choses dans Lambda, vous obtenez simplement une sécurité naturelle, ce qui est formidable. Donc, c'est beaucoup moins cher. C'est bien plus sécurisé. On encourage ces petites architectures modulaires, ce qui peut être une bonne idée. Il semble que ce soit domino après domino de bonnes idées ici. C'est pourquoi c'est remarquable. Vous connaissez?
Drew : Oui, je veux dire, traditionnellement avec une architecture basée sur un serveur que nous utilisons depuis des décennies sur le Web, vous avez un serveur Web que vous gérez vous-même. Il contient votre code frontal, votre code principal, votre base de données et tout. Ensuite, vous devez le maintenir et le faire fonctionner et payer les factures, et même s'il n'est pas utilisé, il est là pour enregistrer les factures. L'utilisateur ferait une demande et il construirait tout ce matériel de requête HTML à partir de la base de données, l'enverrait tout au navigateur. Ce processus fonctionne. C'est ainsi que beaucoup de choses sont construites. C'est probablement la majorité de la façon dont le Web est construit. C'est ainsi que fonctionnent des choses comme WordPress. Est-ce vraiment un problème que nous devons résoudre ? Je veux dire, nous avons un peu parlé des coûts. Quels sont les autres types de problèmes avec cela, que nous sommes… que nous devons résoudre, et que l'absence de serveur pourrait nous aider à résoudre ?
Chris : Ouais, les problèmes avec l'approche de la vieille école. Oui, je ne sais pas, peut-être qu'il n'y en a pas. Je veux dire, je ne dis pas que tout le Web doit changer son tout… tout du jour au lendemain. Je ne sais pas. Peut-être que ce n'est pas vraiment le cas, mais je pense que cela ouvre des portes. Il semble que lorsque de bonnes idées arrivent comme celle-ci, elles changent lentement le fonctionnement du Web. Donc, s'il y a un CMS construit d'une manière qui s'attend à ce qu'une base de données soit là, cela signifie que peut-être que les hôtes du futur commenceront à en tirer parti de manière intéressante. Peut-être avez-vous l'impression qu'il ne s'agit que d'un serveur traditionnel, mais les hôtes eux-mêmes l'ont exploité, comment ils fonctionnent, vers des architectures sans serveur. Donc, vous ne savez même pas vraiment ce qui se passe, mais ils ont trouvé un moyen de réduire leurs coûts en hébergeant les éléments dont vous avez besoin sans serveur. Peut-être que oui, vous n'avez même pas besoin de vous en soucier en tant que développeur, mais au niveau méta, c'est ce qui se passe. Peut-être. Je ne sais pas.
Chris : Cela ne signifie pas non plus que… Les bases de données sont toujours là. S'il s'avère que l'architecture d'une base de données relationnelle est la bonne façon de stocker ces données, tant mieux. Je mentionne cela parce que ce monde de Serverless grandit en même temps que JAMstack. Et JAMstack est cette architecture qui est, "Vous devriez servir votre site Web à partir d'hôtes statiques, qui n'exécutent rien du tout sauf pour..." Ils sont comme de petits CDN. Ils disent : « Je ne peux rien faire. Je n'utilise pas PHP. Je n'utilise pas Ruby. Je cours rien. Je fonctionne sur un tout petit serveur Web qui est juste conçu pour servir uniquement des fichiers statiques.
Chris : "Et puis, si vous devez faire plus que cela, si vous devez extraire des données d'une base de données relationnelle, faites-le à un autre moment, pas au moment du serveur. Vous pouvez soit le faire dans un processus de construction à l'avance, et extraire ces éléments de la base de données, pré-construire des fichiers statiques et je les servirai, soit le faire au moment de l'exécution. Cela signifie que vous obtenez ce shell d'un document, puis il fait une requête JavaScript pour obtenir des données et les préremplit ensuite. Donc, vous le faites à l'avance ou après l'heure, mais cela ne signifie pas « n'utilisez pas de base de données relationnelle ». Ça veut juste dire, « Ne laissez pas le serveur le générer au moment de la demande du document », ce qui est un… Je ne sais pas, c'est un peu un changement de paradigme.
Chris : Ce n'est pas seulement JAMstack non plus. Nous vivons également à l'époque des frameworks JavaScript. Nous vivons à une époque où l'on commence à s'attendre un peu plus à ce que la façon dont une application JavaScript démarre, c'est qu'elle monte certains composants, et au fur et à mesure que ces composants montent, elle demande les données dont elle a besoin. Et donc, il peut être assez naturel pour quelque chose comme un site Web React de se dire: «Eh bien, je vais simplement appuyer sur une fonction sans serveur pour cracher les données dont il a besoin. Il frappe essentiellement une API JSON. J'obtiens les données JSON dont j'ai besoin et je me construis à partir de ces données, puis je rends sur la page. Maintenant, que ce soit bon ou mauvais pour le Web, c'est comme : « Je ne sais pas. Dommage. Le navire a navigué. C'est comme ça que beaucoup de gens construisent des chantiers. Ce sont juste des choses rendues par le client. Ainsi, JavaScript sans serveur et moderne vont de pair.
Drew : Je suppose que vous n'avez pas besoin de vendre en gros… d'examiner une architecture ou une autre. Il y a une zone au milieu où des parties d'une infrastructure pourraient être plus traditionnelles et des parties pourraient être sans serveur, je suppose ?
Cris : Ouais. Eh bien, ils essaient de vous le dire de toute façon. Quiconque veut vous vendre une partie de son architecture vous dit : « Vous n'êtes pas obligé d'acheter tout de suite. Faites-le un peu. Parce que bien sûr, ils veulent que vous plongez votre orteil dans tout ce qu'ils vendent, car une fois que vous trempez l'orteil, les chances que vous vous éclaboussiez dans la piscine sont beaucoup plus élevées. Donc, je pense que… ce n'est pas un mensonge, cependant, nécessairement, bien que je trouve un peu moins de chance dans… Je ne veux pas que mon stack soit un peu de tout. Je pense qu'il y a là une mort technique que je ne veux pas toujours avaler.
Drew : Mm (affirmatif).
Chris : Mais c'est possible. Je pense que le plus cité est… disons que j'ai un site qui contient un élément de commerce électronique, ce qui signifie… et disons un commerce électronique à grande échelle, donc 10 000 produits ou quelque chose, que cette architecture JAMstack n'a pas atteint le point où c'est toujours particulièrement efficace pour reconstruire ça statiquement. Donc, la pensée va, "Alors ne le fais pas." Laissez cette partie s'hydrater naturellement avec… appuyez sur les fonctions sans serveur et obtenez les données dont elle a besoin, et faites tout cela. Mais le reste du site, qui n'est pas… il n'y a pas autant de pages, il n'y a pas autant de données, vous pourriez faire une sorte de pré-rendu ou quoi que ce soit. Donc un peu des deux.
Drew : Bien sûr, beaucoup de gens ont affaire à des systèmes hérités qui… une ancienne base de données construite dans les années 2000 sur laquelle ils pourraient peut-être coller une sorte de couche API JSON…
Cris : Ouais.
Drew : … et construisez quelque chose de plus moderne, et peut-être sans serveur, puis interagissez toujours avec ces systèmes hérités en les collant d'une manière étrange.
Cris : Ouais. J'aime bien ça, n'est-ce pas ? Ne sont pas… la plupart des sites Web existent déjà. Combien d'entre nous sont des sites Web totalement verts ? La plupart d'entre nous travaillent sur des conneries qui existent déjà et qui doivent être traînées dans le futur pour une raison quelconque, parce que je ne sais pas, les développeurs veulent travailler plus vite, ou vous ne pouvez plus embaucher personne en COBOL, ou peu importe l'histoire est. Vous connaissez?
Drew : Donc, en termes de terminologie, nous parlons de JAMstack, qui est cette méthodologie consistant à exécuter un code à peu près dans le navigateur, en le servant à partir d'un CDN. Donc, ne rien avoir de dynamique sur le serveur. Et puis, lorsque nous parlons de sans serveur, nous parlons de ces petites fonctionnalités qui s'exécutent sur leur serveur ailleurs. Est-ce correct? Que nous parlions de ces fonctions cloud en quelque sorte...
Chris : Ouais, je veux dire, il se trouve que ce sont toutes les deux des idées brûlantes en ce moment. Il est donc assez facile de parler de l'un et de parler de l'autre. Mais ils n'ont pas nécessairement besoin d'être ensemble. Vous pouvez exécuter un site JAMstack qui n'a rien à voir avec quoi que ce soit sans serveur. Vous ne faites que le faire, vous venez de pré-construire le site et de l'exécuter, et vous pouvez utiliser sans serveur sans avoir à vous soucier de JAMstack. En fait, CodePen ne fait rien du tout à JAMstack. Non pas que nous voulions nécessairement parler de CodePen, mais c'est une application Ruby on Rails. Il s'exécute sur tout un tas d'instances AWS EC2 et sur une variété d'autres architectures pour y arriver. Mais nous utilisons des éléments sans serveur chaque fois que nous le pouvons, car c'est bon marché et sécurisé, et c'est juste une bonne façon de travailler. Donc, pas de JAMstack en cours d'utilisation, mais sans serveur partout.
Drew : C'est assez intéressant. À quel type de tâches mettez-vous sans serveur sur CodePen ?
Chris : Eh bien, il y a tout un tas de choses. L'un d'eux est, je pense, j'espère assez évident, j'ai besoin de… le point de CodePen est que vous écrivez chaque HTML, CSS et JavaScript dans le navigateur et il le rend devant vous, n'est-ce pas ? Mais vous pouvez également choisir des langages de pré-processeur. Disons que vous aimez Sass. Vous activez Sass dans le CSS et vous écrivez Sass. Eh bien, quelque chose doit traiter le Sass. Ces jours-ci, Sass est écrit en Dart ou quelque chose comme ça.
Chris : Théoriquement, vous pourriez le faire dans le client. Mais ces bibliothèques qui font du pré-traitement sont assez grosses. Je ne pense pas que je veuille vous expédier toute la bibliothèque Sass, juste pour faire fonctionner ce truc. Je ne veux pas… c'est juste que non, ce n'est pas forcément la bonne architecture pour ça. Peut-être que c'est sur la route, je veux dire, nous pourrions parler de conneries hors ligne, yada, yada, Web Workers. Il y a un million de choses architecturales que nous pourrions faire. Mais voici comment cela fonctionne maintenant, s'il y a un lambda. Il traite Sass. Il a un tout petit, tout petit, tout petit, tout petit boulot.
Chris : Vous lui envoyez ce blob de Sass et il vous renvoie des trucs, c'est-à-dire le CSS traité, peut-être un plan du site, peu importe. Il a un tout petit travail et nous payons probablement pour ce lambda, comme quatre cents ou quelque chose comme ça. Parce que les lambdas sont incroyablement bon marché et que vous pouvez aussi les marteler. Vous n'avez pas à vous soucier de l'échelle. Vous venez de toucher ce truc autant que vous le souhaitez et votre facture sera étonnamment bon marché. Il y a des moments où le sans serveur commence à franchir cette ligne d'être trop cher. Je ne sais pas ce que c'est, je ne suis pas ce maître des trucs comme ça. Mais en général, tout ce que nous faisons sans serveur, nous… sommes presque tous considérés comme gratuits, car c'est si bon marché. Mais il y en a un pour Sass. Il y en a un pour Moins. Il y en a un pour Babbel. Il y en a un pour TypeScript. Il y en a un pour… Ce sont tous des lambdas individuels que nous gérons. Voici du code, donnez-le au lambda, il revient, et nous faisons ce que nous voulons en faire. Mais nous l'utilisons pour bien plus que cela, même récemment.
Chris : Voici un exemple. Chaque stylo sur CodePen a une capture d'écran. C'est plutôt cool, non ? Donc, les gens font quelque chose et ensuite nous avons besoin d'un PNG ou d'un JPEG, ou quelque chose comme ça, pour que nous puissions… de cette façon, quand vous le tweetez, vous en obtenez un petit aperçu. Si vous le partagez dans Slack, vous en obtenez un petit aperçu. Nous l'utilisons sur le site Web lui-même pour rendre… au lieu d'une iframe, si nous pouvions détecter que le Pen n'est pas animé, car l'image d'une iframe est beaucoup plus claire, alors pourquoi ne pas utiliser l'image ? Ce n'est pas animé de toute façon. Juste des gains de performances comme ça. Donc, chacune de ces captures d'écran a une URL, évidemment. Et nous l'avons conçu pour que cette URL soit en fait une fonction sans serveur. C'est un ouvrier. Et donc, si cette URL est atteinte, nous pouvons très rapidement vérifier si nous avons déjà pris cette capture d'écran ou non.
Chris : C'est en fait activé par CloudFlare Workers, car CloudFlare Workers n'est pas seulement une fonction sans serveur, mais ils ont aussi un magasin de données. Ils ont ce truc appelé magasin clé-valeur, donc l'ID de cela, nous pouvons juste vérifier très rapidement et ce sera, "Vrai ou faux, l'avez-vous ou non?" S'il l'a, il le sert. Et il le sert sur CloudFlare, qui est super rapide pour commencer. Et puis vous donne toute cette capacité aussi. Comme il s'agit d'un CDN d'images, vous pouvez dire : « Eh bien, servez-le dans le format optimal. Servez-le comme ces dimensions. Je n'ai pas à faire l'image dans ces dimensions. Vous venez de mettre les dimensions dans l'URL et cela revient comme par magie. Alors c'est vraiment sympa. S'il ne l'a pas, il demande une autre fonction sans serveur pour le rendre vraiment rapide. Donc ça va le faire et ensuite ça va le mettre dans un seau quelque part… parce que vous devez avoir une origine pour l'image, n'est-ce pas ? Vous devez généralement l'héberger quelque part. Nous l'avons donc mis dans un seau S3 très rapidement, puis nous le servons.
Chris : Donc, il n'y a pas de serveur de file d'attente, il n'y a rien. C'est comme si des fonctions sans serveur géraient la création, le stockage et le service de ces images. Et il y en a 50 ou 80 millions ou quelque chose comme ça. C'est beaucoup, donc il gère assez bien cette échelle. Nous n'y touchons même pas. Cela arrive tout simplement. Tout se passe super vite. Super sympa.
Drew : Je suppose que… eh bien, une fonction sans serveur conviendra idéalement à une tâche qui nécessite très peu de connaissances sur l'état des choses. Je veux dire, vous avez mentionné la capacité de CloudFlare à stocker des paires clé-valeur pour voir si vous avez déjà quelque chose en cache ou non.
Cris : Ouais. C'est ce qu'ils essaient de résoudre, cependant, avec ceux-là. Ces paires clé-valeur, c'est que… Je pense que c'était traditionnellement vrai. Ils sont comme, "Évitez l'état dans la chose", parce que vous ne pouvez tout simplement pas compter dessus. Et les travailleurs de CloudFlare disent: "Ouais, en fait, vous pouvez gérer l'état, dans une certaine mesure." Ce n'est pas aussi sophistiqué qu'un… Je ne sais pas, ce sont des valeurs clés, donc c'est une clé dans une valeur. Ce n'est pas comme une fantaisie relationnelle imbriquée. Il y a donc probablement des limites à cela. Mais ce sont des jours de bébé pour cela. Je pense que ce truc va évoluer pour être plus puissant, donc vous avez une certaine capacité à faire des trucs de type étatique.
Drew : Et parfois, la limitation, cette sorte de capacité limitée à maintenir l'état, ou le fait que vous n'avez pas... vous ne voulez maintenir aucun état du tout, vous pousse en quelque sorte dans une architecture qui vous donne ce genre de... Eh bien, quand nous parlons de la philosophie logicielle de "Small Pieces Loosely Joined", n'est-ce pas ?
Chris : Mm (affirmatif).
Drew : Où chaque petit composant fait une chose et le fait bien. Et ne connaît pas vraiment le reste de l'écosystème qui l'entoure. Et il semble que cela s'applique vraiment à ce concept de fonctions sans serveur. Êtes-vous d'accord?
Cris : Ouais. Je pense que vous pourriez avoir un débat philosophique, que ce soit une bonne idée ou non. Vous connaissez? Je pense que certaines personnes aiment le monolithe, pour ainsi dire. Je pense qu'il est possible… il y a des moyens d'en faire trop et de créer trop de petites pièces trop difficiles à tester. C'est bien d'avoir un test du genre : « Oh, je me demande si ma fonction Sass fonctionne. Eh bien, écrivons juste un petit test pour cela et assurons-nous que c'est le cas. Mais disons que ce qui compte pour l'utilisateur, c'est une série de sept d'entre eux. Comment les testez-vous tous les sept ensemble? Je pense que cette histoire devient un peu plus compliquée. Je ne sais pas comment parler super intelligemment de tout ça, mais je sais que ce n'est pas nécessairement ça, si vous roulez avec toutes les fonctions sans serveur, c'est automatiquement une meilleure architecture que toute autre architecture. Je l'aime bien. Cela me raisonne bien, mais je ne sais pas si c'est la fin de toutes les architectures. Vous connaissez?
Drew : Pour moi, cela ressemble beaucoup au Web, dans la mesure où... c'est exactement comme ça que HTML fonctionne, n'est-ce pas ? Vous livrez du HTML et le navigateur ira alors chercher vos images et cherchera votre JavaScript et cherchera votre CSS. Il semble que ce soit une extension de cela -
Chris : C'est sympa.
Drew : … une sorte d'idée. Mais, une chose que nous savons sur le Web, c'est qu'il est conçu pour être résilient parce que le réseau est fragile.
Chris : Mm (affirmatif).
Drew : Quelle est la robustesse du type d'approche sans serveur ? Que se passe-t-il si quelque chose… si l'un de ces petits morceaux s'en va ?
Chris : Ce serait très mauvais. Vous connaissez? Ce serait un désastre. Votre site tomberait en panne comme n'importe quel autre serveur, s'il devait tomber en panne, je suppose.
Drew : Existe-t-il des moyens d'atténuer cela, qui sont particulièrement...
Cris : Je ne sais pas.
Drew : … adapté à ce genre d'approche, que vous avez rencontré ?
Cris : Peut-être. Je veux dire, comme je l'ai dit, une chose robuste vraiment super fantaisiste pourrait être comme… disons que vous visitez CodePen et disons qu'il y a une implémentation JavaScript de Sass et nous avons remarqué que vous êtes sur un réseau assez rapide et que vous êtes inactif à l'heure actuelle. Peut-être allons-nous récupérer ce JavaScript et le lancer dans un service worker. Ensuite, si nous détectons que le lambda échoue, ou quelque chose, ou que vous avez déjà installé ce truc, alors nous frapperons le service worker au lieu du lambda, et les service workers pourront travailler hors ligne. Donc, c'est plutôt sympa aussi. C'est intéressant. Je veux dire, ils sont de la même langue. Les Service Workers sont JavaScript et beaucoup de fonctions Cloud sont JavaScript, donc il y a quelques... Je pense que c'est une possibilité, bien que... c'est juste, c'est une technique sérieuse qui... Cela me fait juste peur d'avoir ce morceau de JavaScript que vous avez livré à combien de milliers d'utilisateurs, que vous ne savez pas nécessairement ce qu'ils ont, et quelle version ils ont. Eww, mais c'est juste ma propre peur. Je suis sûr que certaines personnes ont fait du bon travail avec ce genre de chose.
Chris : En fait, je ne sais pas. Peut-être connaissez-vous des stratégies que je ne connais pas, sur la résilience du sans serveur.
Drew : Je suppose qu'il existe un mode d'échec, un style d'échec, qui pourrait se produire avec des fonctions sans serveur, où vous exécutez une fonction une fois et elle échoue, et vous pouvez l'exécuter une deuxième fois immédiatement après et elle réussirait, car elle pourrait frapper un serveur complètement différent. Ou quel que soit le problème, lorsque cette exécution peut ne pas exister sur une deuxième demande. Les problèmes d'un hôte entier en panne sont une chose, mais peut-être qu'il y a… vous avez des problèmes individuels avec la machine. Vous avez un serveur particulier où sa mémoire est défectueuse, et il génère une charge d'erreurs, et la première fois que vous le touchez, il va échouer. La deuxième fois, ce problème aurait pu être enraciné.
Chris : Les entreprises qui ont tendance à proposer cette technologie, il faut leur faire confiance, mais il se trouve aussi que c'est le genre d'entreprises qui… c'est leur fierté. C'est la raison pour laquelle les gens les utilisent parce qu'ils sont fiables. Je suis sûr que les gens pourraient signaler certaines pannes AWS du passé, mais elles ont tendance à être un peu rares et pas très courantes. Si vous hébergez votre propre merde, je parie qu'ils vous ont battu à partir d'un pourcentage de niveau SLA. Vous connaissez? Donc, ce n'est pas comme "Ne construisez pas de manière résiliente", mais généralement, le type d'entreprises qui offrent ces choses est sacrément fiable. Les chances que vous tombiez en panne parce que vous avez foiré cette fonction sont beaucoup plus élevées que parce que leur architecture est défaillante.
Drew : Je suppose, je veux dire, comme tout ce qui utilise une API ou quelque chose qui peut échouer, s'assurer de structurer votre code pour faire face à ce mode d'échec, et savoir ce qui se passe ensuite, plutôt que de simplement jeter jusqu'à une erreur à l'utilisateur, ou tout simplement en train de mourir, ou ce que vous avez. Il s'agit d'en être conscient et de demander à l'utilisateur de réessayer. Ou réessayez vous-même, ou quelque chose comme ça.
Chris : Ouais, j'aime cette idée d'essayer plus d'une fois, plutôt que de simplement dire « Oh non. Échouer. Avorter." « Je ne sais pas, pourquoi n'essaies-tu pas encore là, mon pote ? »
Drew : Donc, je veux dire, lorsqu'il s'agit de tester et de développer des fonctions sans serveur, une sorte de fonctions cloud, est-ce quelque chose qui peut être fait localement ? Faut-il le faire dans le cloud ? Existe-t-il des moyens de gérer cela ?
Chris : Je pense qu'il y a plusieurs façons. Je ne sais pas si l'histoire est aussi géniale. C'est encore un concept relativement nouveau, donc je pense que ça va de mieux en mieux. Mais d'après ce que je sais, d'une part, vous écrivez une fonction Node assez normale. En supposant que vous utilisiez JavaScript pour ce faire, et je sais que sur Lambda en particulier, ils prennent en charge toutes sortes de choses. Vous pouvez écrire une super fonction PHP Cloud. Vous pouvez écrire une fonction Ruby Cloud. Donc, je sais que je parle spécifiquement de JavaScript, car j'ai le sentiment que la plupart de ces choses sont du JavaScript. Même quelle que soit la langue, je veux dire, vous pouvez accéder à votre ligne de commande localement et exécuter la chose. Certains de ces tests sont… vous le testez simplement comme vous le feriez pour n'importe quel autre code. Vous appelez simplement la fonction localement et voyez si cela fonctionne.
Chris : C'est une histoire un peu différente lorsque vous parlez d'une requête HTTP, c'est ce que vous essayez de tester. Répond-il correctement à la demande ? Et est-ce qu'il renvoie les choses correctement? Je ne sais pas. Le réseau pourrait s'en mêler. Vous voudrez peut-être écrire des tests à ce niveau. C'est très bien. Je ne sais pas. Quelle est l'histoire normale là-bas? Vous lancez une sorte de serveur local ou quelque chose qui le sert. Utilisez Postman, je ne sais pas. Mais il y a… Les frameworks essaient aussi d'aider. Je sais que le ".com" sans serveur est terriblement déroutant, mais il existe littéralement une société appelée Serverless et ils créent un cadre pour écrire les fonctions sans serveur qui vous aident à les déployer.
Chris : Donc, si vous aimez l'installation de NPM sans serveur, vous obtenez leur framework. Et c'est largement considéré comme très bon, parce que c'est juste très utile, mais ils n'ont pas leur propre cloud ou quoi que ce soit. Vous les écrivez, puis cela vous aide à les amener à un vrai lambda. Ou cela peut fonctionner avec plusieurs fournisseurs de cloud. Je ne sais même pas ces jours-ci, mais leur but d'exister est de faciliter l'histoire du déploiement. Je ne sais pas quoi… AWS n'est pas réputé pour sa simplicité. Vous connaissez? Il existe tout ce monde d'outils pour vous aider à utiliser AWS et ils en font partie.
Chris : Ils ont une sorte de produit payant. Je ne sais même pas ce que c'est exactement. Je pense qu'une des choses qu'ils font est… le but de leur utilisation est pour les tests, c'est d'avoir un environnement de développement qui sert à tester votre fonction sans serveur.
Drew : Ouais, parce que je suppose que c'est une partie assez importante du flux de travail, n'est-ce pas ? Si vous avez écrit votre fonction JavaScript, que vous l'avez testée localement, vous savez qu'elle fera l'affaire. How do you actually pick which provider it's going to go into and how do you get it onto that service? Now, I mean, that's a minefield, isn't it?
Cris : Ouais. I mean, if you want to use no tooling at all, I think they have a really… like AWS, specifically, has a really rudimentary GUI for the thing. You can paste the code in there and hit save and be like, “Okay, I guess it's live now.” That's not the best dev story, but I think you could do it that way. I know CloudFlare workers have this thing called Wrangler that you install locally. You spin it up and it spins up a fake browser on the top and then dev tools below. Then you can visit the URL and it somehow intercepts that and runs your local cloud function against it. Because one of the interesting things about workers is… you know how I described how it… you don't hit a URL and then it returns stuff. It just automatically runs when you… when it intercepts the URL, like CDN style.
Chris: So, one of the things it can do is manipulate the HTML on the way through. The worker, it has access to the complete HTML document. They have a jQuery-esque thing that's like, “Look for this selector. Get the content from it. Replace it with this content. And then continue the request.” So you can mess with code on the way through it. To test that locally, you're using their little Wrangler tool thing to do that. Also, I think the way we did it was… it's also a little dangerous. The second you put it live, it's affecting all your web traffic. It's kind of a big deal. You don't want to screw up a worker. Vous connaissez? You can spin up a dev worker that's at a fake subdomain, and because it's CloudFlare, you can… CloudFlare can just make a subdomain anyway. Je ne sais pas. It's just kind of a nice way to do a… as you're only affecting sub-domain traffic, not your main traffic yet. But the subdomain's just a mirror of a production anyway, so that's kind of a… that's a testing story there.
Chris: It brings up an interesting thing, though, to me. It's like… imagine you have two websites. One of them is… for us it's like a Ruby on Rails app. Peu importe. C'est une chose. But we don't have a CMS for that. That's just like… it's not a CMS, really. I think there's probably Ruby CMSs, but there's not any renowned ones. Vous connaissez? It seems like all the good CMSs are PHP, for some reason. So, you want a quality CMS. Drew, you've lived in the CMS market for a long time -
Drew: Absolutely.
Chris: … so you know how this goes. Let's say you want to manage your sites in Perch or whatever, because it's a good CMS and that's the proper thing to use to build the kind of pages you want to build. But you don't want to run them on the same server. Unless you want to manage the pages on one site, but show them on another site. Well, I don't know, there's any number of ways to do that. But one JavaScript way could be, “Okay, load the page. There's an empty div there. Run some JavaScript. Ask the other site for the content of that page and then plunk it out on the new page.” That's fine, I guess, but now you're in a client side rendered page. It's going to be slow. It's going to have bad SEO, because… Google will see it eventually, but it takes 10 days or something. It's just a bad story for SEO. It's not very resilient, because who knows what's going to happen in the network. It's not the greatest way to do this kind of “content elsewhere, content on site B, show page of site A”, situation.
Chris: You could also do it on the server side, though. Let's say you had… Ruby is capable of granting a network request too, but that's even scarier because then if something fails on the network, the whole page could die or something. It's like a nervous thing. I don't love doing that either. But we did this just recently with a worker, in that we… because the worker's JavaScript, it can make a fetch request. So, it fetches site A, it finds this div on the page, and then it goes and asks site B for the content. Gets the content. Plugs it into that div, and serves the page before it gets anything. So it looks like a server rendered page, but it wasn't. It all happened at the… on the edge, at the worker level, at the serverless level.
Chris: So it's kind of cool. I think you can imagine a fetch request on the browser probably takes, I don't know, a second and a half or something. It probably takes a minute to do it. But because these are… site B is hosted on some nice hosting and Cloudflare has some… who knows what kind of super computers they use to do it. They do. Those are just two servers talking to each other, and that fetch request happens just so super duper, duper fast. It's not limited to the internet connection speed of the user, so that little request takes like two milliseconds to get that data. So it's kind of this cool way to stitch together a site from multiple sources and have it feel like, and behave like, a server rendered page. I think there's a cool future to that.
Drew: Are there any sort of conventions that are sort of springing up around serverless stuff. I'm sort of thinking about how to architect things. Say I've got something where I want to do two sort of requests to different APIs. I want to take in a postal address and geocode it against one, and then take those coordinates and send that to a florist who's going to flower bomb my front yard or something. How would you build that? Would you do two separate things? Or would you turn that into one function and just make the request once from the browser?
Chris: Mm (affirmative). That's a fascinating question. I'd probably have an architect function or something. One function would be the one that's in charge of orchestrating the rest of them. It doesn't have to be, your website is the hub and it only communicates to this array of single sources. Serverless functions can talk to other serverless functions. So I think that's somewhat common to have kind of an orchestrator function that makes the different calls and stitches them together, and returns them as one. I think that is probably smart and faster, because you want servers talking to servers, not the client talking to a whole bunch of servers. If it can make one request and get everything that it needs, I think that's probably generally a good idea-
Drew: Yeah, that sounds smart. Ouais.
Chris: But I think that's the ultimate thing. You get a bunch of server nerds talking, they'll talk about the different approaches to that exact idea in 10 different ways.
Drew : Ouais. No, that sounds pretty smart. I mean, you mentioned as well that this approach is ideal if you're using APIs where you've got secret information. You've got API keys or something that you don't want to live in the client. Because I don't know, maybe this florist API charges you $100 dollars every time flower bomb someone.
Chris: Easily.
Drew: You can basically use those functions to almost proxy the request and add in the secret information as it goes, and keep it secret. That's a viable way to work?
Chris: Yeah, yeah. I think so. I mean, secrets are, I don't know, they're interesting. They're a form of buy in I think to whatever provider you go with, because… I think largely because of source control. It's kind of like, you could just put your API key right in the serverless function, because it's just going to a server, right? You don't even have to abstract it, really. The client will never see that code that executes, but in order for it to get there, there's probably a source control along the way. It's probably like you commit to master, and then master… then some kind of deployment happens that makes that thing go to the serverless function. Then you can't put your API key in there, because then it's in the repo, and you don't put your API keys in repos. That's good advice. Now there's stuff. We've just done… at CodePen recently, we started using this git-crypt thing, which is an interesting way to put keys safely into your repos, because it's encrypted by the time anybody's looking at that file.
Chris: But only locally they're decrypted, so they're useful. So it's just kind of an interesting idea. I don't know if that helps in this case, but usually, cloud providers of these things have a web interface that's, “Put your API keys here, and we'll make them available at runtime of that function.” Then it kind of locks… it doesn't lock you in forever but it kind of is… it's not as easy to move, because all your keys are… you put in some input field and some admin interface somewhere.
Drew: Yeah, I think that's the way that Netlify manage it.
Chris: They all do, you know?
Drew : Ouais. You have the secret environment variables that you can set from the web interface. That seems to work quite nicely.
Chris: Yeah, right. But then you got to leave… I don't know, it's not that big of a deal. I'm not saying they're doing anything nefarious or anything. How do you deal with those secrets? Well, it's a hard problem. So they kind of booted it to, I don't know, “Just put them in this input field and we'll take care of it for you, don't worry about it.”
Drew: Is there anything that you've seen that stands out as an obvious case for things that you can do with serverless, that you just couldn't do with a traditional kind of serverfull approach? Or is it just taking that code and sort of almost deploying it in a different way?
Chris: It's probably mostly that. I don't know that it unlocks any possibility that you just absolutely couldn't run it any other way. Yeah, I think that's a fair answer, but it does kind of commoditize it in an interesting way. Like, if somebody writes a really nice serverless function… I don't know that this exists quite yet, but there could kind of a marketplace, almost, for these functions. Like, I want a really good serverless function that can take a screenshot. That could be an open source project that lots of eyeballs around, that does a tremendously good job of doing it and solves all these weird edge cases. That's the one I want to use. I think that's kind of cool. Vous connaissez? That you can kind of benefit from other people's experience in that way. I think that will happen more and more.
Drew: I guess it's the benefit that we talked about, right at the top, of enabling people who write JavaScript and may have written JavaScript only for the front-end, to expand and use those skills on the back-end as well.
Cris : Ouais, ouais. Je pense que oui, je pense que c'est… parce qu'il y a des moments comme… vous n'avez pas besoin d'être extrêmement compétent pour savoir ce qui est approprié et ce qui ne l'est pas pour un site Web. Par exemple, j'ai fait un petit tutoriel l'autre semaine, où il y avait ce problème qui utilise ces… lorsque vous enregistrez un problème, ils vous donnent un slug pour votre truc que vous avez construit, c'est-à-dire « Whisky, tango, foxtrot. 1 000. » C'est comme une petite chose intelligente. Les chances qu'il soit unique sont très élevées, car je pense qu'ils y ajoutent même un numéro ou quelque chose comme ça. Mais ils finissent par être ces petites choses amusantes. Ils ouvrent leur bibliothèque qui contient tous ces mots, mais c'est comme une centaine, des milliers de mots. Le dossier est énorme. Vous connaissez? Il s'agit de mégaoctets d'un simple dictionnaire de mots. Vous avez probablement appris au cours de votre première année de développement : "N'expédiez pas un fichier JavaScript qui représente des mégaoctets d'un dictionnaire." Ce n'est pas une bonne chose à expédier. Vous connaissez? Mais Node s'en fiche. Vous pouvez en expédier des centaines. Cela n'a aucune incidence sur la vitesse d'un serveur.
Drew : Ouais.
Chris : Cela n'a pas d'importance sur un serveur. Donc, je pourrais dire: "Hmm, eh bien, je vais le faire dans Node alors." J'aurai une déclaration qui dit: «Les mots égaux nécessitent des mots», ou autre chose, et une note en haut, «Faites-lui randomiser un nombre. Retirez-le du tableau et renvoyez-le. Ainsi, cette fonction sans serveur est constituée de huit lignes de code avec un packaged@JSON qui extrait cette bibliothèque open source. Et puis mon code frontal, il y a une URL vers la fonction sans serveur. Il atteint cette URL. L'URL renvoie un mot ou un groupe de mots ou autre. Vous construisez votre propre petite API pour cela. Et maintenant, j'ai un truc vraiment sympa et efficace. Ce qui était bien, c'est que c'est si simple. Je ne m'inquiète pas pour la sécurité de celui-ci. Je ne… tu sais ?
Chris : C'est juste que… un développeur JavaScript très moyen ou débutant, je pense, peut réussir ça, ce qui est cool. C'est une chose habilitante qu'ils n'avaient pas auparavant. Avant, ils disaient : "Eh bien, voici un tableau de mots de 2 Mo." "Oh, je ne peux pas expédier ça au client." "Oh, tu vas juste fermer alors." Vous pourriez vous heurter à ce mur du genre : « Je ne peux tout simplement pas faire cette partie alors. J'ai besoin de demander à quelqu'un d'autre de m'aider avec ça ou simplement de ne pas le faire ou de choisir des limaces plus ennuyeuses ou quelque chose comme ça… » C'est juste que vous devez emprunter une autre voie qui est un mur pour vous, parce que vous ne pouvez pas le faire. Et maintenant, vous êtes, "Oh, eh bien, je vais juste ..." Au lieu d'avoir cela dans mon script slash, ou dans mon dossier de scripts slash source, je vais le mettre dans mon dossier de fonctions à la place.
Chris : Vous avez en quelque sorte déplacé le script d'un dossier à l'autre. Et celui-ci est déployé en tant que fonction sans serveur à la place. À quel point cela est cool? Vous connaissez? Vous utilisez exactement le même ensemble de compétences, presque. Il y a encore quelques aspérités, mais c'est assez proche.
Drew : C'est super cool. Vous avez monté une sorte de petit micro site sur ces idées, n'est-ce pas ?
Cris : Ouais. J'étais un peu en avance sur le match. J'y travaillais juste aujourd'hui, cependant, parce que… il reçoit des demandes d'extraction. L'idée… eh bien, c'est sur serverless.css-tricks.com et… il y a un tiret dans CSS-Tricks, au fait. C'est donc un sous-domaine de CSS-Tricks, et je l'ai également construit sans serveur, donc c'est… CSS-Tricks est comme un site WordPress, mais c'est un site générateur de site statique. Tout son contenu se trouve dans le repo GitHub, qui est open-source. Donc, si vous souhaitez modifier le contenu du site, vous pouvez simplement soumettre une demande de sondage, ce qui est bien car il y en a eu une centaine au fil du temps. Mais j'ai construit tout le contenu original.
Drew : C'est un endroit super utile, parce qu'il répertorie... Si vous pensez, "Bien, je veux commencer avec des fonctions sans serveur", il répertorie tous les fournisseurs que vous pourriez essayer et...
Chris : C'est tout ce que c'est, à peu près, ce sont des listes de technologies. Ouais.
Drew : Ce qui est formidable, car sinon, vous ne faites que rechercher n'importe quoi sur Google et vous ne savez pas ce que vous trouvez. Oui, ce sont des listes de fournisseurs d'API qui vous aident à faire ce genre de choses.
Chris : Forms en est un exemple, parce que… donc à la minute où vous choisissez de… disons, vous allez utiliser JAMstack, ce qui, je sais, n'est pas nécessairement le but, mais vous voyez à quel point ils sont main dans la main. . Tout d'un coup, vous n'avez plus de fichier PHP ou quoi que ce soit pour traiter ce formulaire. Comment faire des formulaires sur un site JAMstack ? Eh bien, il y a plusieurs façons de le faire. Tout le monde et leur sœur veulent vous aider à résoudre ce problème, apparemment. Donc je pense que si j'étais l'inventeur du mot JAMstack, alors ils essaient de vous aider naturellement, mais vous n'êtes pas obligé de les utiliser.
Chris : En fait, j'ai été tellement surpris de créer ce site. Voyons voir. Il y a six, neuf, douze, quinze, dix-huit, vingt et un, vingt-deux services qui veulent vous aider à traiter vos formulaires sans serveur sur ce site en ce moment. Si vous voulez être le 23e, vous êtes le bienvenu, mais vous avez de la concurrence. Donc, l'idée derrière cela est que vous écrivez un formulaire en HTML, comme littéralement un élément de formulaire. Et puis l'attribut action du formulaire, il ne peut pointer nulle part en interne, car il n'y a rien à pointer. Vous ne pouvez pas traiter, donc il pointe vers l'extérieur. Il pointe vers tout ce vers quoi ils veulent que vous le pointiez. Ils traiteront le formulaire, puis ils auront tendance à faire des choses que vous attendez d'eux, comme envoyer une notification par e-mail. Ou envoyer un truc Slack. Ou alors envoyez-le à Zapier et Zapier l'enverra ailleurs. Ils ont tous des ensembles de fonctionnalités, des prix et des choses légèrement différents, mais ils essaient tous de résoudre ce problème pour vous, du genre « Vous ne voulez pas traiter vos propres formulaires ? Aucun problème. Nous le traiterons pour vous.
Drew : Ouais, c'est une ressource super utile. Je recommanderais vraiment à tout le monde de le vérifier. C'est serverless.css-tricks.com. Donc, j'ai tout appris sur le sans serveur. Qu'as-tu appris dernièrement, Chris ?
Chris: Eh bien, je suis toujours très présent dans ce monde et j'apprends des trucs sans serveur. J'ai eu une idée de… J'avais l'habitude de jouer à ce jeu de rôle en ligne il y a très longtemps. Je viens de découvrir récemment qu'il est toujours en vie. C'est un genre de jeu médiéval fantastique basé sur du texte. J'y ai joué quand AOL était une chose, parce qu'AOL voulait avoir ces jeux auxquels vous deviez être connecté pour y jouer, parce qu'ils voulaient que vous passiez des heures et des heures sur AOL, afin qu'ils puissent vous envoyer ces énormes factures, ce qui était , je suis sûr, pourquoi ils ont si bien réussi à un moment donné.
Drew : Donc facturation à la seconde. Ouais.
Cris : Ouais. Donc, les jeux étaient importants pour eux. S'ils pouvaient vous faire jouer à des jeux avec d'autres personnes là-bas. Donc ce jeu en quelque sorte… il n'a pas fait ses débuts là-bas, mais il a déménagé sur AOL, parce que je suis sûr qu'ils ont obtenu une bonne affaire pour ça, mais c'était tellement… je veux dire, c'est juste, ça ne pourrait pas être plus ringard. Vous êtes un mage nain et vous obtenez un bâton runique dans votre étui en cuir. Et vous y tapez des commandes comme un terminal. Ensuite, le jeu vous répond. J'ai joué à ce jeu pendant très longtemps. J'étais très dedans. Je suis entré dans la communauté de celui-ci et dans son esprit. C'était une sorte de… c'était comme si j'étais seul devant mon ordinateur, mais pourtant je repense à cette période de ma vie et je me dis : « C'était une période merveilleuse de ma vie. J'étais vraiment… J'ai juste aimé les gens et le jeu et tout ça. Mais ensuite j'ai grandi et j'ai arrêté d'y jouer, parce que la vie vous arrive.
Chris : Je ne l'ai découvert que récemment, parce que quelqu'un a recommencé à faire un podcast à ce sujet… Je ne sais pas comment je suis tombé dessus, mais je viens de le faire. Je me suis dit : « Ce jeu est bel et bien vivant dans le monde d'aujourd'hui, vous vous moquez de moi ? Ce truc basé sur du texte. Et j'étais plus qu'heureux de réactiver et de récupérer mes anciens personnages et d'y jouer. Mais seulement pour découvrir que les clients qu'ils vous ont téléchargés pour ce jeu n'ont pas du tout évolué. Ils sont horribles. Ils supposent presque que vous utilisez Windows. Il y a juste ces rendus terriblement ringards… et c'est basé sur du texte, vous pensez qu'il aurait au moins une belle typographie. Non. Alors je me dis : « Je pourrais être impliqué. Je pourrais écrire un client pour ce jeu. Mettez-y une belle typographie. Modernisez simplement la chose, et je pense que les joueurs du jeu l'apprécieraient, mais cela m'a semblé écrasant. "Comment puis-je le faire?" Mais je trouve quelques projets open source. L'un d'eux est comme… vous pouvez jouer au jeu via une fenêtre de terminal réelle, et il utilise des bibliothèques open source pour créer une sorte d'interface graphique à partir d'une fenêtre de terminal.
Drew : Vraiment ?
Cris : Je ne sais pas. C'était plutôt cool. Je me disais: «S'ils ont écrit cela, il doit y avoir un code pour se connecter au jeu et tout faire fonctionner et tout. Donc au moins j'ai un code de démarrage. J'essayais de suivre l'application, "Peut-être que je le ferai dans Flutter ou quelque chose comme ça", pour que l'application du produit final fonctionne sur les téléphones mobiles et, "Je pourrais vraiment moderniser cette chose." Mais ensuite j'ai été submergé. Je me suis dit : « Ah, c'est trop gros… je ne peux pas. Je suis occupé." Mais j'ai trouvé une autre personne qui avait la même idée et qui était bien plus avancée, donc je pouvais simplement contribuer au niveau de la conception. Et c'était vraiment amusant de travailler dessus, mais j'ai beaucoup appris aussi, parce que c'est rare pour moi de me lancer dans un projet qui est le bébé de quelqu'un d'autre, et je contribue juste un peu, et c'est totalement différent choix technologiques que je n'aurais jamais choisis.
Chris : C'est une application Electron. Ils ont choisi cela, ce qui est aussi une manière plutôt cool de procéder, car ce sont mes compétences Web… donc je n'apprends rien de trop bizarre, et c'est multiplateforme, ce qui est génial. Donc, j'ai beaucoup appris sur Electron. Je pense que c'est amusant.
Drew : C'est fascinant. C'est toujours incroyable de voir comment les petits projets parallèles et les choses que nous faisons pour le plaisir finissent par être l'endroit où nous apprenons parfois le plus. Et acquérir des compétences qui peuvent ensuite être réinjectées dans notre type de travail quotidien.
Chris : C'est la seule façon d'apprendre des choses. Je suis entraîné dans quelque chose qui… Je me suis dit : « Ils ne sont pas… » C'est rendu avec une bibliothèque JavaScript appelée Mithril, qui est… Je ne sais pas si vous en avez déjà entendu parler, mais c'est bizarre. Ce n'est pas… c'est presque comme écrire React sans JSX. Vous devez "créer un élément" et faire tout cela… mais c'est censé être bien meilleur que ça… Et c'est en fait assez important parce que dans ce jeu basé sur du texte, le texte vole. Il y a beaucoup de manipulation de données, c'est comme si... on pourrait penser que ce jeu basé sur du texte serait si facile à exécuter pour une fenêtre de navigateur, mais ce n'est en fait pas le cas. Il y a tellement de manipulations de données qui se produisent, qu'il faut vraiment être vraiment… nous devons être consciencieux quant à la vitesse du rendu. Vous connaissez?
Drew : C'est fascinant...
Chris : Plutôt cool.
Drew : Ouais. Si vous, cher auditeur, souhaitez en savoir plus sur Chris, vous pouvez le trouver sur Twitter, où il est @chriscoyier. Bien sûr, CSS-Tricks peut être trouvé sur css-tricks.com et CodePen sur codepen.io. Mais surtout, je vous recommande de vous abonner au podcast ShopTalk Show si vous ne l'avez pas déjà fait, sur shoptalkshow.com. Merci de vous joindre à nous aujourd'hui, Chris. Avez-vous des mots d'adieu?
Chris : Smashingpodcast.com. J'espère que c'est la vraie URL.