Qu'estce que sans serveur?

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

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, qui apparaît en haut des résultats de la recherche Google lorsque vous recherchez des réponses à une 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 peu de 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 j'ai l'impression que 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 avec 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, tout en haut. Nous parlons de serveur 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 la première douzaine de 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 les lieux. 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 la raison pour laquelle vous exécutez le back-end pour commencer, car il connaît des éléments secrets qui ne doivent pas nécessairement être dans 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 communique avec 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. J'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 la rend également 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 tout simplement 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 est là pour enregistrer les factures. L'utilisateur ferait une demande et il construirait tout ce truc 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. Ainsi, 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 que ce n'est encore qu'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 qu’on n’a même pas besoin de s’inquiéter 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 quelque sorte 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 demande JavaScript pour obtenir des données et les préremplit ensuite. Vous le faites donc avant ou après, 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 ne s’agit que 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 forcément 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 eCommerce, ce qui signifie… et disons eCommerce à 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 effectuer un pré-rendu 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 construite dans les années 2000 qui leur permettra peut-être de 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…

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 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 en faire. 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 l’utiliser? 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 sur 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: «Et 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é très rapidement dans un compartiment S3, 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 les 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 quelque chose est déjà mis en cache 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", car vous ne pouvez tout simplement pas compter dessus. Et les travailleurs 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, ce genre 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 qui sont 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, dans la mesure où… 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. Il semble que ce soit une extension de cela –

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 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 allons-nous récupérer ce JavaScript et le lancer 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. Alors, 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 en 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 elles se trouvent également être 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 de structurer 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 que sais-je encore. Il en est conscient et demande à l’utilisateur de réessayer. Ou réessayer vous-même, ou quelque chose comme ça.

Chris: Oui, 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 ne pas réessayer 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 fait 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. You can write a Ruby Cloud Function. So, I know I’m specifically talking about JavaScript, because I have a feeling that most of these things are JavaScript. Even no matter what language it is, I mean, you can go to your command line locally and execute the thing. Some of that testing is… you just test it like you would any other code. You just call the function locally and see if it works.

Chris: It’s a little different story when you’re talking about an HTTP request to it, that’s the thing that you’re trying to test. Does it respond to the request properly? And does it return the stuff properly? Je ne sais pas. The network might get involved there. So you might want to write tests at that level. That’s fine. Je ne sais pas. What is the normal story there? You spin up some kind of local server or something that serves it. Use Postman, I don’t know. But there’s… Frameworks try to help too. I know that the serverless “.com”, which is just terribly confusing, but there’s literally a company called Serverless and they make a framework for writing the serverless functions that helps you deploy them.

Chris: So if you like NPM install serverless, you get their framework. And it’s widely regarded as very good, because it’s just very helpful, but they don’t have their own cloud or whatever. You write these and then it helps you get them to a real lambda. Or it might work with multiple cloud providers. I don’t even know these days, but their purpose of existing is to make the deployment story easier. I don’t know what… AWS is not renowned for their simplicity. You know? There’s all this world of tooling to help you use AWS and they’re one of them.

Chris: They have some kind of paid product. I don’t even know what it is exactly. I think one of the things they do is… the purpose of using them is for testing, is to have a dev environment that’s for testing your serverless function.

Drew: Yeah, because I guess, that is quite a big part of the workflow, isn’t it? If you’ve written your JavaScript function, you’ve tested it locally, you know it’s going to do the job. 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?

Chris: Yeah. 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. You know? 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. It’s a thing. 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. You know? 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. Yep.

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: Yeah. 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: Yeah. 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. You know? 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.

Chris: Yeah, yeah. I think so, I think that’s… because there’s moments like… you don’t have to be tremendously skilled to know what’s appropriate and what’s not for a website. Like, I did a little tutorial the other week, where there was this glitch uses these… when you save a glitch, they give you a slug for your thing that you built, that’s, “Whiskey, tango, foxtrot. 1,000.” It’s like a clever little thing. The chances of it being unique are super high, because I think they even append a number to it or something too. But they end up being these fun little things. They open source their library that has all those words in it, but it’s like a hundred, thousands of words. The file is huge. You know? It’s megabytes large of just a dictionary of words. You probably learn in your first year of development, “Don’t ship a JavaScript file that’s megabytes of a dictionary.” That’s not a good thing to ship. You know? But Node doesn’t care. You can ship hundreds of them. It’s irrelevant to the speed on a server.

Drew: Yeah.

Chris: It doesn’t matter on a server. So, I could be like, “Hmm, well, I’ll just do it in Node then.” I’ll have a statement that says, “Words equal require words,” or whatever, and a note at the top, “Have it randomize a number. Pull it out of the array and return it.” So that serverless function is eight lines of code with a packaged@JSON that pulls in this open source library. And then my front-end code, there’s a URL to the serverless function. It hits that URL. The URL returns one word or a group of words or whatever. You build your own little API for it. And now, I have a really kind of nice, efficient thing. What was nice about that is, it’s so simple. I’m not worried about the security of it. I don’t… you know?

Chris: It’s just… a very average or beginner JavaScript developer, I think, can pull that off, which is cool. That’s an enabling thing that they didn’t have before. Before, they were like, “Well, here’s a 2MB array of words.” “Oh, I can’t ship that to the client.” “Oh, you’ll just shut down then.” You might hit this wall that’s like, “I just can’t do that part then. I need to ask somebody else to help me with that or just not do it or pick more boring slugs or some…” It’s just, you have to go some other way that is a wall to you, because you couldn’t do it. And now, you’re, “Oh, well, I’ll just…” Instead of having that in my script slash, or in my source slash scripts folder, I’ll put it in my functions folder instead.

Chris: You kind of like moved the script from one folder to the other. And that one happens to get deployed as a serverless function instead. À quel point cela est cool? You know? You’re using the same exact skill set, almost. There’s still some rough edges to it, but it’s pretty close.

Drew: It’s super cool. You’ve put together a sort of little micro site all about these ideas, haven’t you?

Chris: Yeah. I was a little early to the game. I was just working on it today, though, because… it gets pull requests. The idea… well, it’s at serverless.css-tricks.com and… there’s a dash in CSS-Tricks, by the way. So it’s a subdomain of CSS-Tricks, and I built it serverlessly too, so this is… CSS-Tricks is like a WordPress site, but this is a static site generator site. All the content of it is in the GitHub repo, which is open-source. So if you want to change the content of the site, you can just submit a poll request, which is nice because there’s been a hundred or so of those over time. But I built all the original content.

Drew: It’s a super useful place, because it lists… If you’re thinking, “Right, I want to get started with serverless functions,” it lists all the providers who you could try it and…

Chris: That’s all it is, pretty much, is lists of technology. Yeah.

Drew: Which is great, because otherwise, you’re just Googling for whatever and you don’t know what you’re finding. Yeah, it’s lists of API providers that help you do these sorts of things.

Chris: Forms is one example of that, because… so the minute that you choose to… let’s say, you’re going to go JAMstack, which I know that’s not necessarily the point of this, but you see how hand in hand they are. All of a sudden, you don’t have a PHP file or whatever to process that form with. How do you do forms on a JAMstack site? Well, there’s any number of ways to do it. Everybody and their sister wants to help you solve that problem, apparently. So I think if I was the inventor of the word JAMstack, so they try to help you naturally, but you don’t have to use them.

Chris: In fact, I was so surprised putting this site together. Let’s see. There’s six, nine, twelve, fifteen, eighteen, twenty one, twenty two services out there, that want to help you serverlessly process your forms on this site right now. If you want to be the 23rd, you’re welcome to it, but you have some competition out there. So the idea behind this is that you write a form in HTML, like literally a form element. And then the action attribute of the form, it can’t point anywhere internally, because there’s nothing to point to. You can’t process, so it points externally. It points to whatever they want you to point it to. They’ll process the form and then they tend to do things that you’d expect them to, like send an email notification. Or send a Slack thing. Or then send it to Zapier and Zapier will send it somewhere else. They all have slightly different feature sets and pricing and things, but they’re all trying to solve that problem for you, like, “You don’t want to process your own forms? Aucun problème. We’ll process it for you.”

Drew: Yeah, it’s a super useful resource. I’d really recommend everyone check it out. It’s serverless.css-tricks.com. So, I’ve been learning all about serverless. What have you been learning about lately, Chris?

Chris: Well, I’m still very much in this world too and learning about serverless stuff. I had an idea to… I used to play this online role playing game ages ago. I just recently discovered that it’s still alive. It’s a text based medieval fantasy kind of game. I played it when AOL was a thing, because AOL wanted to have these games that you had to be logged on to play it, because they wanted you to spend hours and hours on AOL, so they could send you these huge bills, which was, I’m sure, why they did so well at some point.

Drew: So billing by the second. Yeah.

Chris: Yeah. So games was big for them. If they could get you playing games with other people on there. So this game kind of… it didn’t debut there, but it moved to AOL, because I’m sure they got a juicy deal for it, but it was so… I mean, it’s just, couldn’t possibly be nerdier. You’re a dwarven mage and you get rune staff from your leather sheath. And you type commands into it like a terminal. Then the game responds to you. I played that game for a very long time. I was very into it. I got into the community of it and the spirit of it. It was kind of a… it was like I was just alone by myself at my computer, but yet I look back on that time in my life, and be like, “That was a wonderful time in my life.” I was really… I just liked the people and the game and all that. But then I grew up and stopped playing it, because life happens to you.

Chris: I only found out recently, because somebody started doing a podcast about it again… I don’t know how I came across it, but I just did. I was like, “This game is alive and well in today’s world, are you kidding me? This text based thing.” And I was more than happy to reactivate and get my old characters back and play it. But only to find out that the clients that they have you download for this game, haven’t evolved at all. They are awful. They almost assume that you’re using Windows. There’s just these terribly cheesy poorly rendering… and it’s text based, you think it’d at least have nice typography. No. So I’m like, “I could be involved. I could write a client for this game. Put beautiful typography in it.” Just modernize the thing, and I think the players of the game would appreciate it, but it felt overwhelming to me. “How can I do it?” But I find some open source projects. One of them is like… you can play the game through an actual terminal window, and it uses some open source libs to kind of make a GUI out of a terminal window.

Drew: Really?

Chris: I don’t know. So that was kind of cool. I was like, “If they wrote that, there must be code in there to how to connect to the game and get it all going and stuff. So at least I have some starter code.” I was trying to go along the app, “Maybe I’ll do it in Flutter or something,” so the final product app would work on mobile phones and, “I could really modernize this thing.” But then I got overwhelmed. I was like, “Ah, this is too big a… I can’t. I’m busy.” But I found another person who had the same idea and they were way further along with it, so I could just contribute on a design level. And it’s been really fun to work on, but I’ve been learning a lot too, because it’s rare for me to jump into a project that’s somebody else’s baby, and I’m just contributing to a little bit, and that has totally different technology choices than I would have ever picked.

Chris: It’s an Electron app. They picked that, which is also kind of a cool way to go too, because it’s my web skills… so I’m not learning anything too weird, and it’s cross-platform, which is great. So, I’ve been learning a lot about Electron. I think it’s fun.

Drew: That’s fascinating. It’s always amazing how little side projects and things that we do for fun, end up being the place where we sometimes learn the most. And learn skills that can then feed back into our sort of daily work.

Chris: That’s the only way I learn things. I’m dragged into something that… I was like, “They’re not…” It’s rendered with a JavaScript library called Mithril, which is… I don’t know if you’ve ever heard of it, but it’s weird. It’s not… it’s almost like writing React without JSX. You have to “create element” and do all these… but it’s supposed to benchmark way better than it… And it actually kind of matters because in this text based game, the text is just flying. There’s a lot of data manipulation, which is like… you’d think this text based game would be so easy for a browser window to run, but it’s actually kind of not. There’s so much data manipulation happening, that you really have to be really… we have to be conscientious about the speed of the rendering. You know?

Drew: That’s fascinating-

Chris: Pretty cool.

Drew: Yeah. If you, dear listener, would like to hear more from Chris, you can find him on Twitter, where he’s @chriscoyier. Of course, CSS-Tricks can be found at css-tricks.com and CodePen at codepen.io. But most of all, I recommend that you subscribe to the ShopTalk Show podcast if you haven’t already done so, at shoptalkshow.com. Thanks for joining us today, Chris. Do you have any parting words?

Chris: Smashingpodcast.com. I hope that’s the real URL.

(il)