Smashing Podcast Episodul 22 cu Chris Coyier: Ce este serverless?

Astăzi, vorbim despre arhitecturile Serverless. Ce înseamnă asta și cum diferă de modul în care am putea construi site-uri în prezent? Am vorbit cu Chris Coyier pentru a afla.

Afișați note

• Microsite-ul lui Chris Puterea serverelor pentru dezvoltatorii front-end
• Chris pe Twitter
• Podcast ShopTalk Show

Actualizare săptămânală

• „Configurarea Redux pentru utilizare într-o aplicație din lumea reală”,
  de Jerry Navi
• „Poți crea un site web pentru cele cinci simțuri?”
  de Suzanne Scacca
• „Crearea unui blog static cu Sapper și Strapi”,
  de Daniel Madalitso Phiri
• „Un ghid practic pentru tururile de produse în aplicațiile React”,
  prin Binecuvântarea Krofegha
• „Cum să creez un Porsche 911 cu schiță”,
  de Nikola Lazarevic

Transcriere

Drew McLellan: Este un designer și dezvoltator web pe care poate îl cunoașteți de la CSS-Tricks, un site web pe care l-a început acum mai bine de 10 ani și care rămâne o resursă de învățare fantastică pentru cei care construiesc site-uri web. El este co-fondatorul CodePen, locul de joacă de codare bazat pe browser și comunitatea folosită de front-enders din întreaga lume pentru a împărtăși ceea ce fac și pentru a găsi inspirație de la cei pe care îi urmăresc. Alături de Dave Rupert este co-gazda ShopTalk Show, un podcast despre crearea de site-uri web. Așa că știm că știe multe despre dezvoltarea web, dar știai că odată a câștigat un concurs de mâncare de hot dog folosind doar farmecul lui? Prietenii mei zdrobitori, vă rog bun venit lui Chris Coyier. Buna Chris, ce mai faci?

Chris Coyier: Hei, sunt zdrobitor.

Drew: Am vrut să vă vorbesc astăzi, nu despre CodePen și nu vreau să vă vorbesc neapărat despre CSS-Tricks, care este una dintre acele resurse uimitoare despre care sunt sigur că toată lumea știe că apare chiar în fruntea Google Rezultatele căutării atunci când căutați răspunsuri la orice întrebare despre dezvoltatori web. Up îți iese fața și există o postare utilă pe blog scrisă de tine sau de unul dintre invitații tăi.

Chris: Oh, chiar făceam asta. A existat o... Nu știu, probabil a fost pe vremea când Google avea acea rețea socială ciudată. Ce a fost asta? Google Plus?

Drew: Oh, în plus, da.

Chris: Da, unde ar asocia un site web cu un cont Plus și astfel contul meu Plus avea un avatar, iar avatarul eram eu, așa că apărea în rezultatele căutării. Cred că acele zile au trecut. Cred ca daca tu...

Drew: Cred că da, da-

Chris: Da.

Drew: Dar am vrut să vă vorbesc despre ceva care a fost puțin mai mult un fel de interes secundar al dvs. și acesta este acest concept de arhitecturi fără server.

Chris: Mm (afirmativ).

Drew: Acesta este ceva despre care ai învățat mai multe de ceva vreme. Este corect?

Chris: Da, da. Sunt doar un fan. Pare o potrivire firească cu evoluția dezvoltării front-end, care este locul în care simt că am, cel puțin, ceva expertiză. Mă consider mult mai mult un... mult mai util pe front-end decât pe back-end, nu că eu... fac asta în toate zilele astea. Sunt destul de mult timp încât să nu mă tem să mă uit la un mic cod Ruby, asta e sigur. Dar prefer front-end-ul. L-am studiat mai mult. Am participat mai mult la proiecte la acel nivel și apoi apare acest tip de nouă paradigmă care spune: „Puteți să vă folosiți abilitățile JavaScript pe server”, și este interesant. Tu stii? Așa gândesc eu. Există mult mai mult decât atât, dar de aceea îmi pasă, este pentru că simt că este ca și cum dezvoltatorii front-end au săpat atât de adânc în JavaScript. Și acum putem folosi același set de abilități în altă parte. Mm, destul de tare.

Drew: Se pare că s-a deschis o lume cu totul nouă, în timp ce dacă ai fi doar un codificator front-end... Eu zic, doar un codificator front-end, n-ar trebui. Dacă sunteți un codificator front-end și sunteți obișnuit să lucrați cu un coleg sau un prieten pentru a vă ajuta cu implementarea back-end, brusc s-a deschis. Și este ceva pe care îl poți gestiona singur mai mult din întreaga stivă.

Chris: Da, da. Asta e.

Drew: Adresându-mă elefantului din cameră, chiar în partea de sus. Vorbim despre serverless și, evident, numirea lucrurilor este greu. Toti stim asta. Arhitectura serverless nu înseamnă că nu există servere, nu-i așa?

Chris: Cred că este obligatoriu, de parcă acesta este primul podcast pe care îl auzi, sau în primul... auzi cuvântul „fără server” doar în primele duzini de ori când l-ai auzit, este obligatoriu ca tu au o reacție viscerală și au acest tip de „Oh, dar mai există servere.” Este în regulă. Dacă ți se întâmplă asta chiar acum, știi doar că, acesta este un pas necesar în acest sens. Este ca orice altceva în viață. Există etape pentru înțelegere. Prima dată când auzi ceva, ți se cere să-l respingi puțin și apoi abia după o duzină de ori sau cam așa ceva, sau după ce ți se dovedește puțin că merită, ajungi să intri în etapele ulterioare. de înțelegere aici. Dar cuvântul a câștigat, așa că dacă tot lupți împotriva cuvântului „fără server”, nu-mi place să vă spun că trenul a părăsit gara de acolo. Cuvântul are deja succes. Nu vei câștiga asta. Deci, scuze.

Chris: Dar cred că este interesant că... începe să fie ca, poate, uneori, de fapt, nu sunt servere implicate. Aș crede că unul dintre lucrurile care au blocat serverless ca concept a fost AWS Lambda. Au fost cam primii la fața locului. O lambda este ca o funcție pe care o dați lui AWS și o pune în cerul magic și apoi... are o adresă URL și o puteți apăsa și va rula acea funcție și va returna ceva dacă doriți. Tu stii? Este doar HTTP sau orice altceva. Așa funcționează, care... prima dată când auzi asta, te gândești: „De ce? nu-mi pasă.” Dar apoi, sunt câteva lucruri evidente. Ar putea cunoaște cheile mele API la care nimeni altcineva nu are acces. De aceea, rulați back-end pentru început, este că știe lucruri secrete care nu trebuie să fie în JavaScript pe partea clientului. Deci, dacă trebuie să vorbească cu o bază de date, poate face asta. Poate face acest lucru în siguranță, fără a fi nevoit să expună cheile API în altă parte. Sau chiar unde sunt acele date sau cum le obțin, este...

Chris: Deci, e destul de tare. Pot scrie o funcție care vorbește cu o bază de date, pot obține niște date, returnează asta. Misto. Deci, Lambda este asta, dar AWS funcționează. Trebuie să alegi o regiune. Ești de genul: „Nu știu. Unde ar trebui să fie, Virginia? Oregon? Ar trebui să-l aleg pe cel din Australia? Nu știu." Au 20, 30. Nici nu știu câți au zilele astea, dar până și lambda aveau regiuni. Cred că în zilele noastre au Lambda@Edge, ceea ce înseamnă că sunt toate regiunile, ceea ce este cam misto. Dar ei au fost primii, iar acum toată lumea are ceva ca Lambda. Toate serviciile cloud. Ei vor un fel de serviciu pe lumea asta. Unul dintre ele este CloudFlare. CloudFlare are lucrători. Au mult mai multe locații decât are AWS, dar au executat-o ​​într-un fel și într-un moment diferit... așa cum un lucrător CloudFlare... este similar cu un lambda în care poți rula Node. Puteți rula JavaScript. Puteți rula și o serie de alte limbi, dar... Mă gândesc la aceste lucruri în mare măsură, cel mai interesant limbaj este JavaScript, doar din cauza prevalenței acestuia.

Chris: Se întâmplă doar la nivel de CDN, care cred că este un server, dar tind să nu mă gândesc la CDN-uri ca la un server. Nu la fel de evident ca altceva. Începe să se simtă și mai fără server în ultima vreme. Este un CDN un server? Adică, cred că este un computer undeva, dar se simte ca și mai puțin server-y.

Drew: Se pare că, da, un CDN poate fi un server, dar este cea mai variată versiune minimă a unui server. Este ca un server subțire, dacă vrei.

Chris: Da. Sigur.

Drew: Bine. Am auzit că s-a spus... Din păcate, nu-mi amintesc sursa de credit, dar am auzit că serverless este descris ca fiind „ca folosirea unui serviciu de partajare a călătoriei precum Uber sau Lyft” sau orice altceva. Poți să fii fără mașină și să nu deții o mașină, dar asta nu înseamnă că nu folosești niciodată o mașină.

Chris: Da, asta nu înseamnă că mașinile nu există. Mm, asta e frumos.

Drew: Doar chemați unul când aveți nevoie, dar, în același timp, nu plătiți costul inițial de achiziție al unei mașini. Nu plătiți întreținere sau combustibil sau...

Chris: Corect, și prețul are sens, de asemenea, nu? Este frumos. Asta e o analogie frumoasă, cred. Și apoi, pentru că este și la nivel CDN, doar interceptează cererile HTTP care au loc deja, ceea ce înseamnă că nu o întrebi... nu îi trimiți o cerere și trimite o solicitare înapoi. Se întâmplă în mod natural în timpul solicitării, ceea ce face, de asemenea, să se simtă mai puțin server-y. Nu stiu, e interesant. Este interesant cu siguranță. Deci este o mare problemă, totuși, că ai adus în discuție chestia cu prețurile. Că plătești doar pentru ceea ce folosești. Și asta este semnificativ, pentru că... să spunem că ești un dezvoltator back-end, care a obișnuit să creeze servere toată viața. Și ei conduc costurile, „Am nevoie de acest tip de server cu acest tip de memorie și acest tip de procesor și astfel de specificații. Și asta este cât de mult va costa.” Serverless vine și taie capul din acel preț.

Chris: Așadar, chiar dacă ești un dezvoltator back-end căruia pur și simplu nu-i place asta atât de mult, că pur și simplu nu îi place, de parcă setul tău de abilități este exact ceea ce este de-a lungul anilor, compari prețul iar tu spui: „Ce? Aș putea plăti 1% din ceea ce plăteam înainte?” Nu ai voie să nu-ți pese de asta, nu? Dacă ești acest dezvoltator back-end care plătește de o sută de ori mai mult pentru serviciile lor decât trebuie să plătească, atunci ești cam prost la locul tău de muncă. Imi pare rau sa spun. Acest lucru a apărut și a distrus prețurile în multe feluri. Trebuie să-ți pese de asta. Și e cam grozav să fie altcineva... Nu e ca și cum nu trebuie să-ți faci griji cu privire la securitate, dar nu este serverul tău. Nu aveți... funcția dvs. lambda sau cloud, sau lucrătorul dvs., sau orice altceva, nu se află pe un server care este chiar lângă niște date cu adevărat sensibile din propria rețea. Nu este chiar lângă baza ta de date.

Chris: Dacă cineva scrie cod care încearcă cumva să se ejecteze de la lucrător sau lambda, sau orice altceva, și încearcă să aibă acces la alte lucruri în calea lui, nu există nimic de găsit. Deci și securitatea este o mare problemă, așa că din nou, dacă asta este treaba ta ca administrator de server, este să te ocupi de securitatea acestui lucru. Rulându-l, rulând anumite lucruri în Lambda, obțineți doar o siguranță naturală din el, ceea ce este grozav. Deci, este mult mai ieftin. Este mult mai sigur. Încurajează aceste mici arhitecturi modulare, ceea ce poate fi o idee bună. Pare să fie domino după domino de idei bune aici. De aceea este notabil. Tu stii?

Drew: Da, vreau să spun, în mod tradițional, cu o arhitectură bazată pe server pe care o rulăm de zeci de ani pe web, aveți un server web pe care îl conduceți singur. Acesta deține codul dumneavoastră front-end, codul back-end, baza de date și tot. Apoi, trebuie să-l mențineți și să-l mențineți în funcțiune și să plătiți facturile și, chiar dacă nu este folosit, este acolo pentru a înregistra facturile. Utilizatorul ar face o solicitare și ar construi toate acele chestii de interogare HTML din baza de date, le-ar trimite pe toate în continuare către browser. Acest proces funcționează. Așa sunt construite o mulțime de lucruri. Este probabil cea mai mare parte a modului în care este construit web-ul. Așa funcționează lucruri precum WordPress. Este aceasta cu adevărat o problemă pe care trebuie să o rezolvăm? Adică, am vorbit puțin despre costuri. Care sunt celelalte probleme cu asta, pe care trebuie să le rezolvăm și cu care ne-ar putea ajuta fără server?

Chris: Da, problemele cu abordarea vechii școli. Da, nu știu, poate că nu există. Adică, nu spun că întregul web trebuie să-și schimbe întregul... totul peste noapte. Nu știu. Poate că nu chiar, dar cred că deschide uși. Se pare că, atunci când ideile bune ajung așa, ele schimbă încet modul în care funcționează web-ul. Deci, dacă există un CMS care este construit într-un fel care se așteaptă ca o bază de date să fie acolo, înseamnă că poate gazdele viitorului vor începe să folosească acest lucru în moduri interesante. Poate că vi se pare că este încă doar un server tradițional, dar gazdele înșiși l-au dezvoltat, cum funcționează, la arhitecturi fără server. Deci nici nu știi cu adevărat că asta se întâmplă, dar au găsit o modalitate de a-și reduce costurile găzduind lucrurile de care ai nevoie în moduri fără server. Poate că da nici nu trebuie să-i pese ca dezvoltator, dar la nivel meta, asta se întâmplă. Pot fi. Nu știu.

Chris: De asemenea, nu înseamnă că... Bazele de date sunt încă acolo. Dacă se dovedește că a avea o bază de date relațională din punct de vedere arhitectural este modalitatea corectă de a stoca acele date, grozav. Menționez asta pentru că această lume Serverless crește în același timp cu JAMstack. Și JAMstack este această arhitectură care spune: „Ar trebui să vă serviți site-ul pe gazde statice, care nu rulează nimic, cu excepția...” Sunt ca niște mici CDN-uri. Ei spun: „Nu pot face nimic. Nu rulez PHP. Eu nu o conduc pe Ruby. nu alerg nimic. Rulez pe un server web mic, care este conceput doar pentru a servi numai fișiere statice.”

Chris: „Și atunci, dacă trebuie să faceți mai mult decât atât, dacă trebuie să extrageți date dintr-o bază de date relațională, atunci vă rugăm să faceți-o la un alt moment, nu la ora serverului. Puteți fie să o faceți într-un proces de construire din timp și să scoateți acele lucruri din baza de date, să pre-construiți fișiere statice și le voi servi, sau să faceți acest lucru în timpul execuției.” Înseamnă că obțineți acest shell a unui document și apoi face o solicitare JavaScript pentru a obține niște date și apoi le completează în prealabil. Așa că o faci înainte sau după timp, dar asta nu înseamnă „Nu utilizați o bază de date relațională”. Înseamnă doar, „Serverul nu îl generează în momentul solicitării documentului”, ceea ce este un... Nu știu, este un pic o schimbare de paradigmă.

Chris: Nu este vorba doar de JAMstack. De asemenea, trăim în timpul cadrelor JavaScript. Trăim într-o perioadă în care începe să fie puțin mai așteptat că modul în care pornește o aplicație JavaScript este că montează unele componente și, pe măsură ce se montează acele componente, solicită datele de care are nevoie. Așadar, poate fi o potrivire naturală ca ceva de genul unui site web React să fie de genul „Ei bine, voi apăsa o funcție fără server pentru a obține datele de care are nevoie. În esență, atinge unele API JSON. Obțin datele JSON de care am nevoie și mă construiesc din acele date, apoi redau pe pagină.” Acum, fie că este bine sau rău pentru web, este ca „Nu știu. Pacat. Nava a navigat. Așa mulți oameni construiesc șantiere.” Sunt doar lucruri redate de client. Deci, JavaScript fără server și modern merg mână în mână.

Drew: Presupun că nu trebuie să te uiți la o arhitectură sau alta. Există o zonă în mijloc în care părți ale unei infrastructuri ar putea fi mai tradiționale, iar părțile ar putea fi fără server, bănuiesc?

Chris: Da. Ei bine, oricum încearcă să-ți spună asta. Oricine vrea să-ți vândă orice parte a arhitecturii lor spune: „Nu trebuie să cumperi chiar acum. Doar fă-o puțin.” Pentru că, desigur, vor să vă înmuiați degetul de la picior în orice vând, pentru că odată ce ați înmuiat degetul de la picior, șansele să vă stropiți în piscină sunt mult mai mari. Deci, cred că... nu este o minciună, totuși, neapărat, deși găsesc puțin mai puțin noroc în... Nu vreau ca stack-ul meu să fie un pic din tot. Cred că există o moarte tehnică acolo pe care nu vreau să o înghit întotdeauna.

Drew: Mm (afirmativ).

Chris: Dar se poate. Cred că cel mai citat este... să presupunem că am un site care are un element de comerț electronic, ceea ce înseamnă... și să spunem comerțul electronic la scară largă, deci 10.000 de produse sau ceva, că această arhitectură JAMstack nu a ajuns la punctul în care care este întotdeauna deosebit de eficient pentru a reconstrui asta static. Deci, gândul spune: „Atunci nu”. Lăsați acea parte să se hidrateze în mod natural cu... accesați funcțiile fără server și obțineți datele de care are nevoie și faceți toate astea. Dar restul site-ului, care nu este... nu sunt atât de multe pagini, nu sunt atât de multe date, ai putea să faci pre-rendare sau orice altceva. Deci un pic din ambele.

Drew: Desigur, mulți oameni au de-a face cu sisteme moștenite care... ceva vechi de baze de date care a fost construit în anii 2000, pe care ar putea să lipească un fel de strat API JSON deasupra...

Chris: Da.

Drew: … și construiește ceva mai modern, și poate fără server, și apoi interacționează în continuare cu acele sisteme moștenite, lipindu-le într-un mod ciudat.

Chris: Da. Imi place totusi, nu-i asa? Nu sunt... majoritatea site-urilor web există deja. Câți dintre noi suntem site-uri web care respectă totalitatea? Cei mai mulți dintre noi lucrăm la niște prostii care există deja și care trebuie să fie târâte în viitor dintr-un motiv oarecare, pentru că nu știu, dezvoltatorii vor să lucreze mai repede sau nu mai poți angaja pe nimeni în COBOL, sau orice ar fi povestea. este. Tu stii?

Drew: Deci, din punct de vedere terminologic, vorbim despre JAMstack, care este această metodologie de a rula un cod aproape în browser, servindu-l dintr-un CDN. Deci, să nu aibă nimic dinamic pe server. Și atunci când vorbim despre serverless, vorbim despre acele mici părți de funcționalitate care rulează pe serverul lor în altă parte. Este corect? Că vorbeam despre aceste funcții de cloud cam...

Chris: Da, vreau să spun, se întâmplă să fie ambele idei fierbinți chiar acum. Așa că este ușor să vorbești despre unul și despre celălalt. Dar nu trebuie neapărat să fie împreună. Ai putea rula un site JAMstack care nu are nimic de-a face cu nimic fără server. Doar o faci, doar pre-creezi site-ul și îl rulezi și poți folosi serverless fără a fi nevoie să-ți pese de JAMstack. De fapt, CodePen nu face nimic JAMstack. Nu că vrem să vorbim neapărat despre CodePen, dar este o aplicație Ruby on Rails. Funcționează pe o mulțime de instanțe AWS EC2 și pe o varietate de alte arhitecturi pentru a face acest lucru. Dar folosim lucruri fără server ori de câte ori putem pentru orice putem, pentru că sunt ieftine și sigure și doar o modalitate drăguță de a lucra. Deci, niciun JAMstack în uz deloc, dar fără server peste tot.

Drew: Este destul de interesant. Ce fel de sarcini puneți fără server pe CodePen?

Chris: Ei bine, sunt o grămadă de lucruri. Una dintre ele este, cred, sper că destul de evidentă este că am nevoie de... scopul CodePen este că scrii fiecare HTML, CSS și JavaScript în browser și îl redă în fața ta, nu? Dar puteți alege și limbi de pre-procesor. Să spunem că îți place Sass. Activați Sass în CSS și scrieți Sass. Ei bine, ceva trebuie să proceseze Sass. În zilele noastre, Sass este scris în Dart sau așa ceva.

Chris: Teoretic, ai putea face asta în client. Dar aceste biblioteci care fac preprocesare sunt destul de mari. Nu cred că vreau să-ți trimit întreaga bibliotecă Sass, doar pentru a rula chestia aia. Nu vreau să... pur și simplu nu este, nu este neapărat arhitectura potrivită pentru asta. Poate că este mai departe, adică am putea vorbi despre prostii offline, yada, yada, Web Workers. Sunt un milion de lucruri arhitecturale pe care le-am putea face. Dar iată cum funcționează acum, dacă există o lambda. Procesează Sass. Are o slujbă micuță, micuță, micuță.

Chris: Îi trimiți acest blob de Sass și îți trimite lucruri înapoi, care este CSS-ul procesat, poate o hartă a site-ului, orice ar fi. Are o slujbă mică și probabil că plătim pentru acea lambda, ca patru cenți sau ceva de genul. Pentru că lambda sunt doar incredibil de ieftine și poți să-l ciocănești și tu. Nu trebuie să vă faceți griji cu privire la scară. Doar ai lovit acel lucru cât de mult vrei și factura ta va fi uimitor de ieftină. Există momente în care serverless începe să treacă de linia de a fi prea scump. Nu știu ce este, nu sunt stăpânul unor astfel de lucruri. Dar, în general, orice lucruri pe care le facem fără server, practic... aproape toate sunt considerate gratuite, pentru că sunt atât de ieftine. Dar există unul pentru Sass. Există unul pentru Less. Există unul pentru Babbel. Există unul pentru TypeScript. Există unul pentru... Toate acestea sunt lambda individuale pe care le conducem. Iată un cod, dă-l lambda, se întoarce și facem tot ce vom face cu el. Dar îl folosim pentru mult mai mult decât atât, chiar și recent.

Chris: Iată un exemplu. Fiecare stilou pe CodePen are o captură de ecran. E cam misto, nu? Deci, oamenii fac un lucru și apoi avem nevoie de un PNG sau un JPEG, sau ceva din el, astfel încât să putem... în acest fel, atunci când îl tweetați, obțineți o mică previzualizare a acestuia. Dacă îl distribuiți în Slack, obțineți o mică previzualizare a acestuia. Îl folosim pe site-ul propriu-zis pentru a reda... în loc de un iframe, dacă am putea detecta că Pen-ul nu este animat, deoarece imaginea unui iframe este mult mai ușoară, așa că de ce să nu folosim imaginea? Oricum nu este animat. Doar câștiguri de performanță așa. Deci, fiecare dintre acele capturi de ecran are o adresă URL, evident. Și l-am proiectat astfel încât acea adresă URL să fie de fapt o funcție fără server. Este un muncitor. Și astfel, dacă acea adresă URL este accesată, putem verifica rapid dacă am făcut deja acea captură de ecran sau nu.

Chris: Acest lucru este de fapt activat de CloudFlare Workers, deoarece CloudFlare Workers nu sunt doar o funcție fără server, ci au și un depozit de date. Au acest lucru numit magazin cheie-valoare, așa că ID-ul acestuia, îl putem verifica foarte repede și va fi: „Adevărat sau fals, îl ai sau nu?” Dacă îl are, îl servește. Și îl servește peste CloudFlare, care este foarte rapid pentru început. Și apoi îți oferă toată această capacitate. Pentru că este un CDN de imagine, puteți spune: „Ei bine, serviți-l în formatul optim. Serviți-l ca aceste dimensiuni.” Nu trebuie să fac imaginea în acele dimensiuni. Doar puneți dimensiunile în adresa URL și revine la acea dimensiune, ca magic. Deci e foarte frumos. Dacă nu îl are, cere o altă funcție serverless pentru a-l face cu adevărat rapid. Așa că o va face și apoi o va pune într-o găleată undeva... pentru că trebuie să ai o origine pentru imagine, nu? De obicei, trebuie să-l găzduiești undeva. Așa că îl punem într-o găleată S3 foarte repede și apoi îl servim.

Chris: Deci nu există server de coadă, nu există nimic. Este ca și cum funcțiile fără server gestionează crearea, stocarea și difuzarea acestor imagini. Și sunt cam 50 de milioane sau 80 de milioane sau așa ceva. Este mult, așa că se descurcă destul de bine ca scară. Doar că nici măcar nu o atingem. Pur și simplu se întâmplă. Totul se întâmplă super rapid. Super dragut.

Drew: Bănuiesc că... ei bine, o funcție fără server se va potrivi în mod ideal unei sarcini care necesită foarte puține cunoștințe despre starea lucrurilor. Adică, ați menționat capacitatea CloudFlare de a stoca perechi cheie-valoare pentru a vedea dacă aveți deja ceva în cache sau nu.

Chris: Da. Totuși, asta încearcă să rezolve cu acelea. Acele perechi cheie-valoare sunt că... Cred că în mod tradițional era adevărat. Ei sunt de genul „Evitați starea în lucru”, pentru că pur și simplu nu vă puteți baza pe ea. Iar lucrătorii CloudFlare spun: „Da, de fapt, poți să faci față statului, într-o oarecare măsură.” Nu este la fel de elegant ca un... Nu știu, sunt valori cheie, deci este o cheie într-o valoare. Nu este ca o chestie de fantezie imbricată, relațională. Deci, probabil că există niște limite la asta. Dar pentru asta sunt zilele bebelușului. Cred că aceste lucruri vor evolua pentru a deveni mai puternice, așa că aveți o anumită capacitate de a face niște chestii de stat.

Drew: Și, uneori, limitarea, acel tip de capacitate limitată de a menține starea sau faptul că nu ai... nu vrei să menții nicio stare, te împinge într-o arhitectură care îți oferă acest tip de... Ei bine, când vorbim despre filozofia software-ului „Small Pieces Loosely Joined”, nu-i așa?

Chris: Mm (afirmativ).

Drew: Unde fiecare componentă mică face un lucru și îl face bine. Și nu știe cu adevărat despre restul ecosistemului din jurul lui. Și se pare că se aplică cu adevărat acestui concept de funcții fără server. Sunteți de acord?

Chris: Da. Cred că ai putea avea o dezbatere filozofică dacă aceasta este o idee bună sau nu. Tu stii? Cred că unora le place monolitul, parcă. Cred că este posibil... există modalități de a exagera cu asta și de a face prea multe piese mici care sunt prea greu de testat cu totul. Este plăcut să ai un test de genul „Oh, mă întreb dacă funcția mea Sass funcționează. Ei bine, hai să scriem un mic test pentru el și să ne asigurăm că este.” Dar să spunem, ceea ce contează pentru utilizator este un șir de șapte dintre acestea. Cum le testezi pe toate cele șapte împreună? Cred că povestea devine puțin mai complicată. Nu știu cum să vorbesc super inteligent cu toate chestiile astea, dar știu că nu este neapărat asta, dacă rulezi cu toate funcțiile fără server, aceasta este automat o arhitectură mai bună decât orice altă arhitectură. Imi place. Îmi raționează frumos, dar nu știu că este sfârșitul tuturor arhitecturilor. Tu stii?

Drew: Pentru mine, mi se pare extrem de web, în ​​sensul că... exact așa funcționează HTML, nu-i așa? Livrați ceva HTML, iar browserul va merge apoi și va prelua imaginile și va prelua JavaScript și va prelua CSS. Se pare că este o extindere a asta -

Chris: E frumos.

Drew: … un fel de idee. Dar, un lucru pe care îl știm despre web, este că este conceput pentru a fi rezistent, deoarece rețeaua este fragilă.

Chris: Mm (afirmativ).

Drew: Cât de robust este tipul de abordare fără server? Ce se întâmplă dacă ceva... dacă una dintre acele bucăți mici dispare?

Chris: Ar fi foarte rău. Tu stii? Ar fi un dezastru. Site-ul dvs. s-ar defecta la fel ca orice alt server, dacă se întâmplă să se defecteze, cred.

Drew: Există modalități de a atenua acest lucru, în special...

Chris: Nu stiu.

Drew: … potrivit pentru acest tip de abordare, pe care ai întâlnit-o?

Chris: Poate. Adică, așa cum am spus, o chestie foarte elegantă și robustă ar putea fi ca... să presupunem că vizitezi CodePen și să spunem că există o implementare JavaScript a Sass și am observat că ești într-o rețea destul de rapidă și că ești inactiv chiar acum. Poate că vom lua acel JavaScript și îl vom arunca într-un lucrător de service. Apoi, dacă detectăm că lambda eșuează, sau ceva, sau că aveți deja instalat acest lucru, atunci vom lovi lucrătorul de service în loc de lambda și lucrătorii de service vor putea lucra offline. Deci, e cam frumos și asta. Interesant. Adică, sunt în aceeași limbă. Lucrătorii de servicii sunt JavaScript și o mulțime de funcții Cloud sunt JavaScript, deci există câteva... Cred că este o posibilitate, deși asta... este doar, este ceva tehnic serios că... Mă sperie doar să am această bucată de JavaScript pe care ai furnizat-o la câte mii de utilizatori, că nu știi neapărat ce au și ce versiune au. Eww, dar asta e doar propria mea frică. Sunt sigur că unii oameni au făcut o treabă bună cu astfel de lucruri.

Chris: De fapt, nu știu. Poate că știți câteva strategii pe care eu nu le cunosc, despre reziliența fără server.

Drew: Bănuiesc că există un mod de eșec, un stil de eșec, care s-ar putea întâmpla cu funcțiile fără server, în care rulezi o funcție o dată și eșuează și o poți rula a doua oară imediat după aceea și ar reuși, pentru că s-ar putea să lovească un server complet diferit. Sau oricare ar fi problema, când acea rulare poate să nu existe la o a doua cerere. Problemele cu care o întreagă gazdă nu este în stare de funcționare este un lucru, dar poate că există... aveți probleme individuale cu mașina. Aveți un anumit server în care memoria sa s-a prost și aruncă o mulțime de erori, iar prima dată când îl lovești, va eșua. A doua oară, problema ar fi putut fi rezolvată.

Chris: Companiile care tind să ofere această tehnologie, trebuie să ai încredere în ele, dar se întâmplă să fie și genul de companii care... aceasta este mândria lor. Acesta este motivul pentru care oamenii le folosesc este pentru că sunt de încredere. Sunt sigur că oamenii ar putea indica unele întreruperi ale AWS din trecut, dar acestea tind să fie puțin rare și nu foarte comune. Dacă îți găzduiești propria prostie, pun pariu că te-au învins de la un nivel de procent SLA. Tu stii? Deci, nu este genul „Nu construiți într-un mod rezistent”, dar, în general, tipul de companii care oferă aceste lucruri sunt al naibii de fiabile. Șansele ca tu să scapi pentru că ai stricat această funcție sunt mult mai mari decât pentru că arhitectura lor eșuează.

Drew: Presupun, adică, la fel ca orice lucru în care utilizați un API sau ceva care poate eșua, este doar să vă asigurați că vă structurați codul pentru a face față acelui mod de eșec și pentru a ști ce se întâmplă în continuare, mai degrabă decât să aruncați o eroare pentru utilizator, sau doar pe moarte, sau ce ai tu. Este conștient de acest lucru și cere utilizatorului să încerce din nou. Sau să încerci din nou, sau ceva de genul ăsta.

Chris: Da, îmi place ideea de a încerca de mai multe ori, în loc să fiu doar „Oh, nu. Eșuează. Avorta.” „Nu știu, de ce nu încerci din nou acolo, amice?”

Drew: Deci, când vine vorba de testarea și dezvoltarea de funcții fără server, un fel de funcții cloud, este ceva ce poate fi făcut local? Trebuie făcut în cloud? Există modalități de a gestiona asta?

Chris: Cred că există câteva moduri. Nu știu dacă povestea este la fel de grozavă. Este încă un concept relativ nou, așa că cred că asta devine din ce în ce mai bine. Dar din câte știu, pentru un lucru, scrii o funcție Node destul de normală. Presupunând că utilizați JavaScript pentru a face acest lucru și știu că în special pe Lambda, acceptă tot felul de lucruri. Puteți scrie o funcțiune PHP Cloud Funcție. Puteți scrie o funcție Ruby Cloud. Deci, știu că vorbesc în mod special despre JavaScript, pentru că am sentimentul că majoritatea acestor lucruri sunt JavaScript. Chiar și indiferent de ce limbă este, vreau să spun, puteți accesa linia de comandă local și executați lucrul. Unele dintre aceste teste sunt... pur și simplu testați-l ca și orice alt cod. Doar apelați funcția local și vedeți dacă funcționează.

Chris: Este o poveste puțin diferită atunci când vorbiți despre o solicitare HTTP la ea, acesta este lucrul pe care încercați să îl testați. Răspunde în mod corespunzător solicitării? Și returnează lucrurile în mod corespunzător? Nu știu. Rețeaua s-ar putea implica acolo. Așa că poate doriți să scrieți teste la acel nivel. E in regula. Nu știu. Care este povestea normală acolo? Porniți un fel de server local sau ceva care îl servește. Folosește Poștașul, nu știu. Dar există... Framework-urile încearcă să ajute și ele. Știu că „.com” fără server, care este teribil de confuz, dar există literalmente o companie numită Serverless și creează un cadru pentru scrierea funcțiilor fără server care te ajută să le implementezi.

Chris: Deci, dacă vă place instalarea NPM fără server, obțineți cadrul lor. Și este considerat pe scară largă ca fiind foarte bun, pentru că este pur și simplu foarte util, dar nu au propriul lor nor sau altceva. Le scrii și apoi te ajută să le aduci la o adevărată lambda. Sau poate funcționa cu mai mulți furnizori de cloud. Nici măcar nu știu în zilele noastre, dar scopul lor de a exista este să ușureze povestea implementării. Nu știu ce... AWS nu este renumit pentru simplitatea lor. Tu stii? Există toată această lume a instrumentelor care vă ajută să utilizați AWS și ei sunt unul dintre ele.

Chris: Au un fel de produs plătit. Nici măcar nu știu ce este exact. Cred că unul dintre lucrurile pe care le fac este... scopul utilizării lor este pentru testare, este de a avea un mediu de dezvoltare care să testeze funcția dumneavoastră fără server.

Drew: Da, pentru că cred că aceasta este o parte destul de mare a fluxului de lucru, nu-i așa? Dacă ați scris funcția JavaScript, ați testat-o ​​local, știți că va face treaba. 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: Da. 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. Nu știu. 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. Da.

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: Da. 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: Da. 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: Da, da. Cred că da, cred că asta este... pentru că există momente ca... nu trebuie să fii extraordinar de priceput pentru a ști ce este potrivit și ce nu este pentru un site web. De exemplu, am făcut un mic tutorial săptămâna trecută, unde a existat această eroare, folosește acestea... când salvezi o eroare, îți dau un melc pentru lucrul tău pe care l-ai construit, adică „Whiskey, tango, foxtrot. 1.000.” Este ca un lucru mic inteligent. Șansele ca acesta să fie unic sunt foarte mari, pentru că cred că chiar îi adaugă un număr sau ceva de genul. Dar ajung să fie aceste lucruri mici distractive. Ei își deschid bibliotecă cu surse care conține toate acele cuvinte, dar este ca o sută, mii de cuvinte. Dosarul este imens. Tu stii? Sunt megaocteți mari dintr-un dicționar de cuvinte. Probabil că în primul an de dezvoltare ați învățat: „Nu trimiteți un fișier JavaScript care este în megaocteți dintr-un dicționar”. Nu este un lucru bun de expediat. Tu stii? Dar lui Node nu-i pasă. Puteți expedia sute dintre ele. Este irelevant pentru viteza de pe un server.

Drew: Da.

Chris: Nu contează pe un server. Așa că aș putea spune: „Hmm, ei bine, atunci o voi face în Node”. Voi avea o declarație care spune: „Cuvintele egale necesită cuvinte”, sau orice altceva, și o notă în partea de sus, „Pune-l să randomizeze un număr. Scoateți-l din matrice și returnați-l.” Deci, această funcție fără server este de opt linii de cod cu un pachet @JSON care trage în această bibliotecă open source. Și apoi codul meu front-end, există o adresă URL a funcției fără server. Acesta atinge acea adresă URL. URL-ul returnează un cuvânt sau un grup de cuvinte sau orice altceva. Îți construiești propriul tău API mic pentru asta. Și acum, am un lucru foarte frumos și eficient. Ce a fost frumos la asta este că este atât de simplu. Nu sunt îngrijorat de securitatea acesteia. Eu nu... știi?

Chris: Doar că... un dezvoltator JavaScript foarte obișnuit sau începător, cred, poate reuși, ceea ce este grozav. Acesta este un lucru favorabil pe care nu l-au avut înainte. Înainte, ei spuneau: „Ei bine, iată o serie de cuvinte de 2 MB”. „Oh, nu pot trimite asta clientului.” „Oh, te vei închide atunci.” S-ar putea să lovești acest perete care spune: „Nu pot să fac partea asta atunci. Trebuie să cer pe altcineva să mă ajute cu asta sau pur și simplu să nu o fac sau să aleg mai multe melci plictisitori sau ceva...” Doar că trebuie să mergi într-un alt drum care să fie un zid pentru tine, pentru că nu ai putut să o faci. Și acum, tu ești: „Oh, ei bine, voi doar...” În loc să am asta în script-ul slash sau în folderul scripts slash sursă, îl voi pune în folderul funcții.

Chris: Ți-ar fi cam mutat scenariul dintr-un dosar în altul. Și acesta se întâmplă să fie implementat ca o funcție fără server. Cat de tare e asta? Tu stii? Folosești exact același set de abilități, aproape. Există încă niște margini aspre, dar este destul de aproape.

Drew: E super tare. Ai creat un fel de mic microsite despre aceste idei, nu-i așa?

Chris: Da. Am fost puțin mai devreme la joc. Lucram la el azi, totuși, pentru că... primesc solicitări de tragere. Ideea... ei bine, este la serverless.css-tricks.com și... există o liniuță în CSS-Tricks, apropo. Deci este un subdomeniu al CSS-Tricks și l-am construit și fără server, așa că acesta este... CSS-Tricks este ca un site WordPress, dar acesta este un site generator de site static. Tot conținutul acestuia se află în depozitul GitHub, care este open-source. Deci, dacă doriți să schimbați conținutul site-ului, puteți să trimiteți o solicitare de sondaj, ceea ce este frumos pentru că au fost o sută sau cam așa ceva de-a lungul timpului. Dar am construit tot conținutul original.

Drew: Este un loc super util, pentru că listează... Dacă te gândești, „Bine, vreau să încep cu funcțiile fără server”, listează toți furnizorii pe care le-ai putea încerca și...

Chris: Cam atât, sunt liste de tehnologie. Da.

Drew: Ceea ce este grozav, pentru că altfel, cauți pe Google orice și nu știi ce găsești. Da, listele de furnizori API vă ajută să faceți astfel de lucruri.

Chris: Forms este un exemplu în acest sens, pentru că... în momentul în care alegi să... să zicem, vei merge pe JAMstack, ceea ce știu că nu este neapărat scopul, dar vezi cât de mână în mână sunt. . Dintr-o dată, nu aveți un fișier PHP sau orice altceva cu care să procesați formularul respectiv. Cum faci formularele pe un site JAMstack? Ei bine, există mai multe moduri de a face asta. Se pare că toată lumea și sora lor vor să te ajute să rezolvi această problemă. Deci cred că dacă eu am fost inventatorul cuvântului JAMstack, așa că încearcă să te ajute în mod natural, dar nu trebuie să le folosești.

Chris: De fapt, am fost atât de surprins când am creat acest site. Să vedem. Există șase, nouă, doisprezece, cincisprezece, optsprezece, douăzeci și unu, douăzeci și două de servicii acolo, care doresc să vă ajute să vă procesați fără server formularele pe acest site chiar acum. Dacă vrei să fii al 23-lea, ești binevenit, dar ai ceva competiție acolo. Deci ideea din spatele acestui lucru este că scrieți un formular în HTML, ca literalmente un element de formular. Și apoi atributul de acțiune al formularului, nu poate indica nicăieri în interior, pentru că nu există nimic spre care să indicați. Nu poți procesa, așa că indică în exterior. Indică spre tot ce vor ei să-l arăți. Ei vor procesa formularul și apoi au tendința de a face lucruri pe care v-ați aștepta să le facă, cum ar fi să trimită o notificare prin e-mail. Sau trimite o chestie Slack. Sau apoi trimite-l la Zapier și Zapier îl va trimite în altă parte. Toți au seturi de caracteristici, prețuri și lucruri ușor diferite, dar toți încearcă să rezolve această problemă pentru tine, cum ar fi: „Nu doriți să vă procesați propriile formulare? Nici o problemă. O vom procesa pentru tine.”

Drew: Da, este o resursă super utilă. Recomand cu adevărat tuturor să-l verifice. Este serverless.css-tricks.com. Deci, am învățat totul despre serverless. Despre ce ai învățat în ultima vreme, Chris?

Chris: Ei bine, sunt încă foarte mult în această lume și învăț despre chestii fără server. Mi-a venit o idee să... Obișnuiam să joc acest joc de rol online cu o mulțime de ani în urmă. Am descoperit recent că este încă în viață. Este un tip de joc fantezie medieval bazat pe text. L-am jucat când AOL era un lucru, pentru că AOL dorea să aibă aceste jocuri la care trebuia să fii conectat pentru a le juca, pentru că voiau să petreci ore și ore pe AOL, ca să-ți trimită aceste facturi uriașe, ceea ce era , sunt sigur, de ce s-au descurcat atât de bine la un moment dat.

Drew: Deci, facturare pe secundă. Da.

Chris: Da. Deci jocurile au fost mari pentru ei. Dacă ar putea să te facă să joci cu alți oameni acolo. Așa că acest joc cam... nu a debutat acolo, dar s-a mutat la AOL, pentru că sunt sigur că au primit o afacere suculentă pentru el, dar a fost atât de... Adică, pur și simplu, nu ar putea fi mai tocilar. Ești un mag pitic și primești toiag de rune din teaca ta de piele. Și tastați comenzi în el ca pe un terminal. Atunci jocul îți răspunde. Am jucat jocul acela foarte mult timp. Am fost foarte interesat de asta. Am intrat în comunitatea ei și în spiritul ei. A fost un fel de... parcă eram singur la computer, dar totuși mă uit înapoi la acel moment din viața mea și spun: „A fost un moment minunat în viața mea”. Eram cu adevărat... Pur și simplu îmi plăceau oamenii și jocul și toate astea. Dar apoi am crescut și am încetat să mai joc, pentru că ți se întâmplă viața.

Chris: Am aflat abia de curând, pentru că cineva a început să facă din nou un podcast despre asta... Nu știu cum am dat de el, dar tocmai am făcut-o. Mi-am spus: „Acest joc este viu și bine în lumea de astăzi, glumiți de mine? Acest lucru bazat pe text.” Și am fost mai mult decât fericit să reactivez și să-mi recuperez vechile personaje și să le joc. Dar doar pentru a afla că clienții pe care îi descarcă pentru acest joc nu au evoluat deloc. Sunt groaznice. Ei aproape presupun că utilizați Windows. Există doar aceste redări teribil de brânzoase prost... și se bazează pe text, crezi că ar avea măcar o tipografie frumoasă. Nu. Așa că am spus: „Aș putea fi implicat. Aș putea scrie un client pentru acest joc. Pune o tipografie frumoasă în ea.” Doar modernizează chestia și cred că jucătorii jocului ar aprecia asta, dar mi s-a părut copleșitor. „Cum pot să fac?” Dar găsesc câteva proiecte open source. Una dintre ele este ca... poți juca jocul printr-o fereastră de terminal reală și folosește niște biblioteci open source pentru a face un fel de interfață grafică dintr-o fereastră de terminal.

Drew: Serios?

Chris: Nu stiu. Deci a fost cam misto. Eram de genul: „Dacă au scris asta, trebuie să existe cod acolo pentru a vă conecta la joc și a pune totul în funcțiune și alte chestii. Deci cel puțin am un cod de pornire.” Încercam să merg de-a lungul aplicației, „Poate o voi face în Flutter sau așa ceva”, astfel încât aplicația pentru produsul final să funcționeze pe telefoanele mobile și „Aș putea cu adevărat să modernizez chestia asta”. Dar apoi am fost copleșit. Am spus: „Ah, asta e prea mare pentru... nu pot. Sunt ocupat." Dar am găsit o altă persoană care a avut aceeași idee și a fost mult mai departe cu ea, așa că am putut contribui doar la nivel de design. Și a fost foarte distractiv să lucrez, dar și eu am învățat multe, pentru că este rar pentru mine să sar într-un proiect care este copilul altcuiva și doar contribui la un pic, iar asta este total diferit. alegeri tehnologice decât aș fi ales eu vreodată.

Chris: Este o aplicație Electron. Ei au ales asta, care este, de asemenea, o modalitate grozavă de a merge, pentru că sunt abilitățile mele de web... așa că nu învăț nimic prea ciudat și este multi-platformă, ceea ce este grozav. Deci, am învățat multe despre Electron. Cred că e distractiv.

Drew: E fascinant. Este întotdeauna uimitor cât de puține proiecte secundare și lucruri pe care le facem pentru distracție ajung să fie locul în care uneori învățăm cel mai mult. Și învățați abilități care pot fi apoi reintroduse în munca noastră zilnică.

Chris: Doar așa învăț lucruri. Sunt târât în ​​ceva care... Am spus: „Nu sunt...” Este redat cu o bibliotecă JavaScript numită Mithril, care este... Nu știu dacă ați auzit vreodată de el, dar este ciudat. Nu este... este aproape ca și cum ai scrie React fără JSX. Trebuie să „creezi un element” și să faci toate acestea... dar ar trebui să evalueze mult mai bine decât el... Și de fapt contează, deoarece în acest joc bazat pe text, textul pur și simplu zboară. Există o mulțime de manipulare a datelor, ceea ce este ca... ați crede că acest joc bazat pe text ar fi atât de ușor de rulat pentru o fereastră de browser, dar de fapt nu este. Se întâmplă atât de multă manipulare a datelor, încât trebuie să fii cu adevărat... trebuie să fim conștiincioși cu privire la viteza de redare. Tu stii?

Drew: E fascinant...

Chris: Destul de misto.

Drew: Da. Dacă tu, dragă ascultător, ai vrea să afli mai multe de la Chris, îl poți găsi pe Twitter, unde este @chriscoyier. Desigur, CSS-Tricks pot fi găsite la css-tricks.com și CodePen la codepen.io. Dar, mai ales, vă recomand să vă abonați la podcastul ShopTalk Show dacă nu ați făcut-o deja, la shoptalkshow.com. Mulțumim că ni ești alături astăzi, Chris. Ai cuvinte de despărțire?

Chris: Smashingpodcast.com. Sper că acesta este adresa URL reală.