Smashing Podcast Episodio 22 con Chris Coyier: cos'è il serverless?

Oggi parliamo di architetture Serverless. Cosa significa e in che cosa differisce da come potremmo creare siti attualmente? Ho parlato con Chris Coyier per scoprirlo.

Mostra note

• Il microsito di Chris The Power of Serverless for Front-end Developers
• Chris su Twitter
• Podcast di ShopTalk Show

Aggiornamento settimanale

• "Configurazione di Redux per l'uso in un'applicazione del mondo reale",
  di Jerry Navi
• "Puoi progettare un sito Web per i cinque sensi?"
  di Susanna Scacca
• "Creare un blog statico con Sapper e Strapi",
  di Daniel Madalitso Phiri
• "Una guida pratica ai tour dei prodotti nelle app React",
  dalla benedizione di Krofegha
• "Come creare una Porsche 911 con Sketch"
  di Nikola Lazarevic

Trascrizione

Drew McLellan: È un web designer e sviluppatore che potresti conoscere da CSS-Tricks, un sito Web che ha avviato più di 10 anni fa e che rimane una fantastica risorsa di apprendimento per coloro che creano siti Web. È il co-fondatore di CodePen, il parco giochi di codifica basato su browser e la comunità utilizzata dai front-end di tutto il mondo per condividere ciò che fanno e trovare ispirazione da coloro che seguono. Insieme a Dave Rupert è il co-conduttore di ShopTalk Show, un podcast dedicato alla creazione di siti Web. Quindi sappiamo che sa molto sullo sviluppo web, ma sapevi che una volta ha vinto un concorso di mangiatori di hot dog usando solo il suo fascino? Miei formidabili amici, vi prego di dare il benvenuto a Chris Coyier. Ciao Cris, come stai?

Chris Coyier: Ehi, sto distruggendo.

Drew: Volevo parlarti oggi non di CodePen, e non voglio necessariamente parlarti di CSS-Tricks, che è una di quelle risorse straordinarie che sono sicuro che tutti sanno che appare proprio in cima a Google Risultati della ricerca quando si cercano risposte su qualsiasi domanda di sviluppo web. Viene visualizzata la tua faccia e c'è un utile post sul blog scritto da te o da uno dei tuoi contributori ospiti.

Chris: Oh, lo facevo davvero. C'è stato un... non lo so, probabilmente è stato durante il periodo in cui Google aveva quello strano social network. Che cos 'era questo? Google Plus?

Drew: Oh, in più, sì.

Chris: Sì, dove associavano un sito Web a un account Plus, quindi il mio account Plus aveva un avatar e l'avatar ero io, quindi sarebbe apparso nei risultati di ricerca. Penso che quei giorni siano passati. Penso che se tu...

Drew: Penso di sì, sì-

Chris: Sì.

Drew: Ma in un certo senso volevo parlarti di qualcosa che è stato un po' più una sorta di tuo interesse secondario, ed è questo concetto di architetture serverless.

Chris: Mm (affermativo).

Drew: Questo è qualcosa su cui stai imparando qualcosa di più da un po' di tempo. È giusto?

Chris: Sì, sì. Sono solo un fan. Sembra un adattamento naturale all'evoluzione dello sviluppo front-end, ed è qui che sento di avere almeno una certa esperienza. Mi considero molto più un... molto più utile sul front-end che sul back-end, non che io... lo faccia tutti questi giorni. Sono stato in giro abbastanza a lungo da non aver paura di guardare un po' di codice Ruby, questo è certo. Ma io preferisco il front-end. L'ho studiato di più. Ho partecipato a progetti più a quel livello, e poi è arrivato questo piccolo tipo di nuovo paradigma che dice: "Puoi usare le tue abilità JavaScript sul server", ed è interessante. Sai? È così che la penso. C'è molto di più in questo, ma è per questo che mi interessa, è perché sento che gli sviluppatori front-end hanno scavato così a fondo in JavaScript. E ora possiamo usare lo stesso set di abilità altrove. Mm, piuttosto cool.

Drew: Sembra che si sia aperto un mondo completamente nuovo, mentre se tu fossi solo un programmatore front-end... dico, solo un programmatore front-end, non dovrei. Se sei un programmatore front-end e sei abituato a lavorare con un collega o un amico per aiutarti con l'implementazione del back-end, all'improvviso si è aperto. Ed è qualcosa che puoi gestire tu stesso di più dell'intero stack.

Chris: Sì, sì. Questo è tutto.

Drew: Rivolgendosi all'elefante nella stanza, proprio in alto. Stiamo parlando di serverless e, ovviamente, dare un nome alle cose è difficile. Lo sappiamo tutti. L'architettura serverless non significa che non ci siano server, vero?

Chris: Penso che sia obbligatorio, ad esempio se questo è il primo podcast di cui ne senti parlare, o nel primo... senti la parola "serverless" solo nelle prime dozzine di volte in cui l'hai sentito, è obbligatorio che tu avere una reazione viscerale e avere questo tipo di "Oh, ma ci sono ancora i server". Va bene. Se ti sta succedendo in questo momento, sappi solo che è un passaggio obbligatorio in questo. È proprio come qualsiasi altra cosa nella vita. Ci sono fasi per la comprensione. La prima volta che senti qualcosa, ti viene richiesto di rifiutarlo un po', e solo dopo una dozzina di volte o giù di lì, o dopo che ti è stato dimostrato un po' di valore, puoi entrare nelle fasi successive di comprensione qui. Ma la parola ha vinto, quindi se stai ancora combattendo contro la parola "serverless", odio dirti che il treno ha lasciato la stazione lì. La parola ha già successo. Non vincerai questo. Quindi, scusa.

Chris: Ma penso che sia interessante che... stia iniziando a pensare che forse a volte non ci sono server coinvolti. Penso che una delle cose che ha bloccato il serverless come concetto fosse AWS Lambda. Sono stati i primi sulla scena. Una lambda è come una funzione che dai ad AWS e la mette nel cielo magico e poi... ha un URL e puoi colpirlo ed eseguirà quella funzione e restituirà qualcosa se lo desideri. Sai? Questo è solo HTTP o altro. È così che funziona, che... la prima volta che lo senti, sei tipo "Perché? Non mi interessa.” Ma poi, ci sono alcune cose ovvie. Potrebbe conoscere le mie chiavi API a cui nessun altro ha accesso. Ecco perché per cominciare corri il back-end, è che conosce cose segrete che non devono essere nel JavaScript sul lato client. Quindi, se ha bisogno di parlare con un database, può farlo. Può farlo in modo sicuro senza dover esporre le chiavi API altrove. O anche dove si trovano quei dati o come li ottengono, sono...

Chris: Quindi è abbastanza bello. Posso scrivere una funzione che parli con un database, ottenere alcuni dati, restituirli. Freddo. Quindi, Lambda è quello, ma AWS funziona. Devi scegliere una regione. Sei tipo "Non lo so. Dove dovrebbe essere, Virginia? Oregon? Dovrei scegliere quello australiano? Non lo so." Ne hanno 20, 30. Non so nemmeno quanti ne hanno in questi giorni, ma anche le lambda avevano regioni. Penso che in questi giorni abbiano Lambda@Edge, il che significa che sono tutte le regioni, il che è piuttosto interessante. Ma sono stati i primi, e ora tutti hanno qualcosa come Lambda. Tutti i servizi cloud. Vogliono un qualche tipo di servizio in questo mondo. Uno di questi è CloudFlare. CloudFlare ha lavoratori. Hanno molte più posizioni di AWS, ma l'hanno eseguito anche in un momento diverso... il modo in cui un lavoratore CloudFlare... è simile a un lambda in quanto puoi eseguire Node. Puoi eseguire JavaScript. Puoi eseguire anche un certo numero di altri linguaggi, ma... penso a queste cose in gran parte, il linguaggio più interessante è JavaScript, proprio per la sua prevalenza.

Chris: Succede solo a livello di CDN, che immagino sia un server, ma tendo a non pensare ai CDN come a un server. Non così ovviamente come qualcos'altro. Ultimamente sta iniziando a sembrare ancora più serverless. Una CDN è un server? Voglio dire, immagino che sia un computer da qualche parte, ma sembra ancora meno server-y.

Drew: Sì, sembra che una CDN possa essere un server, ma è la versione più minimale di un server. È come un server sottile, se vuoi.

Chris: Sì. Sicuro.

Drew: Va bene. Ho sentito dire... Sfortunatamente, non ricordo la fonte da accreditare, ma ho sentito descrivere il serverless come "come usare un servizio di condivisione di corse come Uber o Lyft" o altro. Puoi essere senza auto e non possedere un'auto, ma ciò non significa che non usi mai un'auto.

Chris: Sì, non significa che le auto non esistano. Mm, è carino.

Drew: Ne evochi uno quando ne hai bisogno, ma allo stesso tempo non paghi il costo di acquisto anticipato di un'auto. Non stai pagando manutenzione o carburante o-

Chris: Giusto, e anche il prezzo ha senso, giusto? Bello. Questa è una bella analogia, credo. E poi, poiché è anche a livello di CDN, intercetta semplicemente le richieste HTTP che stanno già avvenendo, il che significa che non lo chiedi ... non gli invii una richiesta e lui invia una richiesta indietro. Sta succedendo naturalmente durante la richiesta, il che lo fa anche sentire meno servery. Non lo so, è interessante. È sicuramente interessante. Quindi è un grosso problema, però, che tu abbia sollevato la questione dei prezzi. Che paghi solo per quello che usi. Anche questo è significativo, perché... diciamo che sei uno sviluppatore di back-end, abituato a far girare i server per tutta la vita. E gestiscono i costi, "Ho bisogno di questo tipo di server con questo tipo di memoria e questo tipo di CPU e questo tipo di specifiche. E questo è quanto costerà”. Serverless arriva e taglia la testa a quel prezzo.

Chris: Quindi, anche se sei uno sviluppatore di back-end a cui non piace così tanto, che semplicemente non sono interessati, come se il tuo set di abilità fosse quello che è stato nel corso degli anni, confronti il ​​prezzo e tu dici "Cosa? Potrei pagare l'1% di quello che pagavo prima?" Non ti è permesso non preoccuparti di questo, giusto? Se sei questo sviluppatore back-end che paga cento volte di più per il loro servizio di quanto debbano pagare, allora sei solo un po' pessimo nel tuo lavoro. Spiace dirlo. Questo è arrivato e questo ha sconvolto i prezzi in molti modi. Devi preoccupartene. Ed è bello che qualcun altro sia... Non è che non devi preoccuparti della sicurezza, ma non è il tuo server. Non hai... la tua funzione lambda o cloud, o il tuo lavoratore, o altro, non è seduto su un server che è proprio accanto ad alcuni dati davvero sensibili sulla tua rete. Non è proprio accanto al tuo database.

Chris: Se qualcuno scrive codice che in qualche modo tenta di espellersi dal lavoratore o dalla lambda, o altro, e cerca di ottenere l'accesso ad altre cose sulla sua strada, non c'è niente da ottenere. Quindi anche la sicurezza è un grosso problema, quindi di nuovo, se questo è il tuo lavoro come amministratore del server, è occuparti della sicurezza di questa cosa. Eseguendolo, eseguendo alcune cose in Lambda, ottieni semplicemente una sicurezza naturale da esso, il che è fantastico. Quindi, è molto più economico. È molto più sicuro. Incoraggia queste piccole architetture modulari, che possono essere una buona idea. Sembra essere domino dopo domino di buone idee qui. Ecco perché è notevole. Sai?

Drew: Sì, voglio dire, tradizionalmente con un'architettura basata su server che abbiamo eseguito per decenni sul web, hai un server web che gestisci tu stesso. Contiene il tuo codice front-end, il tuo codice back-end, il tuo database e tutto. Quindi devi mantenerlo e mantenerlo in funzione e pagare le bollette, e anche se non viene utilizzato, è lì che registra le bollette. L'utente farebbe una richiesta e creerebbe tutta quella roba di query HTML dal database, invierebbe tutto lungo la linea al browser. Quel processo funziona. È così che vengono costruite un sacco di cose. Probabilmente è la maggior parte di come è costruito il web. È così che funzionano cose come WordPress. È davvero un problema che dobbiamo risolvere? Voglio dire, abbiamo parlato un po' di costi. Quali sono gli altri tipi di problemi che dobbiamo affrontare e che il serverless potrebbe aiutarci?

Chris: Sì, i problemi con l'approccio della vecchia scuola. Sì, non lo so, forse non ce n'è. Voglio dire, non sto dicendo che l'intero web abbia bisogno di cambiare il suo intero... l'intera cosa dall'oggi al domani. Non lo so. Forse non è proprio così, ma penso che apra le porte. Sembra solo che, quando le buone idee arrivano in questo modo, cambino lentamente il modo in cui funziona il web. Quindi, se c'è qualche CMS costruito in qualche modo che prevede la presenza di un database, significa che forse gli host del futuro inizieranno a sfruttarlo in modi interessanti. Forse ti sembra che sia ancora solo un server tradizionale, ma gli host stessi lo hanno trasformato, come operano, in architetture serverless. Quindi non sai nemmeno davvero che sta succedendo, ma hanno trovato un modo per ridurre i costi ospitando le cose di cui hai bisogno in modi serverless. Forse sì, non c'è nemmeno bisogno di preoccuparsi come sviluppatore, ma a un meta livello, questo è quello che sta succedendo. Forse. Non lo so.

Chris: Inoltre non significa che... I database sono ancora lì. Se si scopre che avere un database relazionale dal punto di vista architettonico è il modo corretto per archiviare quei dati, fantastico. Lo dico perché questo mondo di Serverless sta crescendo nello stesso momento in cui lo è JAMstack. E JAMstack è questa architettura che dice: "Dovresti servire il tuo sito Web da host statici, che non eseguono nulla tranne ..." Sono come piccole CDN. Dicono: “Non posso fare niente. Non eseguo PHP. Non gestisco Ruby. Non corro niente. Corro su un minuscolo server Web progettato solo per servire solo file statici.

Chris: “E poi, se hai bisogno di fare di più, se hai bisogno di estrarre dati da un database relazionale, fallo in un altro momento, non al momento del server. Puoi farlo in un processo di compilazione in anticipo ed estrarre quella roba dal database, pre-creare file statici e io li servirò, oppure farlo in fase di esecuzione. Ciò significa che ottieni questa shell di un documento, quindi fa una richiesta JavaScript per ottenere alcuni dati e quindi li precompila. Quindi lo fai in anticipo o dopo il tempo, ma non significa "Non utilizzare un database relazionale". Significa solo: "Non lasciare che il server lo generi al momento della richiesta del documento", che è un... non so, è un po' un cambio di paradigma.

Chris: Non è nemmeno solo JAMstack. Viviamo anche ai tempi dei framework JavaScript. Viviamo in un'epoca in cui inizia a essere un po' più prevedibile rispetto al modo in cui un'applicazione JavaScript si avvia, monta alcuni componenti e, man mano che questi componenti vengono montati, richiede i dati di cui ha bisogno. E quindi, può essere una scelta naturale per qualcosa come un sito Web React dire: "Bene, mi limiterò a selezionare una funzione serverless per estrarre i dati di cui ha bisogno. In sostanza, colpisce alcune API JSON. Ottengo i dati JSON di cui ho bisogno e mi costruisco da quei dati, quindi eseguo il rendering sulla pagina. " Ora, se questo è un bene o un male per il web, è come, “Non lo so. Peccato. La nave è salpata. È così che molte persone stanno costruendo i cantieri”. Sono solo cose rese dal cliente. Quindi, JavaScript moderno e serverless vanno di pari passo.

Drew: Suppongo che tu non debba vendere all'ingrosso... guardare un'architettura o un'altra. C'è un'area nel mezzo in cui parti di un'infrastruttura potrebbero essere più tradizionali e parti potrebbero essere serverless, immagino?

Chris: Sì. Beh, stanno cercando di dirtelo comunque. Chiunque voglia venderti una parte della propria architettura dice: “Non devi comprare tutto in questo momento. Fallo solo un po'". Perché, naturalmente, vogliono che tu metta la punta del piede in qualunque cosa stiano vendendo, perché una volta che la abbassi, le probabilità che ti tuffi in piscina sono molto più alte. Quindi, penso che... non è una bugia, però, necessariamente, anche se trovo un po' meno fortuna in... non voglio che il mio stack sia un po' di tutto. Penso che ci sia qualche morte tecnica lì che non voglio ingoiare sempre.

Disegnato: Mm (affermativo).

Chris: Ma è possibile farlo. Penso che il più citato sia... diciamo che ho un sito che ha un elemento di eCommerce, il che significa... e diciamo eCommerce su larga scala, quindi 10.000 prodotti o qualcosa del genere, che questa architettura JAMstack non è arrivata al punto in cui è sempre particolarmente efficiente ricostruirlo staticamente. Quindi, il pensiero va: "Allora non farlo". Lascia che quella parte si idrati in modo naturale con... attiva le funzioni serverless e ottieni i dati di cui ha bisogno e fai tutto questo. Ma il resto del sito, che non è... non ci sono tante pagine, non ci sono tanti dati, potresti fare un pre-rendering o altro. Quindi un po' di entrambi.

Drew: Ovviamente, molte persone hanno a che fare con sistemi legacy che... qualche vecchio database costruito negli anni 2000 che potrebbero essere in grado di incollare una sorta di livello API JSON sopra...

Chris: Sì.

Drew: … e costruisci qualcosa di più moderno, e forse serverless, e poi interagisci ancora con quei sistemi legacy incollandoli del tutto in un modo strano.

Chris: Sì. Mi piace però, vero? Non lo sono... la maggior parte dei siti web esiste già. Quanti di noi sono siti web totalmente green? La maggior parte di noi lavora su qualche merda che esiste già che deve essere trascinata nel futuro per qualche motivo, perché non lo so, gli sviluppatori vogliono lavorare più velocemente, o non puoi più assumere nessuno in COBOL, o qualunque sia la storia è. Sai?

Drew: Per quanto riguarda la terminologia, stiamo parlando di JAMstack che è questa metodologia per eseguire un codice praticamente nel browser, servendolo da una CDN. Quindi, non avere nulla di dinamico sul server. E poi, quando parliamo di serverless, parliamo di quei piccoli frammenti di funzionalità che girano sul loro server da qualche altra parte. È giusto? Che stavamo parlando di queste funzioni cloud tipo-

Chris: Sì, voglio dire, in questo momento sono entrambe idee interessanti. Quindi è abbastanza facile parlare dell'uno e parlare dell'altro. Ma non hanno necessariamente bisogno di stare insieme. Potresti eseguire un sito JAMstack che non ha nulla a che fare con qualsiasi cosa serverless. Lo stai solo facendo, pre-costruisci il sito ed eseguilo, e puoi usare serverless senza doverti preoccupare di JAMstack. In effetti, CodePen non fa nulla di JAMstack. Non che vogliamo parlare necessariamente di CodePen, ma è un'app Ruby on Rails. Funziona su un intero gruppo di istanze AWS EC2 e una varietà di altre architetture per realizzarlo. Ma usiamo materiale serverless ogni volta che possiamo per tutto ciò che possiamo, perché è economico e sicuro, ed è solo un bel modo di lavorare. Quindi, nessun JAMstack in uso ma serverless ovunque.

Drew: È piuttosto interessante. A che tipo di attività stai mettendo serverless su CodePen?

Chris: Beh, ci sono un sacco di cose. Uno di questi è, penso, si spera abbastanza ovvio è, ho bisogno ... il punto di CodePen è che scrivi ogni HTML, CSS e JavaScript nel browser e lo visualizza davanti a te, giusto? Ma puoi anche scegliere le lingue del preprocessore. Diciamo che ti piace Sass. Si attiva Sass nel CSS e si scrive Sass. Bene, qualcosa deve elaborare il Sass. Al giorno d'oggi, Sass è scritto in Dart o qualcosa del genere.

Chris: Teoricamente, potresti farlo nel client. Ma queste librerie che eseguono la pre-elaborazione sono piuttosto grandi. Non credo di volerti spedire l'intera libreria Sass, solo per eseguire quella cosa. Non voglio... è solo che non è, non è necessariamente l'architettura giusta per questo. Forse è in fondo alla strada, voglio dire, potremmo parlare di merda offline, yada, yada, Web Workers. Ci sono un milione di cose architettoniche che potremmo fare. Ma ecco come funziona ora, c'è una lambda. Elabora il Sass. Ha un piccolo, minuscolo, minuscolo, piccolo lavoro.

Chris: Gli mandi questo blob di Sass e ti rispedisce roba, che è il CSS elaborato, forse una mappa del sito, qualunque cosa. Ha un piccolo lavoro e probabilmente paghiamo per quella lambda, tipo quattro centesimi o qualcosa del genere. Perché le lambda sono semplicemente incredibilmente economiche e puoi anche martellarlo. Non devi preoccuparti della scala. Hai appena colpito quella cosa quanto vuoi e il tuo conto sarà sorprendentemente economico. Ci sono momenti in cui il serverless inizia a superare quella linea di essere troppo costoso. Non so cosa sia, non sono quel maestro di cose del genere. Ma in generale, qualsiasi cosa senza server che facciamo, fondamentalmente... contiamo quasi tutti come gratuiti, perché è così economico. Ma ce n'è uno per Sass. Ce n'è uno per Meno. Ce n'è uno per Babbel. Ce n'è uno per TypeScript. Ce n'è uno per... Tutti quelli sono singoli lambda che gestiamo. Ecco del codice, darlo a lambda, torna indietro e facciamo tutto ciò che vogliamo fare con esso. Ma lo usiamo per molto di più, anche di recente.

Chris: Ecco un esempio. Ogni singola penna su CodePen ha uno screenshot. È fantastico, vero? Quindi, le persone creano una cosa e quindi abbiamo bisogno di un PNG o di un JPEG, o qualcosa del genere, in modo che possiamo... in questo modo quando lo twitti, ne hai una piccola anteprima. Se lo condividi in Slack, ne ottieni una piccola anteprima. Lo usiamo sul sito stesso per il rendering... invece di un iframe, se potessimo rilevare che la penna non è animata, perché l'immagine di un iframe è molto più chiara, quindi perché non usare l'immagine? Comunque non è animato. Solo guadagni di prestazioni del genere. Quindi ognuno di quegli screenshot ha un URL, ovviamente. E l'abbiamo progettato in modo che quell'URL sia effettivamente una funzione serverless. È un lavoratore. E quindi, se quell'URL viene colpito, possiamo controllare molto rapidamente se abbiamo già preso quello screenshot o meno.

Chris: Ciò è effettivamente abilitato da CloudFlare Workers, perché CloudFlare Workers non è solo una funzione serverless, ma ha anche un archivio dati. Hanno questa cosa chiamata archivio chiave-valore, quindi l'ID di quello, possiamo semplicemente controllare molto velocemente e sarà "Vero o falso, ce l'hai o no?" Se ce l'ha, lo serve. E lo serve su CloudFlare, che è super veloce per cominciare. E poi ti dà anche tutta questa capacità. Poiché è un CDN di immagini, puoi dire: "Bene, servilo nel formato ottimale. Servitelo come queste dimensioni. Non devo fare l'immagine in quelle dimensioni. Basta inserire le dimensioni nell'URL e torna come quella dimensione, magicamente. Quindi è davvero bello. Se non ce l'ha, chiede un'altra funzione serverless per renderlo davvero veloce. Quindi lo farà e poi lo metterà in un secchio da qualche parte... perché devi avere un'origine per l'immagine, giusto? Di solito devi ospitarlo da qualche parte. Quindi lo mettiamo in un secchio S3 molto velocemente e poi lo serviamo.

Chris: Quindi non c'è un server di coda, non c'è niente. È come se le funzioni serverless gestissero la creazione, l'archiviazione e la pubblicazione di queste immagini. E ce ne sono tipo 50 o 80 milioni o qualcosa del genere. È molto, quindi lo gestisce come scala abbastanza bene. Semplicemente non lo tocchiamo nemmeno. Succede e basta. Succede tutto super veloce. Super bello.

Drew: Immagino che... beh, una funzione serverless si adatta idealmente a un'attività che richiede pochissima conoscenza dello stato delle cose. Voglio dire, hai menzionato la capacità di CloudFlare di archiviare coppie chiave-valore per vedere se hai già qualcosa nella cache o meno.

Chris: Sì. Questo è ciò che stanno cercando di risolvere, però, con quelli. Quelle coppie chiave-valore, è che... penso che tradizionalmente fosse vero. Dicono: "Evita lo stato nella cosa", perché proprio non puoi contare su di esso. E i lavoratori di CloudFlare dicono: "Sì, in realtà, puoi affrontare lo stato, in una certa misura". Non è elegante come un... non lo so, sono valori chiave, quindi è una chiave in un valore. Non è come una cosa di fantasia nidificata e relazionale. Quindi probabilmente ci sono dei limiti a questo. Ma questo è il giorno del bambino per questo. Penso che le cose si evolveranno per diventare più potenti, quindi hai una certa capacità di fare cose simili a uno stato.

Drew: E a volte la limitazione, quel tipo di capacità limitata di mantenere lo stato, o il fatto che non hai... non vuoi mantenere alcuno stato, ti spinge in un'architettura che ti dà questo tipo di... Beh, quando parliamo della filosofia software di “Small Pieces Loosely Joined”, vero?

Chris: Mm (affermativo).

Drew: Dove ogni piccolo componente fa una cosa e la fa bene. E non sa davvero del resto dell'ecosistema che lo circonda. E sembra che si applichi davvero a questo concetto di funzioni serverless. Sei d'accordo?

Chris: Sì. Penso che potresti avere un dibattito filosofico che sia una buona idea o meno. Sai? Penso che ad alcune persone piaccia il monolito, per così dire. Penso che sia possibile... ci sono modi per esagerare e fare troppe piccole parti che sono troppo difficili da testare del tutto. È bello avere un test del tipo: "Oh, mi chiedo se la mia funzione Sass funzioni. Bene, scriviamo un piccolo test e assicuriamoci che lo sia. Ma diciamo che ciò che conta per l'utente è una stringa di sette di questi. Come li testate tutti e sette insieme? Penso che la storia diventi un po' più complicata. Non so come parlare in modo super intelligente a tutte quelle cose, ma so che non è necessariamente così, se usi tutte le funzioni serverless, è automaticamente un'architettura migliore di qualsiasi altra architettura. Mi piace. Mi spiega bene, ma non so che sia la fine di tutte le architetture. Sai?

Drew: Per me, sembra estremamente simile al web, in quanto... questo è esattamente come funziona l'HTML, non è vero? Fornisci del codice HTML e il browser andrà quindi a recuperare le tue immagini, il tuo JavaScript e il tuo CSS. Sembra che sia un'espansione di quello -

Chris: È bello.

Drew: ... una specie di idea. Ma una cosa che sappiamo del web è che è progettato per essere resiliente perché la rete è fragile.

Chris: Mm (affermativo).

Drew: Quanto è robusto il tipo di approccio serverless? Cosa succede se qualcosa... se uno di quei piccoli pezzi scompare?

Chris: Sarebbe molto brutto. Sai? Sarebbe un disastro. Il tuo sito andrebbe in crash proprio come qualsiasi altro server, se succedesse, immagino.

Drew: Ci sono modi per mitigarlo, che sono in particolare...

Chris: Non lo so.

Drew: … adatto a questo tipo di approccio, che ti sei imbattuto?

Chris: Forse. Voglio dire, come ho detto, una cosa robusta davvero super elegante potrebbe essere come... diciamo che visiti CodePen e diciamo che c'è un'implementazione JavaScript di Sass e abbiamo notato che sei su una rete abbastanza veloce e che sei inattivo proprio adesso. Forse prenderemo quel JavaScript e lo getteremo in un addetto ai servizi. Quindi, se rileviamo che la lambda non riesce, o qualcosa del genere, o che questa cosa è già installata, colpiremo l'operatore del servizio anziché il lambda e gli operatori del servizio saranno in grado di lavorare offline. Quindi, anche questo è carino. Interessante. Voglio dire, sono la stessa lingua. I service worker sono JavaScript e molte funzioni Cloud sono JavaScript, quindi ci sono alcune... Penso che sia una possibilità, anche se... è solo, è una tecnica seria che... Mi spaventa solo avere questo pezzo di JavaScript che hai fornito a quante migliaia di utenti, che non sai necessariamente cosa hanno e quale versione hanno. Eww, ma è solo la mia stessa paura. Sono sicuro che alcune persone hanno fatto un buon lavoro con quel tipo di cose.

Chris: In realtà non lo so. Forse conosci alcune strategie che io non conosco, sulla resilienza del serverless.

Drew: Immagino che ci sia una modalità di errore, uno stile di errore, che potrebbe verificarsi con funzioni serverless, in cui esegui una funzione una volta e fallisce, e puoi eseguirla una seconda volta subito dopo e avrebbe successo, perché potrebbe colpire un server completamente diverso. O qualunque fosse il problema, quando quell'esecuzione potrebbe non esistere su una seconda richiesta. I problemi di un intero host che non funziona è una cosa, ma forse ci sono... hai problemi individuali con la macchina. Hai un server particolare in cui la sua memoria è andata male e sta generando un carico di errori e la prima volta che lo colpisci, fallirà. La seconda volta, quel problema potrebbe essere stato radicato.

Chris: Le aziende che tendono a offrire questa tecnologia, devi fidarti di loro, ma sono anche il tipo di aziende che... questo è il loro orgoglio. Questo è il motivo per cui le persone li usano perché sono affidabili. Sono sicuro che le persone potrebbero indicare alcune interruzioni di AWS del passato, ma tendono ad essere un po' rare e non molto comuni. Se stavi ospitando la tua merda, scommetto che ti hanno battuto da un livello percentuale SLA. Sai? Quindi non è come "Non costruire in modo resiliente", ma generalmente il tipo di aziende che offrono queste cose sono dannatamente affidabili. Le possibilità che tu vada giù perché hai rovinato quella funzione sono molto più alte che perché la loro architettura non funziona.

Drew: Suppongo, voglio dire, proprio come qualsiasi cosa in cui stai usando un'API o qualcosa che può fallire, è solo assicurarti di strutturare il tuo codice per far fronte a quella modalità di errore e per sapere cosa succede dopo, piuttosto che semplicemente lanciare fino a un errore per l'utente, o semplicemente morendo, o cosa hai. È esserne consapevoli e chiedere all'utente di riprovare. O riprovare te stesso, o qualcosa del genere.

Chris: Sì, mi piace l'idea di provare più di una volta, invece di dire semplicemente: "Oh no. Fallire. Interrompi”. "Non lo so, perché non provi di nuovo lì, amico?"

Drew: Quindi voglio dire, quando si tratta di test e sviluppo di funzioni serverless, una sorta di funzioni cloud, è qualcosa che può essere fatto localmente? Deve essere fatto nel cloud? Ci sono modi per gestirlo?

Chris: Penso che ci siano dei modi. Non so se la storia è così impressionante. È ancora un concetto relativamente nuovo, quindi penso che vada sempre meglio. Ma da quello che so, per prima cosa, stai scrivendo una funzione Node abbastanza normale. Supponendo che tu stia usando JavaScript per farlo, e so che su Lambda in particolare, supportano tutti i tipi di cose. Puoi scrivere una fottuta funzione PHP Cloud. Puoi scrivere una funzione Ruby Cloud. Quindi, so che sto parlando in particolare di JavaScript, perché ho la sensazione che la maggior parte di queste cose siano JavaScript. Anche indipendentemente dalla lingua, voglio dire, puoi andare alla tua riga di comando localmente ed eseguire la cosa. Alcuni di questi test sono... lo testi come faresti con qualsiasi altro codice. Basta chiamare la funzione localmente e vedere se funziona.

Chris: È una storia leggermente diversa quando parli di una richiesta HTTP ad essa, questa è la cosa che stai cercando di testare. Risponde correttamente alla richiesta? E restituisce la roba correttamente? Non lo so. La rete potrebbe essere coinvolta lì. Quindi potresti voler scrivere test a quel livello. Va bene. Non lo so. Qual è la storia normale lì? Fai girare una specie di server locale o qualcosa che lo serve. Usa Postman, non lo so. Ma c'è... Anche i Framework cercano di aiutare. So che il serverless ".com", che è solo terribilmente confuso, ma c'è letteralmente una società chiamata Serverless e creano un framework per scrivere le funzioni serverless che ti aiutano a distribuirle.

Chris: Quindi, se ti piace l'installazione serverless di NPM, ottieni il loro framework. Ed è ampiamente considerato molto buono, perché è semplicemente molto utile, ma non hanno il proprio cloud o altro. Li scrivi e poi ti aiuta a portarli su una vera lambda. Oppure potrebbe funzionare con più provider di servizi cloud. Non lo so nemmeno di questi tempi, ma il loro scopo di esistere è rendere più facile la storia del dispiegamento. Non so cosa... AWS non è famoso per la sua semplicità. Sai? C'è tutto questo mondo di strumenti per aiutarti a utilizzare AWS e loro sono uno di questi.

Chris: Hanno una specie di prodotto a pagamento. Non so nemmeno cosa sia esattamente. Penso che una delle cose che fanno sia... lo scopo del loro utilizzo è per il test, è quello di avere un ambiente di sviluppo che è per testare la tua funzione serverless.

Drew: Sì, perché suppongo che sia una parte piuttosto importante del flusso di lavoro, vero? Se hai scritto la tua funzione JavaScript, l'hai testata localmente, sai che farà il lavoro. 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: Sì. 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. Non lo so. 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. Whatever. 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. Sì.

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: Sì. 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: Sì. 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: Sì, sì. Penso di sì, penso che sia... perché ci sono momenti come... non devi essere tremendamente abile per sapere cosa è appropriato e cosa non lo è per un sito web. Ad esempio, ho fatto un piccolo tutorial l'altra settimana, dove c'era questo problema tecnico che usa questi... quando salvi un problema tecnico, ti danno una lumaca per la tua cosa che hai costruito, cioè "Whiskey, tango, foxtrot. 1.000”. È come una piccola cosa intelligente. Le possibilità che sia unico sono altissime, perché penso che ci aggiungano anche un numero o qualcosa del genere. Ma finiscono per essere queste piccole cose divertenti. Fanno open source la loro libreria che contiene tutte quelle parole, ma è come cento, migliaia di parole. Il file è enorme. Sai? È un megabyte grande solo per un dizionario di parole. Probabilmente imparerai nel tuo primo anno di sviluppo: "Non spedire un file JavaScript che è megabyte di un dizionario". Non è una buona cosa spedire. Sai? Ma a Nodo non importa. Puoi spedirne centinaia. È irrilevante per la velocità su un server.

Drew: Sì.

Chris: Non importa su un server. Quindi, potrei dire "Hmm, beh, allora lo farò in Node". Avrò una dichiarazione che dice: "Parole uguali richiedono parole" o qualsiasi altra cosa, e una nota in alto, "Fai in modo che randomizzi un numero. Tiralo fuori dall'array e restituiscilo. Quindi quella funzione serverless è composta da otto righe di codice con un packaged@JSON che estrae questa libreria open source. E poi il mio codice front-end, c'è un URL per la funzione serverless. Colpisce quell'URL. L'URL restituisce una parola o un gruppo di parole o altro. Costruisci la tua piccola API per questo. E ora, ho una cosa davvero carina ed efficiente. La cosa bella è che è così semplice. Non sono preoccupato per la sua sicurezza. Io non... sai?

Chris: È solo che... uno sviluppatore JavaScript molto mediocre o principiante, penso, può farcela, il che è fantastico. Questa è una cosa abilitante che non avevano prima. Prima dicevano "Beh, ecco una serie di parole da 2 MB". "Oh, non posso spedirlo al cliente." "Oh, allora ti fermerai." Potresti colpire questo muro dicendo: "Non posso proprio fare quella parte allora. Ho bisogno di chiedere a qualcun altro di aiutarmi o semplicemente di non farlo o di scegliere lumache più noiose o altro…” È solo che devi andare in un altro modo che sia un muro per te, perché non potresti farlo. E ora sei: "Oh, beh, lo farò solo..." Invece di averlo nella mia barra dello script o nella mia cartella degli script della barra di origine, lo metterò invece nella mia cartella delle funzioni.

Chris: Ti piace spostare lo script da una cartella all'altra. E quello viene invece distribuito come funzione serverless. Quant'è fico? Sai? Stai usando lo stesso set di abilità, quasi. Ci sono ancora alcuni spigoli, ma è abbastanza vicino.

Drew: È fantastico. Hai messo insieme una specie di piccolo micro sito tutto su queste idee, vero?

Chris: Sì. Ero un po' in anticipo per la partita. Ci stavo solo lavorando oggi, però, perché... riceve richieste pull. L'idea... beh, è ​​su serverless.css-tricks.com e... a proposito, c'è un trattino in CSS-Tricks. Quindi è un sottodominio di CSS-Tricks, e l'ho creato anche senza server, quindi questo è... CSS-Tricks è come un sito WordPress, ma questo è un sito generatore di siti statici. Tutto il contenuto è nel repository GitHub, che è open source. Quindi, se vuoi cambiare il contenuto del sito, puoi semplicemente inviare una richiesta di sondaggio, il che è bello perché ce ne sono stati un centinaio nel tempo. Ma ho costruito tutto il contenuto originale.

Drew: È un posto super utile, perché elenca... Se stai pensando "Va bene, voglio iniziare con le funzioni serverless", elenca tutti i provider che potresti provare e...

Chris: Questo è tutto, praticamente, sono elenchi di tecnologia. Sì.

Drew: Il che è fantastico, perché altrimenti stai solo cercando su Google qualsiasi cosa e non sai cosa stai trovando. Sì, sono elenchi di fornitori di API che ti aiutano a fare questo genere di cose.

Chris: Forms ne è un esempio, perché... quindi nel momento in cui scegli di... diciamo, andrai a JAMstack, che so che non è necessariamente il punto di questo, ma vedi come sono mano nella mano . All'improvviso, non hai un file PHP o altro con cui elaborare quel modulo. Come si creano moduli su un sito JAMstack? Bene, ci sono molti modi per farlo. Tutti e la loro sorella vogliono aiutarti a risolvere quel problema, a quanto pare. Quindi penso che se fossi stato l'inventore della parola JAMstack, quindi cercano di aiutarti in modo naturale, ma non devi usarli.

Chris: In effetti, sono stato così sorpreso di mettere insieme questo sito. Vediamo. Ci sono sei, nove, dodici, quindici, diciotto, ventuno, ventidue servizi là fuori che vogliono aiutarti a elaborare senza server i tuoi moduli su questo sito in questo momento. Se vuoi essere il 23esimo, sei il benvenuto, ma c'è un po' di concorrenza là fuori. Quindi l'idea alla base di questo è che si scrive un modulo in HTML, come letteralmente un elemento del modulo. E poi l'attributo action del modulo, non può puntare da nessuna parte internamente, perché non c'è niente a cui puntare. Non puoi elaborare, quindi punta all'esterno. Indica tutto ciò a cui vogliono che tu lo indichi. Elaboreranno il modulo e quindi tenderanno a fare le cose che ti aspetteresti, come inviare una notifica via email. O invia una cosa Slack. Oppure invialo a Zapier e Zapier lo invierà da qualche altra parte. Hanno tutti set di funzionalità, prezzi e cose leggermente diversi, ma stanno tutti cercando di risolvere quel problema per te, come "Non vuoi elaborare i tuoi moduli? Nessun problema. Lo elaboreremo per te".

Drew: Sì, è una risorsa super utile. Consiglio davvero a tutti di dare un'occhiata. È serverless.css-tricks.com. Quindi, ho imparato tutto sul serverless. Cosa stai imparando ultimamente, Chris?

Chris: Beh, anch'io sono ancora molto in questo mondo e sto imparando cose senza server. Ho avuto un'idea di... giocavo a questo gioco di ruolo online secoli fa. Ho appena scoperto di recente che è ancora vivo. È un tipo di gioco fantasy medievale basato su testo. Ci ho giocato quando AOL era una cosa, perché AOL voleva avere questi giochi a cui dovevi essere connesso per giocarci, perché volevano che passassi ore e ore su AOL, così potevano inviarti questi enormi conti, il che era , sono sicuro, perché ad un certo punto hanno fatto così bene.

Drew: Quindi fatturazione al secondo. Sì.

Chris: Sì. Quindi i giochi erano grandi per loro. Se potessero farti giocare con altre persone lì dentro. Quindi questo gioco in un certo senso... non ha debuttato lì, ma è passato ad AOL, perché sono sicuro che hanno ottenuto un affare succoso, ma era così... voglio dire, è solo che non potrebbe essere più nerd. Sei un mago nano e ottieni il bastone delle rune dal tuo fodero di cuoio. E digiti i comandi come un terminale. Poi il gioco ti risponde. Ho giocato a quel gioco per molto tempo. Ero molto coinvolto. Sono entrato nella comunità di esso e nel suo spirito. Era una specie di... era come se fossi solo da solo davanti al mio computer, eppure guardo indietro a quel periodo della mia vita e penso: "Quello è stato un periodo meraviglioso della mia vita". Ero davvero... mi piacevano le persone, il gioco e tutto il resto. Ma poi sono cresciuto e ho smesso di suonarlo, perché la vita ti succede.

Chris: L'ho scoperto solo di recente, perché qualcuno ha ricominciato a fare un podcast sull'argomento... Non so come l'ho scoperto, ma l'ho fatto e basta. Ero tipo, "Questo gioco è vivo e vegeto nel mondo di oggi, mi stai prendendo in giro? Questa cosa basata sul testo. E sono stato più che felice di riattivare e riavere i miei vecchi personaggi e giocarci. Ma solo per scoprire che i client che hanno scaricato per questo gioco non si sono evoluti affatto. Sono orribili. Presumono quasi che tu stia usando Windows. Ci sono solo questi rendering scadenti e terribilmente scadenti ... ed è basato sul testo, pensi che almeno avrebbe una bella tipografia. No. Quindi sono tipo, “Potrei essere coinvolto. Potrei scrivere un client per questo gioco. Mettici una bella tipografia. " Basta modernizzare la cosa e penso che i giocatori del gioco lo apprezzerebbero, ma per me è stato travolgente. "Come posso farlo?" Ma trovo alcuni progetti open source. Uno di questi è come... puoi giocare attraverso una vera finestra di terminale e utilizza alcune librerie open source per creare una sorta di GUI da una finestra di terminale.

Drew: Davvero?

Chris: Non lo so. Quindi è stato fantastico. Ero tipo: "Se l'hanno scritto, ci deve essere del codice su come connettersi al gioco e far funzionare tutto e cose del genere. Quindi almeno ho un codice di avviamento. Stavo cercando di seguire l'app, "Forse lo farò in Flutter o qualcosa del genere", in modo che l'app del prodotto finale funzioni sui telefoni cellulari e, "Potrei davvero modernizzare questa cosa". Ma poi sono stato sopraffatto. Ero tipo, “Ah, questo è troppo grande... non posso. Sono occupato." Ma ho trovato un'altra persona che aveva la stessa idea ed erano molto più avanti con essa, quindi potevo semplicemente contribuire a livello di progettazione. Ed è stato davvero divertente lavorare su, ma ho anche imparato molto, perché è raro per me entrare in un progetto che è figlio di qualcun altro, e sto solo contribuendo un po', e questo è completamente diverso scelte tecnologiche di quelle che avrei mai scelto.

Chris: È un'app Electron. Hanno scelto quello, che è anche un bel modo di andare, perché sono le mie abilità nel web... quindi non sto imparando niente di troppo strano, ed è multipiattaforma, il che è fantastico. Quindi, ho imparato molto su Electron. Penso che sia divertente.

Drew: È affascinante. È sempre sorprendente come i piccoli progetti collaterali e le cose che facciamo per divertimento, finiscano per essere il luogo in cui a volte impariamo di più. E apprendere abilità che possono poi essere reintrodotte nel nostro tipo di lavoro quotidiano.

Chris: Questo è l'unico modo in cui imparo le cose. Sono stato trascinato in qualcosa che... ero tipo "Non sono..." Viene renderizzato con una libreria JavaScript chiamata Mithril, che è... non so se ne hai mai sentito parlare, ma è strano. Non è... è quasi come scrivere React senza JSX. Devi "creare elementi" e fare tutto questo... ma dovrebbe fare un benchmark molto meglio di così... E in realtà è un po' importante perché in questo gioco basato su testo, il testo vola. C'è un sacco di manipolazione dei dati, che è come... penseresti che questo gioco basato su testo sarebbe così facile da eseguire per una finestra del browser, ma in realtà non è così. C'è così tanta manipolazione dei dati in corso, che devi essere davvero... dobbiamo essere coscienziosi riguardo alla velocità del rendering. Sai?

Drew: È affascinante-

Chris: Abbastanza bello.

Drew: Sì. Se tu, caro ascoltatore, vorresti sentire di più da Chris, puoi trovarlo su Twitter, dove è @chriscoyier. Naturalmente, CSS-Tricks può essere trovato su css-tricks.com e CodePen su codepen.io. Ma soprattutto, ti consiglio di iscriverti al podcast ShopTalk Show, se non l'hai già fatto, su shoptalkshow.com. Grazie per esserti unito a noi oggi, Chris. Hai qualche parola d'addio?

Chris: Smashingpodcast.com. Spero che sia il vero URL.