Fermer

août 11, 2020

Qu'estce que sans serveur?


Nous parlons d’architectures sans serveur. Qu'est-ce que cela signifie et en quoi est-ce différent de la façon dont nous pourrions créer des sites actuellement? Drew McLellan s’entretient avec Chris Coyier pour le savoir.

Aujourd'hui, nous parlons d’architectures sans serveur. Qu'est-ce que cela signifie et en quoi est-ce différent de la façon dont nous pourrions créer des sites actuellement? J'ai parlé à Chris Coyier pour le savoir.

Afficher les notes

Mise à jour hebdomadaire

Transcription

 Photo de Chris Coyier Drew McLellan: C'est un concepteur et développeur Web que vous connaissez peut-être. 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-end du monde entier pour partager ce qu'ils font et s'inspirer de ceux qu'ils suivent. Aux côtés de Dave Rupert est le co-animateur de ShopTalk Show, un podcast consacré à 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 restauration de hot-dogs en utilisant uniquement son charme? Mes amis fracassants, veuillez souhaiter la bienvenue à Chris Coyier. Bonjour Chris, comment vas-tu?

Chris Coyier: Hé, je suis en train de casser.

Drew: Je voulais vous parler aujourd'hui pas de CodePen, et je ne veux pas forcément vous parler de CSS-Tricks, qui est l'une de ces ressources incroyables que tout le monde sait, je suis sûr, apparaît tout en haut des résultats de la recherche Google lorsque vous recherchez des réponses à toute 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, je faisais ça. Il y avait un… je ne sais pas, c'était probablement à l'époque où Google avait ce réseau social étrange. Ca c'était quoi? Google Plus?

Drew: Oh, Plus, ouais.

Chris: Ouais, où ils associeraient un site Web à un compte Plus, et donc mon compte Plus avait un avatar et l'avatar c'était moi, donc il apparaîtrait 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-

Chris: 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 de votre part, et c’est ce concept d’architectures sans serveur.

Chris: Mm (affirmatif).

Drew: C'est quelque chose que vous avez été apprendre un peu plus sur pendant un petit moment.

Chris: Ouais, ouais. Je ne suis qu’un fan. Cela semble être un ajustement naturel à l'évolution du développement front-end, où j'ai l'impression d'avoir, au moins, une certaine expertise. Je me considère beaucoup plus comme… 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 petit code Ruby, c’est sûr. Mais je préfère le front-end. Je l’ai plus étudié. J'ai davantage participé à des projets à ce niveau, puis vient ce petit genre de nouveau paradigme qui dit: «Vous pouvez utiliser vos compétences JavaScript sur le serveur», et c'est intéressant. Tu sais? C’est comme ça que j’y pense. Il y a beaucoup plus que cela, mais c'est pourquoi je m'en soucie, c'est parce que je pense que c'est comme si les développeurs frontaux se sont plongés si profondément dans JavaScript. Et maintenant, nous pouvons utiliser ce même ensemble de compétences ailleurs. Mm, 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 la mise en œuvre back-end, tout à coup cela s'ouvre. Et c'est quelque chose que vous pouvez gérer vous-même une plus grande partie de la pile entière.

Chris: Ouais, ouais. C'est tout.

Drew: S'adressant à l'éléphant dans la pièce, juste en haut. Nous parlons de sans serveur et, évidemment, il est difficile de nommer les choses. 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 êtes seulement En entendant le mot "sans serveur" dans les douze premières fois où vous l'avez entendu, il est obligatoire que vous ayez une réaction viscérale et que vous ayez ce genre de "Oh, mais il y a encore des serveurs." C'est bon. Si cela vous arrive en ce moment, sachez que c'est une étape obligatoire à cet égard. C’est comme toute autre chose 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 seulement après une douzaine de fois environ, ou après que cela vous ait un peu prouvé sa valeur, pouvez-vous entrer dans les étapes suivantes. de compréhension 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 est déjà réussi. Vous n'allez pas gagner celui-ci. Alors, 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 penserais 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 met dans le ciel magique et puis… il a une URL, et vous pouvez le frapper et il exécutera cette fonction et retournera quelque chose si vous le souhaitez. Tu sais? C'est juste HTTP ou autre. C’est ainsi que cela fonctionne, qui… la première fois que vous entendez cela, vous vous dites: «Pourquoi? Je m'en fiche. » Mais alors, il y a des choses évidentes à cela. 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, car il connaît des éléments secrets qui ne doivent pas nécessairement ê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: Alors c’est plutôt cool. Je peux écrire une fonction qui parle à une base de données, obtenir des données, les renvoyer. Cool. Donc, Lambda est cela, mais AWS fonctionne. Vous devez choisir une région. Vous vous dites: «Je ne sais pas. Où ça devrait être, Virginie? 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 ces jours-ci, mais même les lambdas avaient des régions. Je pense que ces jours-ci, ils 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 aussi exécuté à un moment différent… comme un worker CloudFlare… c'est similaire à un lambda en ce sens que vous pouvez exécuter Node. Vous pouvez exécuter JavaScript. Vous pouvez utiliser un certain nombre d'autres langages aussi, mais… Je pense à ce truc en grande partie, le langage le plus intéressant est JavaScript, juste à cause de sa prédominance.

Chris: Cela se produit juste 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 manifestement qu'autre chose. Ces derniers temps, il commence à se sentir encore plus sans serveur. Un CDN est-il un serveur? Je veux dire, je suppose que c'est un ordinateur quelque part, mais cela ressemble encore moins à un serveur-y.

Drew: On dirait, oui, qu'un CDN peut être un serveur, mais c'est la plus sorte de version minimale de un serveur. C’est comme un serveur léger, si vous voulez.

Chris: Ouais. Bien sûr.

Drew: Très bien. Je l’ai entendu dire… Je ne me souviens pas de la source à créditer, malheureusement, mais j’ai entendu dire que le serveur sans serveur était décrit comme «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 veut pas dire que vous n’utilisez jamais de voiture.

Chris: Oui, cela ne veut pas dire que les voitures n’existent pas. Mm, c’est bien.

Drew: Vous n’en invoquez qu’un lorsque vous en avez besoin, mais en même temps, vous ne payez pas le prix d’achat initial d’une voiture. Vous ne payez pas d’entretien ou de carburant ou…

Chris: Bien, et le prix a du sens, non? C'est zonte. C’est une belle analogie, je pense. Et puis, comme il est également au niveau du CDN, il intercepte simplement les requêtes HTTP qui se produisent déjà, ce qui signifie que vous ne le demandez pas … vous ne lui envoyez pas de requête et il renvoie une requête. Cela se produit naturellement pendant la requête, ce qui fait que cela se sent moins serveur-y. Je ne sais pas, c’est intéressant. C’est certainement intéressant. 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 également important, car… disons, vous êtes un développeur back-end, qui a l'habitude de faire tourner des serveurs toute sa vie. Et ils font les frais. «J'ai besoin de ce type de serveur avec ce type de mémoire et ce type de CPU et ce genre 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 ça tant que ça, ils ne sont tout simplement pas dedans , comme vos compétences sont exactement ce qu'elles sont au fil des ans, vous comparez le prix et vous vous dites: «Quoi? Je pourrais payer 1% de ce que je payais auparavant? » Vous n'êtes pas autorisé à ne pas vous en soucier, non? Si vous êtes ce développeur back-end qui paie cent fois plus pour son service que ce dont il a besoin, vous êtes simplement un peu mauvais dans votre travail. Désolé de dire. Cela s'est produit et cela a fait exploser 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 collaborateur, ou autre, 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 essaie 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 à sa manière, il n'y a rien là pour obtenir. Donc, la sécurité est également 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. L'exécuter, exécuter certaines choses dans Lambda, vous obtenez juste une sécurité naturelle, ce qui est génial. Donc, c’est beaucoup moins cher. C’est beaucoup plus sûr. Il encourage ces petites architectures modulaires, ce qui peut être une bonne idée. Cela semble être domino après domino de bonnes idées ici. C’est pourquoi c’est remarquable. Vous savez?

Drew: Ouais, 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 exécutez vous-même. Il contient votre code frontal, votre code back-end, votre base de données et tout. Ensuite, vous devez le maintenir, le faire fonctionner et payer les factures, et même s’il n’est pas utilisé, il enregistre les factures. L'utilisateur ferait une demande et il construirait tout ce contenu de requête HTML à partir de la base de données, l'envoyait tout le long de la ligne au navigateur. Ce processus fonctionne. C’est ainsi que se construisent des tas de choses. 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 ça, que nous sommes… que nous devons résoudre, et que le serveur sans serveur pourrait nous aider?

Chris: Ouais, les problèmes avec l'approche de la vieille école. Ouais, 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 ensemble… le tout du jour au lendemain. Je ne sais pas. Peut-être pas vraiment, mais je pense que cela ouvre des portes. Il semble que, lorsque de bonnes idées arrivent comme ça, elles changent lentement le fonctionnement du Web. Donc, s'il existe un CMS qui est 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. Vous avez peut-être l'impression qu'il ne s'agit encore que d'un serveur traditionnel, mais les hôtes eux-mêmes l'ont transformé, comment ils fonctionnent, en architectures sans serveur. Donc, vous ne savez même pas vraiment que cela 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 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 est en train de grandir en même temps que JAMstack. Et JAMstack est cette architecture qui dit: «Vous devriez servir votre site Web sur des 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’exécute pas PHP. Je ne dirige pas Ruby. Je ne cours rien. Je tourne sur un tout petit serveur Web qui est juste conçu pour servir uniquement des fichiers statiques. »

Chris: « Et puis, si vous avez besoin de faire plus que cela, si vous avez besoin d'extraire des données d'une base de données relationnelle, alors faites-le à un autre moment, pas à l'heure 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é-créer 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. Vous le faites donc à l'avance ou après l'heure, mais cela ne signifie pas: «N'utilisez pas de base de données relationnelle». Cela signifie simplement: «Ne laissez pas le serveur le générer au moment de la demande du document», ce qui est… je ne sais pas, c'est un petit 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ù il commence à être un peu plus attendu que la façon dont une application JavaScript démarre, c'est qu'elle monte certains composants, et à mesure que ces composants se montent, elle demande les données dont elle a besoin. Et donc, cela peut être un peu naturel pour quelque chose comme un site Web React comme: «Eh bien, je vais simplement utiliser une fonction sans serveur pour cracher les données dont il a besoin. Cela touche essentiellement une API JSON. J'obtiens les données JSON dont j'ai besoin et je me construis à partir de ces données, puis j'effectue un rendu 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 ainsi que beaucoup de gens construisent des sites. " Il s’agit juste des éléments rendus 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 peuvent être plus traditionnelles et des parties peuvent être sans serveur, je suppose?

Chris: Ouais. Eh bien, ils essaient de vous le dire de toute façon. Quiconque veut vous vendre une partie de son architecture se dit: «Vous n’avez pas à tout acheter pour le moment. Faites-le un peu. Parce que bien sûr, ils veulent que vous plongiez votre orteil dans tout ce qu'ils vendent, car une fois que vous avez plongé l'orteil, les chances que vous vous éclaboussiez dans la piscine sont beaucoup plus élevées. Donc, je pense que… ce n’est pas nécessairement un mensonge, bien que je trouve un peu moins de chance dans… Je ne veux pas que ma pile 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 a un élément de commerce électronique, ce qui signifie … et disons le commerce électronique à grande échelle, donc 10 000 produits ou quelque chose, que cette architecture JAMstack n'est pas arrivée au point où c'est toujours particulièrement efficace pour reconstruire cela de manière statique. Donc, la pensée dit: "Alors non." Laissez cette partie s'hydrater naturellement avec… des 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 en quelque sorte pré-rendre ou autre. Donc un peu des deux.

Drew: Bien sûr, beaucoup de gens ont affaire à des systèmes hérités qui… une vieille base de données qui a été construite dans les années 2000 pour qu'ils puissent coller une sorte d'API JSON couche au-dessus de…

Chris: 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 le collant complètement dans un façon étrange.

Chris: Ouais. J'aime ça, n'est-ce pas? N'est-ce pas… la plupart des sites Web existent déjà. Combien d'entre nous sont des sites Web totalement verts? La plupart d'entre nous travaillons sur des conneries qui existent déjà et qui doivent être entraî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 quelle que soit l'histoire. est. Vous savez?

Drew: Donc, en termes de terminologie, nous parlons de JAMstack qui est cette méthodologie qui consiste à exécuter un code à peu près dans le navigateur, en le diffusant à 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 petits morceaux de fonctionnalités qui s'exécutent sur leur serveur ailleurs. Est-ce correct? Que nous parlions de ces fonctions de cloud en quelque sorte –

Chris: Ouais, je veux dire, il se trouve que ce sont deux sortes d'idées chaudes en ce moment. Il est donc assez facile de parler de l’un et 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, il vous suffit 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 fonctionne sur tout un tas d'instances AWS EC2 et une variété d'autres architectures pour y arriver. Mais nous utilisons des outils sans serveur chaque fois que nous le pouvons pour tout ce que nous pouvons, car il est bon marché et sécurisé, et c'est juste une bonne façon de travailler. Donc, pas de JAMstack utilisé du tout mais sans serveur partout.

Drew: C’est assez intéressant. À quel genre de tâches mettez-vous sans serveur sur CodePen?

Chris: Eh bien, il y a tout un tas de choses. L'une d'elles est, je pense, assez évidente, j'espère, c'est que j'ai besoin … le but de CodePen est que vous écrivez chaque HTML, CSS et JavaScript dans le navigateur et qu'il le rende devant vous, non? 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 pouvez le faire dans le client. Mais ces bibliothèques qui font du prétraitement sont assez grandes. Je ne pense pas que je veuille vous envoyer toute la bibliothèque Sass, juste pour faire fonctionner cette chose. Je ne veux pas… ce n’est tout simplement pas, ce n’est pas nécessairement la bonne architecture pour cela. Peut-être que c'est sur la route, je veux dire, nous pourrions parler de merde hors ligne, yada, yada, Web Workers. Il y a un million de choses architecturales que nous pourrions faire. Mais voici comment cela fonctionne maintenant, y a-t-il un lambda. Il traite Sass. Il a un tout petit, petit, petit, petit travail.

Chris: Vous lui envoyez ce blob de Sass et il vous renvoie des trucs, qui sont le CSS traité, peut-être un plan de 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 le marteler. Vous n’avez pas à vous soucier de l’échelle. Vous venez de frapper ce truc autant que vous le souhaitez et votre facture sera étonnamment bon marché. Il y a des moments où le serveur sans serveur commence à franchir cette ligne de prix trop élevé. Je ne sais pas ce que c’est, je ne suis pas maître des trucs comme ça. Mais en général, tout ce que nous faisons sans serveur, nous comptons tous presque 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 tout ce que nous allons faire avec. Mais nous l’utilisons pour beaucoup 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 une chose et puis nous avons besoin d'un PNG ou d'un JPEG, ou quelque chose de ce genre, pour que nous puissions… de cette façon quand vous le tweetez, vous en avez 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 effectuer le rendu… 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 de toute façon pas animé. Juste des gains de performance 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 travailleur. 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 les CloudFlare Workers ne sont pas simplement une fonction sans serveur, mais ils ont aussi un magasin de données. Ils ont cette chose appelée magasin de valeurs-clés, donc l'ID de cela, nous pouvons simplement 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 via CloudFlare, qui est très rapide au départ. Et puis vous donne aussi toute cette capacité. Comme il s’agit d’un CDN d’image, vous pouvez dire: «Bien, diffusez-le dans le format optimal. Servez-le comme ces dimensions. " Je n’ai pas à créer l’image dans ces dimensions. Vous venez de mettre les dimensions dans l'URL et cela revient à cette taille, comme par magie. Alors c’est vraiment sympa. S'il ne l'a pas, il demande à une autre fonction sans serveur de le rendre vraiment rapide. Donc, il va le faire et ensuite il le mettra dans un seau quelque part… parce que vous devez avoir une origine pour l'image, non? Vous devez généralement l'héberger quelque part. Nous l'avons donc placé dans un compartiment 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 des fonctions sans serveur gèrent la création, le stockage et la diffusion de ces images. Et il y en a environ 50 ou 80 millions ou quelque chose comme ça. C'est beaucoup, donc il gère cela comme une échelle assez bien. Nous n'y touchons même pas. Cela arrive juste. Tout se passe très vite. Super sympa.

Drew: Je suppose que… eh bien, une fonction sans serveur convient 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à mis en cache quelque chose ou non.

Chris: Ouais. C’est pourtant ce qu’ils essaient de résoudre avec ceux-ci. Ces paires clé-valeur, c'est que… Je pense que c'était traditionnellement vrai. Ils disent: "Évitez l'état dans la chose", parce que vous ne pouvez tout simplement pas compter dessus. Et les employés de CloudFlare se 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 un truc de fantaisie relationnel imbriqué. Il y a donc probablement des limites à cela. Mais ce sont des jours de bébé pour ça. Je pense que ce truc va évoluer pour devenir plus puissant, donc vous avez une certaine capacité à faire des trucs semblables à un état.

Drew: Et parfois la limitation, cette sorte de capacité limitée à maintenir l'état, ou le 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?

Chris: Ouais. Je pense que vous pourriez avoir un débat philosophique sur la question de savoir si c’est une bonne idée ou non. Tu sais? Je pense que certaines personnes aiment le monolithe, pour ainsi dire. Je pense qu’il est possible… il existe des moyens d’en faire trop et de fabriquer 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 simplement un petit test et vérifions qu’il l’est. » Mais disons, ce qui compte pour l'utilisateur, c'est une série de sept d'entre eux. Comment testez-vous les sept ensemble? Je pense que cette histoire se complique un peu. Je ne sais pas comment parler très intelligemment de tout cela, mais je sais que ce n’est pas nécessairement cela, si vous utilisez toutes les fonctions sans serveur, c’est automatiquement une meilleure architecture que toute autre architecture. Je l'aime. Cela me raisonne bien, mais je ne sais pas si c'est la fin de toutes les architectures. Vous savez?

Drew: Pour moi, cela ressemble extrêmement au Web, en ce sens que… c'est exactement ainsi que fonctionne le HTML, n'est-ce pas? Vous fournissez du HTML et le navigateur ira ensuite chercher vos images et récupérer votre JavaScript et récupérer votre CSS. On dirait que c’est une extension de ça –

Chris: C’est bien.

Drew: … une sorte d’idée. Mais, une chose que nous savons sur le Web, est-il 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. Tu sais? Ce serait un désastre. Votre site tomberait en panne comme n'importe quel autre serveur, s'il venait à tomber en panne, je suppose.

Drew: Y a-t-il des moyens d'atténuer cela, en particulier –

Chris: I don

Drew: … adapté à ce genre d'approche, que vous avez rencontré?

Chris: Peut-être. Je veux dire, comme je l'ai dit, une chose vraiment super robuste 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 maintenant. Peut-être que nous allons récupérer ce JavaScript et nous le lancerons dans un technicien de service. Ensuite, si nous détectons que le lambda échoue, ou quelque chose, ou que vous avez déjà installé cet élément, nous allons frapper le service worker au lieu du lambda, et les techniciens de service pourront travailler hors connexion. Donc, c’est plutôt bien aussi. C'est intéressant. Je veux dire, ils sont le même langage-ish. Les techniciens de service sont JavaScript et beaucoup de fonctions Cloud sont JavaScript, donc il y en a… Je pense que c'est une possibilité, bien que… c'est juste, c'est une technique sérieuse qui… Cela me fait 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 certaines stratégies que je ne connais pas, sur la résilience du serveur sans serveur.

Drew: Je suppose qu'il y a 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 il échoue, et vous pouvez l'exécuter une deuxième fois immédiatement après et cela réussirait, car il 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. Le problème de la panne d'un hôte entier est une chose, mais peut-être qu'il y a… vous avez des problèmes individuels avec la machine. Vous avez un serveur particulier sur lequel sa mémoire est mauvaise, et il génère un tas d’erreurs, et la première fois que vous le frappez, il échouera. La deuxième fois, ce problème a peut-être été enraciné.

Chris: Les entreprises qui ont tendance à offrir cette technologie, il faut leur faire confiance, mais il se trouve qu'elles sont aussi le type 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ébergiez votre propre merde, je parie qu'ils vous ont battu à partir d'un niveau de pourcentage de SLA. Tu sais? Donc, ce n’est pas du genre «Ne construisez pas de manière résiliente», mais en général, le type d’entreprises qui offrent ces choses est très fiable. Les chances que vous tombiez en panne parce que vous avez bousillé cette fonction sont beaucoup plus élevées que parce que leur architecture échoue.

Drew: Je suppose, je veux dire, comme tout ce qui utilise une API ou quelque chose qui peut échouer, il s'agit simplement de vous assurer que vous structurez votre code pour faire face à ce mode d'échec et de savoir ce qui se passe ensuite, plutôt que de simplement renvoyer une erreur à l'utilisateur, ou simplement de mourir, ou quoi que ce soit d'autre. Il en est conscient et demande à l’utilisateur de réessayer. Ou réessayer vous-même, ou quelque chose comme ça.

Chris: Ouais, j'aime cette idée d'essayer plus d'une fois, plutôt que d'être simplement: «Oh non. Échouer. Avorter." "Je ne sais pas, pourquoi ne réessayez-vous pas là-bas, mon pote?"

Drew: Donc je veux dire, quand il s'agit de tester et de développer des fonctions sans serveur, une sorte de fonctions cloud, est-ce quelque chose cela peut être fait localement? Doit-il être effectué dans le cloud? Y a-t-il des moyens de gérer cela?

Chris: Je pense qu'il y a des moyens. 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 utilisez JavaScript pour ce faire, et je sais que sur Lambda en particulier, ils prennent en charge toutes sortes de choses. Vous pouvez écrire une 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. Il vous suffit d'appeler la fonction localement et de voir si cela fonctionne.

Chris: C'est une histoire un peu différente lorsque vous lui parlez d'une requête HTTP, c'est ce que vous essayez de tester. Répond-il correctement à la demande? Et est-ce que ça renvoie le truc correctement? Je ne sais pas. Le réseau pourrait s'y impliquer. 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… Frameworks essaie aussi d’aider. Je sais que le ".com" sans serveur, qui est tout simplement terriblement déroutant, mais il y a 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 comme NPM install sans serveur, vous obtenez leur cadre. Et c'est largement considéré comme très bon, car c'est tout simplement très utile, mais ils ne disposent pas de leur propre cloud ou autre. Vous les écrivez et 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 objectif d'exister est de faciliter l'histoire du déploiement. Je ne sais pas quoi… AWS n’est pas réputé pour sa simplicité. Tu sais? 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 teste votre fonction sans serveur.

Drew: Ouais, parce que je suppose, c'est assez une grande partie du flux de travail, n'est-ce pas? Si vous avez écrit votre fonction JavaScript, vous l'avez testée localement, vous savez qu'elle fera l'affaire. Comment choisissez-vous réellement le fournisseur auquel il s'adressera et comment le faire accéder à ce service? Maintenant, je veux dire, c’est un champ de mines, n’est-ce pas?

Chris: Ouais. Je veux dire, si vous ne voulez utiliser aucun outil du tout, je pense qu'ils ont vraiment… comme AWS, en particulier, a une interface graphique vraiment rudimentaire pour la chose. Vous pouvez coller le code là-dedans et appuyer sur Enregistrer et dire: "D'accord, je suppose que c'est en ligne maintenant." Ce n’est pas la meilleure histoire de développement, mais je pense que vous pouvez le faire de cette façon. Je sais que les travailleurs CloudFlare ont ce truc appelé Wrangler que vous installez localement. Vous le faites tourner et il fait tourner un faux navigateur en haut, puis les outils de développement ci-dessous. Ensuite, vous pouvez visiter l'URL et elle intercepte en quelque sorte cela et exécute votre fonction de cloud local contre elle. Parce que l'une des choses intéressantes à propos des collaborateurs est… vous savez comment j'ai décrit comment… vous n'accédez pas à une URL, puis elle renvoie des éléments. Il s'exécute automatiquement quand vous… lorsqu'il intercepte l'URL, comme le style CDN.

Chris: Donc, une des choses qu'il peut faire est de manipuler le HTML en chemin. Le travailleur, il a accès au document HTML complet. Ils ont un truc jQuery-esque qui ressemble à: "Recherchez ce sélecteur. Obtenez le contenu de celui-ci. Remplacez-le par ce contenu. Et puis continuez la demande. " Vous pouvez donc jouer avec le code en le parcourant. Pour tester cela localement, vous utilisez leur petit outil Wrangler pour le faire. De plus, je pense que la façon dont nous l’avons fait était… c’est aussi un peu dangereux. À la seconde où vous le mettez en ligne, cela affecte tout votre trafic Web. C’est un gros problème. Vous ne voulez pas bousiller un travailleur. Tu sais? Vous pouvez lancer un développeur de développement qui se trouve dans un faux sous-domaine, et comme il s'agit de CloudFlare, vous pouvez… CloudFlare peut de toute façon créer un sous-domaine. Je ne sais pas. C'est juste une bonne manière de faire… car vous n'affectez que le trafic du sous-domaine, pas encore votre trafic principal. Mais le sous-domaine n’est que le miroir d’une production de toute façon, donc c’est une sorte de… c’est une histoire de test là-bas.

Chris: Cela m’amène cependant à une chose intéressante. C’est comme… imaginez que vous avez deux sites Web. L’une d’elles est… pour nous, c’est comme une application Ruby on Rails. Peu importe. C’est une chose. Mais nous n’avons pas de CMS pour cela. C’est comme… ce n’est pas vraiment un CMS. Je pense qu'il y a probablement des CMS Ruby, mais il n'y en a pas de renommée. Tu sais? Il semble que tous les bons CMS soient PHP, pour une raison quelconque. Donc, vous voulez un CMS de qualité. Drew, vous vivez sur le marché des CMS depuis longtemps –

Drew: Absolument.

Chris: … vous savez donc comment cela se passe. Supposons que vous souhaitiez gérer vos sites dans Perch ou autre, car c’est un bon CMS et c’est la bonne chose à utiliser pour créer le type de pages que vous souhaitez créer. Mais vous ne voulez pas les exécuter sur le même serveur. À moins que vous ne souhaitiez gérer les pages sur un site, mais les afficher sur un autre site. Eh bien, je ne sais pas, il existe un certain nombre de façons de le faire. Mais un moyen JavaScript pourrait être: «D'accord, chargez la page. Il y a un div vide ici. Exécutez du JavaScript. Demandez à l'autre site le contenu de cette page, puis affichez-le sur la nouvelle page. " C'est bien, je suppose, mais maintenant vous êtes dans une page de rendu côté client. Ça va être lent. Cela va avoir un mauvais référencement, parce que… Google le verra éventuellement, mais cela prend 10 jours ou quelque chose comme ça. C'est juste une mauvaise histoire pour le référencement. Ce n’est pas très résilient, car qui sait ce qui va se passer sur le réseau. Ce n’est pas la meilleure façon de faire ce genre de "contenu ailleurs, contenu sur le site B, afficher la page du site A", situation.

Chris: Vous pouvez également le faire côté serveur, cependant. Disons que vous aviez… Ruby est également capable d’accorder une requête réseau, mais c’est encore plus effrayant, car si quelque chose échoue sur le réseau, la page entière pourrait mourir ou quelque chose du genre. C’est comme une chose nerveuse. Je n’aime pas non plus faire ça. Mais nous l'avons fait récemment avec un worker, en ce sens que nous… parce que le JavaScript du worker, il peut faire une demande de récupération. Donc, il récupère le site A, il trouve ce div sur la page, puis il va et demande au site B le contenu. Obtient le contenu. Le branche sur ce div et sert la page avant qu'il n'obtienne quoi que ce soit. Cela ressemble donc à une page rendue par le serveur, mais ce n’était pas le cas. Tout s’est passé au… à la périphérie, au niveau des travailleurs, au niveau sans serveur.

Chris: Donc, c’est plutôt cool. Je pense que vous pouvez imaginer qu'une demande de récupération sur le navigateur prend probablement, je ne sais pas, une seconde et demie ou quelque chose comme ça. Cela prend probablement une minute pour le faire. Mais parce que ce sont… le site B est hébergé sur un hébergement sympa et Cloudflare en a… qui sait quel genre de super ordinateurs ils utilisent pour le faire. Ils font. Ce ne sont que deux serveurs qui se parlent, et cette demande de récupération se produit tellement super duper, duper vite. Cela ne se limite pas à la vitesse de connexion Internet de l'utilisateur, de sorte qu'une petite demande prend environ deux millisecondes pour obtenir ces données. C'est donc un peu cette façon sympa d'assembler un site à partir de plusieurs sources et de lui donner l'impression et se comporter comme une page rendue par un serveur. Je pense qu'il y a un bel avenir à cela.

Drew: Y a-t-il une sorte de conventions qui surgissent en quelque sorte autour de choses sans serveur. Je réfléchis en quelque sorte à la manière d’architecturer les choses. Disons que j'ai quelque chose pour lequel je veux faire deux sortes de requêtes à différentes API. Je veux saisir une adresse postale et la géocoder par rapport à une adresse, puis prendre ces coordonnées et l’envoyer à un fleuriste qui va faire exploser ma cour ou quelque chose comme ça. Comment construiriez-vous cela? Feriez-vous deux choses distinctes? Ou voudriez-vous transformer cela en une seule fonction et faire la demande une seule fois depuis le navigateur?

Chris: Mm (affirmatif). C’est une question fascinante. J'aurais probablement une fonction d'architecte ou quelque chose comme ça. Une fonction serait celle qui est chargée d’orchestrer le reste d’entre eux. Ce n'est pas nécessaire, votre site Web est le hub et il ne communique qu'avec ce tableau de sources uniques. Les fonctions sans serveur peuvent communiquer avec d'autres fonctions sans serveur. Je pense donc que c’est assez courant d’avoir une sorte de fonction d’orchestrateur qui effectue les différents appels, les assemble et les renvoie comme un seul. Je pense que c'est probablement intelligent et plus rapide, car vous voulez que les serveurs parlent aux serveurs, pas que le client parle à tout un tas de serveurs. S'il peut faire une demande et obtenir tout ce dont il a besoin, je pense que c'est probablement une bonne idée en général…

Drew: Ouais, cela semble intelligent. Oui.

Chris: Mais je pense que c’est l’ultime chose. Vous avez un tas de nerds de serveurs qui parlent, ils parleront des différentes approches de cette idée exacte de 10 manières différentes.

Drew: Ouais. Non, cela semble assez intelligent. Je veux dire, vous avez également mentionné que cette approche est idéale si vous utilisez des API où vous avez des informations secrètes. Vous avez des clés API ou quelque chose que vous ne voulez pas vivre dans le client. Parce que je ne sais pas, peut-être que cette API de fleuriste vous facture 100 dollars à chaque fois qu'une fleur bombarde quelqu'un.

Chris: Facilement.

Drew: Vous pouvez essentiellement utiliser ces fonctions pour quasiment proxy la demande et ajoutez les informations secrètes au fur et à mesure, et gardez-les secrètes. C’est une façon viable de travailler?

Chris: Ouais, ouais. Je le pense. Je veux dire, les secrets sont, je ne sais pas, ils sont intéressants. C'est une forme de rachat, je pense, à n'importe quel fournisseur avec lequel vous allez, parce que… je pense en grande partie à cause du contrôle de la source. C’est un peu comme si vous pouviez simplement mettre votre clé API directement dans la fonction sans serveur, car elle va simplement vers un serveur, non? Vous n’avez même pas besoin de l’abstraire, vraiment. Le client ne verra jamais ce code qui s’exécute, mais pour qu’il y parvienne, il y a probablement un contrôle de source en cours de route. C’est probablement comme si vous vous engagez à maîtriser, puis à maîtriser… puis une sorte de déploiement se produit qui fait passer cette chose à la fonction sans serveur. Ensuite, vous ne pouvez pas y mettre votre clé API, car elle est alors dans le dépôt et vous ne mettez pas vos clés API dans des dépôts. C’est un bon conseil. Maintenant, il y a des trucs. Nous venons de le faire … à CodePen récemment, nous avons commencé à utiliser ce truc git-crypt, qui est un moyen intéressant de mettre des clés en toute sécurité dans vos dépôts, car il est chiffré au moment où quelqu'un regarde ce fichier.

Chris: Mais seulement localement, ils sont déchiffrés, ils sont donc utiles. C’est donc une idée intéressante. Je ne sais pas si cela aide dans ce cas, mais généralement, les fournisseurs de cloud de ces choses ont une interface Web qui dit: "Mettez vos clés API ici, et nous les rendrons disponibles au moment de l'exécution de cette fonction." Ensuite, ça se verrouille en quelque sorte… ça ne vous enferme pas éternellement mais c'est en quelque sorte… ce n'est pas aussi facile à déplacer, parce que toutes vos clés sont… vous mettez quelque part dans un champ de saisie et une interface d'administration.

Drew: Oui, je pense que c'est ainsi que Netlify le gère.

Chris: Ils le font tous, vous savez?

Drew: Ouais. Vous disposez des variables d'environnement secrètes que vous pouvez définir à partir de l'interface Web. Cela semble fonctionner assez bien.

Chris: Ouais, d'accord. Mais ensuite tu dois partir… Je ne sais pas, ce n’est pas si grave. Je ne dis pas qu’ils font quoi que ce soit de méchant ou quoi que ce soit. Comment gérez-vous ces secrets? Eh bien, c’est un problème difficile. Donc, ils l'ont en quelque sorte démarré, je ne sais pas, "Mettez-les simplement dans ce champ de saisie et nous nous en occuperons pour vous, ne vous en faites pas."

Drew: Is Y a-t-il quelque chose que vous avez vu qui se démarque comme un cas évident pour les choses que vous pouvez faire avec le sans serveur, que vous ne pourriez tout simplement pas faire avec une approche traditionnelle avec serveur complet? Ou est-ce que cela prend simplement ce code et le déploie presque d'une manière différente?

Chris: C'est probablement surtout ça. Je ne sais pas si cela ouvre la moindre possibilité que vous ne puissiez absolument pas l'exécuter autrement. Oui, je pense que c’est une bonne réponse, mais cela la banalise d’une manière intéressante. Par exemple, si quelqu'un écrit une fonction sans serveur vraiment sympa… Je ne sais pas encore si cela existe, mais il pourrait y avoir une sorte de marché, presque, pour ces fonctions. Par exemple, je veux une très bonne fonction sans serveur qui puisse prendre une capture d'écran. Cela pourrait être un projet open source que beaucoup de globes oculaires autour, qui fait un très bon travail de le faire et résout tous ces cas de bord étranges. C’est celle que je souhaite utiliser. Je pense que c’est plutôt cool. Tu sais? De cette manière, vous pouvez en quelque sorte bénéficier de l’expérience des autres. Je pense que cela se produira de plus en plus.

Drew: Je suppose que c'est l'avantage dont nous avons parlé, tout en haut, de permettre aux personnes qui écrivent du JavaScript et peuvent avoir écrit du JavaScript uniquement pour le front-end, pour développer et utiliser également ces compétences sur le back-end.

Chris: 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é ou non pour un site Web. Comme, j'ai fait un petit tutoriel l'autre semaine, là où il y avait ce problème utilise ces… quand vous enregistrez un problème, ils vous donnent une limace pour votre chose que vous avez construite, c'est, "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 d'autre. Mais ils finissent par être ces petites choses amusantes. Ils open source leur bibliothèque qui contient tous ces mots, mais c'est comme cent, milliers de mots. Le fichier est énorme. Tu sais? Il s’agit d’un dictionnaire de mots en mégaoctets. Vous apprendrez probablement au cours de votre première année de développement, "Ne pas envoyer de fichier JavaScript contenant des mégaoctets de dictionnaire." Ce n’est pas une bonne chose à expédier. Tu sais? Mais Node s'en fiche. Vous pouvez en expédier des centaines. Cela n’a rien à voir avec la vitesse sur 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, et une note en haut, «Faites-lui un nombre aléatoire. Retirez-le de la baie et renvoyez-le. » Donc, cette fonction sans serveur est huit lignes de code avec un package @ 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 à ce sujet, c’est tellement simple. Je ne m'inquiète pas pour la sécurité de celui-ci. Je ne… tu sais?

Chris: C’est juste… un développeur JavaScript très moyen ou débutant, je pense, peut réussir, ce qui est cool. C’est une chose habilitante qu’ils n’avaient pas auparavant. Avant, ils se disaient: "Eh bien, voici un tableau de 2 Mo de mots." "Oh, je ne peux pas expédier ça au client." "Oh, tu vas juste arrêter alors." Vous pourriez frapper ce mur qui dit: «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 tout simplement de ne pas le faire ou de choisir plus de limaces ennuyeuses ou quelques-unes … »C'est juste que vous devez emprunter une autre voie qui est un mur pour vous, car vous ne pouviez 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 source slash, 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? Tu sais? Vous utilisez presque exactement le même ensemble de compétences. Il y a encore des aspérités, mais c'est assez proche.

Drew: C'est super cool. Vous avez créé une sorte de petit micro-site consacré à ces idées, n'est-ce pas?

Chris: Ouais. J'étais un peu en avance dans le match. Je travaillais juste dessus aujourd'hui, cependant, parce que… il reçoit des pull requests. 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 construit sans serveur aussi, donc c'est… CSS-Tricks est comme un site WordPress, mais c'est un site générateur de site statique. Tout le contenu de celui-ci se trouve dans le dépôt 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, car il répertorie… Si vous pensez: «Oui, je veux commencer avec des fonctions sans serveur», il répertorie tous les fournisseurs qui vous pourriez l'essayer et…

Chris: C'est tout ce que c'est, à peu près, des listes de technologie. Ouais.

Drew: Ce qui est génial, car sinon, vous cherchez simplement 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… à la minute où vous choisissez de… disons, vous allez y aller JAMstack, dont je sais que ce n'est pas nécessairement le but de cela, mais vous voyez à quel point ils sont main dans la main. Tout à coup, vous n’avez pas de fichier PHP ou quoi que ce soit pour traiter ce formulaire. Comment faites-vous des formulaires sur un site JAMstack? Eh bien, il existe plusieurs façons de procéder. 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 sans serveur vos formulaires sur ce site dès maintenant. Si vous voulez être le 23e, vous y ê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 indique ce qu'ils veulent que vous pointiez. Ils traiteront le formulaire, puis ils auront tendance à faire les choses que vous attendez d'eux, comme envoyer une notification par e-mail. Ou envoyez 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 éléments légèrement différents, mais ils essaient tous de résoudre ce problème à votre place, par exemple, "Vous ne voulez pas traiter vos propres formulaires? Aucun problème. Nous allons le traiter pour vous. »

Drew: Oui, c'est une ressource très 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'avez-vous appris ces derniers temps, Chris?

Chris: Eh bien, je suis encore très présent dans ce monde et j'apprends des choses sans serveur. J'ai eu une idée de… J'ai joué à ce jeu de rôle en ligne il y a longtemps. Je viens de découvrir récemment qu’il est toujours vivant. C'est un jeu de type fantastique médiéval basé sur du texte. J'y ai joué quand AOL était une chose, parce qu'AOL voulait avoir ces jeux qu'il fallait ê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.

Chris: Ouais. Les jeux étaient donc 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é à AOL, car je suis sûr qu’ils ont obtenu une bonne affaire pour cela, mais c’était tellement … je veux dire, c’est juste, ne pouvait pas être plus nerd. Vous êtes un mage nain et vous obtenez le bâton runique de 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 intéressé. Je suis entré dans la communauté et l'esprit de celui-ci. C'était en quelque sorte un… c'était comme si j'étais seul tout 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'aimais juste 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 t'arrive.

Chris: Je ne l'ai découvert que récemment, parce que quelqu'un a recommencé à en faire un podcast… Je ne sais pas comment je l'ai découvert , mais je viens de le faire. Je me suis dit: «Ce jeu est bien vivant dans le monde d’aujourd’hui, vous vous moquez de moi? Cette chose basée sur du texte. " Et j'étais plus qu'heureux de réactiver et de récupérer mes anciens personnages et de les jouer. Mais seulement pour découvrir que les clients qu'ils ont téléchargés pour ce jeu n'ont pas du tout évolué. Ils sont affreux. Ils supposent presque que vous utilisez Windows. Il y a juste ces mauvais rendu terriblement ringard … et il est basé sur du texte, vous pensez qu'il aurait au moins une belle typographie. Non, donc je me dis: «Je pourrais être impliqué. Je pourrais écrire un client pour ce jeu. Mettez-y une belle typographie. » Il suffit de moderniser la chose, et je pense que les joueurs du jeu l'apprécieraient, mais cela me paraissait écrasant. "Comment puis-je le faire?" Mais je trouve des 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 interface graphique à partir d'une fenêtre de terminal.

Drew: Vraiment?

Chris : Je ne sais pas. C'était donc plutôt cool. J'étais comme: «S'ils ont écrit ça, il doit y avoir du code là-dedans pour savoir comment se connecter au jeu et tout faire fonctionner, etc. 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 du genre", 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 ça a été vraiment amusant de travailler, mais j'ai aussi beaucoup appris, car il 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 des choix technologiques que je n'aurais jamais choisis.

Chris: C'est une application Electron. Ils ont choisi cela, ce qui est également une bonne façon 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 à quel point 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 apprenez des compétences qui peuvent ensuite alimenter notre travail quotidien.

Chris: C'est la seule façon dont j'apprends des choses. Je suis entraîné dans quelque chose qui … je me suis dit: "Ils ne sont pas …" Il 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 un peu important parce que dans ce jeu basé sur du texte, le texte ne fait que voler. Il y a beaucoup de manipulation de données, ce qui revient à… vous pensez 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 en cours, que vous devez vraiment être vraiment … nous devons être conscients de la vitesse du rendu. Vous savez?

Drew: C'est fascinant-

Chris: Assez 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 véritable URL.

 Smashing Editorial (il)




Source link