Fundamentele JAMstack: ce, ce și cum

Ne place să depășim limitele pe web și așa că am decis să încercăm ceva nou. Probabil ați auzit de JAMstack — noua stivă web bazată pe JavaScript, API și Markup — dar ce înseamnă pentru fluxul dvs. de lucru și când are sens în proiectele dvs.?

Ca parte a abonamentului nostru Smashing, organizăm Smashing TV , o serie de seminarii web live, în fiecare săptămână. Fără dubii – doar seminarii web practice și acționabile, cu întrebări și răspunsuri live, conduse de practicieni respectați din industrie. Într-adevăr, programul Smashing TV pare deja destul de dens și este gratuit pentru membrii Smashing, împreună cu înregistrări - evident .

L-am rugat cu amabilitate pe Phil Hawksworth să organizeze un webinar în care să explice ce înseamnă de fapt JAMStack și când are sens, precum și cum afectează instrumentele și arhitectura front-end. Webinarul de o oră este acum disponibil și. Nu am putea fi mai fericiți să-i urăm bun venit lui Phil pentru a co-MC viitorul nostru SmashingConf Toronto (25-26 iunie) și a conduce JAMStack_conf Londra, pe care îl co-organizăm și în perioada 9-10 iulie anul acesta. Deci, hai să intrăm în asta!

Phil Hawksworth: Excelent, bine, atunci hai să intrăm în asta. Doar ca o salutare foarte rapidă, vreau să spun că am salutat deja, Scott mi-a făcut o prezentare frumoasă. Dar da, în prezent lucrez la Netlify, lucrez în echipa de experiență pentru dezvoltatori de acolo. Sperăm că vom avea suficient timp pentru întrebări și răspunsuri, dar, așa cum a menționat Scott, dacă nu aveți ocazia să puneți întrebări acolo sau, dacă preferați, puteți să le trimiteți direct la mine pe Twitter, așa că se ocupă de Twitter. sunt numele meu, sunt Phil Hawksworth, așa că oricând îmi puteți pune întrebări despre JAMstack sau despre orice pe Twitter.

Phil Hawksworth: Dar vreau să încep astăzi doar să mă întorc puțin în timp la acest citat care într-adevăr rezonează foarte, foarte puternic cu mine. Acesta este un citat din minunatul Aaron Schwartz, care, desigur, a contribuit atât de mult la Creative Commons și la web-ul deschis și a scris asta pe blogul său chiar în 2002, și a spus: „Îmi pasă să nu fiu nevoit să mă mențin nervos. Serverul AOL, instalările Postgres și Oracle.” Server AOL, a trebuit să mă uit în sus pentru a-mi aminti că era un server web open source la acea vreme.

Phil Hawksworth: Dar asta mă sună foarte puternic. De asemenea, nu vreau să întrețin infrastructura pentru a menține un blog în viață și despre asta vorbea. Și era în această postare pe blogul său și era intitulată „Coaceți, nu prăjiți”. Alege un termen pe care cineva care a construit recent un CMS a început să-l folosească și a cam popularizat acest termen despre coacere (Coaceți, nu prăjiți); ceea ce vorbește acolo este pre-rendarea, mai degrabă decât redarea la cerere, așa că coacerea conținutului înainte de timp, mai degrabă decât prăjirea la cerere atunci când oamenii vin și îl cer - îndepărtând lucrurile din timpul solicitării și într-un fel de timp de construire.

Phil Hawksworth: Și când vorbim despre pre-rendare și randare, ceea ce ne referim prin asta este că vorbim despre generarea de markup. Mă simt puțin conștient, uneori, vorbesc despre un fel de randare de server sau de redare izomorfă sau o mulțime de astfel de termeni populari; Am fost chemat acum câțiva ani la o conferință, Frontiers Conference din Amsterdam, când vorbeam despre randarea pe server și cineva mi-a spus: „Vrei să spui să generezi HTML? Doar ceva care scoate HTML?” Și la asta, desigur, vreau să spun.

Phil Hawksworth: Dar toate acestea contribuie în mare măsură la simplificarea stivei. Când ne gândim la stiva din care servim site-urile web; Mă gândesc să încerc să simplific lucrurile, sunt foarte dornic să încerc să simplific stiva. Și asta se află în centrul acestui lucru numit „JAMstack” și vreau să încerc să explic un pic acest lucru. „JAM” din JAMstack înseamnă JavaScript, API-uri și Markup. Dar asta nu este suficient pentru a ne ajuta să înțelegem ce înseamnă – ce naiba înseamnă asta cu adevărat?

Phil Hawksworth: Ei bine, ceea ce vreau să încerc și să fac în următoarea jumătate de oră sau cam asa ceva, este că vreau să extind această definiție și să ofer mai mult o descriere a ceea ce este JAMstack. Vreau să vorbesc puțin despre impactul și implicațiile JAMstack și, știți, să vă gândiți la ce ne poate oferi asta de ce l-am putea alege. Pe parcurs, voi încerca să menționez unele dintre instrumentele și serviciile care vor fi utile și, sperăm, voi încheia câteva resurse pe care ați putea dori să le explorați și, probabil, să menționez câțiva pași pentru a vă ajuta în curs de desfăşurare.

Phil Hawksworth: Deci, acesta este planul pentru următoarea jumătate de oră. Dar, vreau să revin la această noțiune despre simplificarea stivei, pentru că, sperăm, oamenii care se alătură acestuia sau au venit să vizioneze acest videoclip mai târziu, poate că aveți o idee despre ce este JAMstack, sau poate că este un termen complet nou și ești doar curios. Dar, în cele din urmă, există deja o mulțime de stive acolo. Există o mulțime de moduri prin care puteți livra un site web. Se pare că am construit diferite tipuri de infrastructură de foarte mult timp, fie că este o stivă LAMP sau stiva MAMP, sau stiva - nu știu - MEAN. Sunt o grămadă de ei care plutesc pe ecran aici. Sunt o mulțime și o mulțime de ei.

Phil Hawksworth: Deci, de ce naiba am avea nevoie de altul? Ei bine, JAMstack este, așa cum am menționat, este JavaScript/API/Markup, dar dacă încercăm să fim puțin mai descriptivi, JAMstack este destinat să fie o arhitectură modernă, pentru a ajuta la crearea de site-uri rapide și sigure și de aplicații dinamice cu JavaScript/ API-urile și marcajele pre-rendate, oferite fără servere web, iar acest ultim punct este, într-un fel, ceva care îl deosebește și poate, îl face puțin mai, mai interesant și neobișnuit.

Phil Hawksworth: Această noțiune de a servi ceva fără servere web, care sună fie magic, fie ridicol și, sperăm, ne vom da seama ce pe parcurs. Dar pentru a încerca să aruncăm o lumină asupra acestui lucru și să o descriem mai detaliat, uneori este util să o comparăm cu ceea ce am putea considera ca fiind o stivă tradițională sau un mod tradițional de a servi lucrurile pe web. Deci, hai să facem asta doar pentru o secundă. Să vedem, probabil, cum ar putea arăta o solicitare când este deservită într-o stivă tradițională.

Phil Hawksworth: Deci, în acest scenariu, avem pe cineva care deschide un browser web și face o solicitare pentru a vedea o pagină. Și poate că acea solicitare atinge un CDN, dar probabil, mai probabil, a lovit o altă infrastructură pe care o găzduim - ca oamenii care dețin acest site. Poate că am încercat să ne asigurăm că acest lucru se va extinde sub o mare sarcină pentru că, evident, ne dorim o vedere foarte populară și de succes. Deci, poate că avem un echilibrator de încărcare, care are o logică în el, care va deservi acea cerere către unul dintre numeroasele servere web pe care le-am furnizat, configurat și implementat. S-ar putea să existe un număr de acele servere.

Phil Hawksworth: Și acele servere vor executa o logică pentru a spune: „Bine, iată șablonul nostru, trebuie să-l completăm cu niște date.” S-ar putea să ne obținem datele de la unul dintre numeroasele servere de baze de date care vor efectua o anumită logică pentru a căuta unele date, le va returna pe serverul web, va crea o vizualizare pe care apoi o vom transmite înapoi prin echilibrul de încărcare. Poate că, pe parcurs, apelând la CDN, ascunzând unele active în CDN și ar trebui să clarific, un CDN este o rețea de livrare de conținut, deci o rețea de mașini distribuite pe Internet pentru a încerca să obțină un serviciu de solicitare cât mai aproape posibil. utilizatorului și adăugați lucruri, cum ar fi stocarea în cache.

Phil Hawksworth: Așadar, am putea ascunde unele active acolo și, în cele din urmă, să returnăm o vizualizare în browser, în ochii utilizatorului, care poate experimenta apoi site-ul pe care l-am creat. Deci, evident, aceasta este fie o simplificare excesivă, fie o viziune foarte generală asupra modului în care am putea deservi o solicitare într-o stivă tradițională. Dacă comparăm asta cu JAMstack, care deservește lucrurile într-un mod ușor diferit, așa ar putea arăta.

Phil Hawksworth: Deci, din nou, același scenariu, începem cu un browser web. Facem o solicitare pentru vizualizarea paginii, iar pagina respectivă este deja într-un CDN. Acesta servește static de acolo, așa că este returnat utilizatorului, în browser și am terminat. Deci, evident, o viziune foarte simplificată, dar imediat, puteți începe să vedeți diferențele aici în ceea ce privește complexitatea. În ceea ce privește locurile în care trebuie să gestionăm codul, codul profund, toate aceste lucruri diferite. Deci, pentru mine, unul dintre atributele de bază ale unui JAMstack, este că înseamnă că construiți un site care poate fi servit direct de la un CDN, sau chiar de la un server de fișiere static. CDN este ceva pe care s-ar putea să dorim să punem în aplicare pentru a gestiona încărcarea, dar în cele din urmă, acesta ar putea fi servit direct de la orice tip de server de fișiere static, un fel de infrastructură de găzduire statică.

Phil Hawksworth: JAMstack, într-un fel, oferă o oportunitate de a reduce complexitatea. Doar comparând acele două părți ale diagramei la care vom reveni de câteva ori, pe parcursul următoarei jumătate de oră, puteți vedea că este o oportunitate de a reduce complexitatea și de a reduce riscul. Și așa, înseamnă că putem începe să ne bucurăm de unele dintre beneficiile servirii activelor statice și voi vorbi despre ceea ce sunt acestea puțin mai târziu. Dar s-ar putea să te uiți la asta și să te gândești: „Ei bine, grozav, dar nu este acesta doar noul nume pentru site-urile web statice?” Este un lucru rezonabil pentru a mă ridica când spun: „Vom servi lucrurile static”.

Phil Hawksworth: Dar vreau să revin la asta. Vreau să vorbesc despre asta puțin mai mult, dar mai întâi de toate, vreau să vorbesc despre această noțiune de stive și ce naiba este o stivă, oricum? Și mă gândesc la o stivă ca la straturile de tehnologie, care vă oferă site-ul sau aplicația. Și nu vorbim despre pipeline de construire sau despre procesul de dezvoltare, dar cu siguranță modul în care deservim site-urile poate avea un impact mare asupra modului în care dezvoltăm și cum implementăm lucrurile și așa mai departe.

Phil Hawksworth: Dar aici, vorbim despre stiva tehnologică, straturile de tehnologie, care oferă de fapt site-ul și aplicația dvs. utilizatorilor. Deci, hai să facem o altă mică comparație. Să vorbim despre stiva LAMP pentru o secundă.

Phil Hawksworth: Vă amintiți probabil că stiva LAMP este alcătuită dintr-un server web apache, pentru a face lucruri precum rutarea HCP și servirea activelor statice. PHP, pentru unele pre-procesare, deci destul de procesare hiper-text; aplicând logica, poate construirea vederilor pentru șabloane și ce aveți. Și are un anumit acces la datele tale, prin NISQL-ul meu, iar apoi LINUX este sistemul de operare care se află sub toate acestea, menținând totul să respire. Putem împacheta asta împreună în mod noțional ca acest server web. Și s-ar putea să avem multe dintre aceste servere, într-un fel, stând împreună pentru a servi un site web.

Phil Hawksworth: Acesta este un fel de aspect tradițional asupra stivei LAMP și dacă o comparăm cu stiva JAM, ei bine, aici, există o schimbare critică. Aici, de fapt, urcăm nivelul, mai degrabă decât să ne gândim la sistemul de operare și să ne gândim la modul în care rulăm logica pentru a livra un site web. Aici facem o presupunere că vom servi aceste lucruri static. Deci, facem rutarea ACP și servirea activelor de pe un server static. Asta se poate face în mod rezonabil. Ne-am priceput foarte bine la asta, de-a lungul anilor, construind modalități de a livra site-uri web statice sau active statice.

Phil Hawksworth: Acesta ar putea fi un CDN și, din nou, vom vorbi despre asta într-un moment. Dar zona de interes pentru noi, se întâmplă mai mult în browser. Deci, aici, aici este livrat și analizat marcajul nostru. Aici se poate executa JavaScript, iar acest lucru se întâmplă în browser. În multe privințe, browserul a devenit timpul de rulare pentru web-ul modern. În loc să avem timpul de execuție în infrastructura serverului în sine, acum l-am mutat la un nivel mai sus, mai aproape de utilizator și în browser.

Phil Hawksworth: Când vine vorba de accesarea datelor, ei bine, asta se întâmplă prin, eventual, API-uri externe, efectuând apeluri prin JavaScript către aceste API-uri externe pentru a obține acces la server, sau putem considera API-urile ca API-uri de browser, fiind capabile să interacționeze cu JavaScript. cu capabilități chiar acolo în browserul dvs.

Phil Hawksworth: În orice caz, cheia aici despre JAMstack este că, vorbim despre lucruri care sunt pre-rendate: sunt servite static și apoi, pot fi îmbunătățite progresiv în browser pentru a utiliza API-urile browserului, JavaScript-urile. , și ce ai tu.

Phil Hawksworth: Deci, hai să facem această mică comparație una lângă alta aici. Din nou, vreau doar să reiterez că JAMstack a crescut la un nivel în browser. Și dacă vedem cele două părți ale acestei diagrame, cu stiva LAMP în stânga și efectiv, stiva JAM în dreapta, s-ar putea chiar să vă gândiți că, ei bine, chiar și atunci când construim lucruri cu stiva LAMPĂ, încă suntem scoaterea de marcaj. Încă lansăm JavaScript. Este posibil să accesăm în continuare API-uri. Deci, din multe puncte de vedere, JAMstack este aproape ca un subset al ceea ce construiam înainte.

Phil Hawksworth: Obișnuiam să vorbesc uneori despre JAMstack ca fiind stiva asigurată, deoarece asigură un set de instrumente și tehnologii de care avem nevoie pentru a livra un site. Dar, în orice caz, este o modalitate mult simplificată de a furniza un site care, într-un fel, elimină nevoia ca lucrurile să se execute și să realizeze logica la server la momentul solicitării.

Phil Hawksworth: Deci, asta poate face o mulțime de lucruri. Acest lucru poate, într-un fel, să simplifice implementările și, din nou, voi reveni la această diagramă din când în când. Dacă ne gândim la modul în care implementăm codul și site-ul nostru, pentru fiecare implementare, de la prima, de-a lungul întregului ciclu de viață al dezvoltării, pe tot parcursul vieții site-ului. Pe stiva tradițională, ar putea fi nevoiți să schimbăm logica și conținutul pentru fiecare casetă din diagrama respectivă.

Phil Hawksworth: În timp ce, în JAMstack, atunci când vorbim despre implementare, vorbim despre trimiterea lucrurilor către CDN, aducerea lucrurilor către serverul static și asta presupune implementarea. Construirea, genul de logică care rulează construcția — care poate rula oriunde. Acesta nu trebuie să ruleze în același mediu care găzduiește serverul web. De fapt, nu este! Pornește cheia pentru JAMstack. Punem separarea la ceea ce se întâmplă la momentul solicitării, servind aceste active statice, față de ceea ce se întâmplă la momentul construirii, care poate fi logica pe care o rulați pentru a construi și apoi la implementare.

Phil Hawksworth: Deci, acest tip de decuplare este un lucru cheie și voi reveni la asta mai târziu. Ne-am priceput foarte bine la servirea fișierelor statice, iar aducerea lucrurilor către un CDN sau trimiterea lucrurilor către sistemul de fișiere (serverul de fișiere) este undeva în care am văzut progrese uriașe în ultimii câțiva ani. Acum există o mulțime de instrumente și procese care ne pot ajuta să facem acest lucru foarte bine. Doar pentru a evoca câteva servicii care pot servi bine activele statice și pot oferi fluxuri de lucru pentru a vă aduce construcția în acel mediu, aceștia sunt suspecții obișnuiți pe care vă puteți imagina furnizorii mari de infrastructură cloud, cum ar fi Azure, AWS și Google Cloud.

Phil Hawksworth: Dar mai sunt și alții. Deci, cel de sus din dreapta este un serviciu numit Surge, care există de câțiva ani. Vă permite să rulați o comandă în mediul dvs. de construcție și să vă implementați activele în mediul lor de găzduire. Netlify, următorul în jos, este locul unde lucrez și facem aproape același lucru, dar avem și automatizări diferite. Aș putea să intru în asta altă dată. Și cel de jos, un alt site de mediu de găzduire static, numit Now.

Phil Hawksworth: Deci, există o grămadă de opțiuni diferite pentru a face acest lucru, iar toate aceste spații oferă instrumente diferite pentru a ajunge la CDN, cât mai repede posibil. Implementarea site-urilor dvs. în cel mai simplu mod posibil. Și toți au ceva în comun în care se bazează pe principiul de a rula ceva la nivel local. Adesea mă gândesc la un generator de site static ca la ceva pe care l-am putea rula într-o versiune care, atunci când o rulăm, ia lucruri precum conținut și șabloane și poate date de la diferite servicii și scoate ceva care poate fi servit static.

Phil Hawksworth: Putem previzualiza asta local pe serverul nostru static. Ceva care este oarecum simplu de făcut în orice mediu de dezvoltare locală, și apoi procesul de implementare care este transferul în mediul de găzduire și, în mod ideal, într-un CDN pentru a obține, într-un fel, scala. Așadar, cu acest tip de fundație așezat, vreau să abordez o concepție greșită comună când vine vorba de site-urile JAMstack. Și nu mi-am făcut nicio favoare deschizând acest lucru, descriind site-urile JAMstack ca fiind JavaScript, API-uri și Markup. Deoarece ideea greșită comună este că fiecare site JAMstack trebuie să fie JavaScript și API-uri și Markup, dar acest tip de lucru pe care l-am trecut cu vederea este că nu trebuie să le folosim pe toate trei - fiecare dintre acestea este un fel de , optional. Putem folosi oricât de mult sau cât de puțin din acestea ne dorim. În același mod în care un site de stivă LAMP nu ar trebui neapărat să lovească o bază de date. Acum, am construit lucruri în trecut care sunt deservite de un server Apache, pe o mașină Linux, și am folosit PHP, dar nu am lovit o bază de date și nu aș începe să redenumesc o stivă. neaparat pentru asta.

Phil Hawksworth: Deci, dacă ne gândim la ce este un site JAMstack, atunci ar putea fi o grămadă de lucruri diferite. Ar putea fi ceva care a fost construit cu un generator de site static, cum ar fi Jekyll, care extrage conținut din fișierele YAML pentru a construi un site care nu are JavaScript, nu atinge deloc API-urile și îl oferim pe ceva, cum ar fi Paginile GitHub. Sau, acesta ar fi un site JAMstack. Sau poate folosim un generator de site static, cum ar fi Gatsby, care este, mai degrabă într-un mediu Ruby pentru Jekyll, acum acesta este un generator de site static JavaScript construit în ecosistemul React.

Phil Hawksworth: S-ar putea să atragă din nou conținut și să organizeze fișiere Markdown. Ar putea fi îmbogățitor că, cu apeluri către API-uri, API-urile GraphQL. S-ar putea să facă lucruri în browser, cum ar fi hidratarea JavaScript pentru popularea șabloanelor chiar acolo în browser. Și ar putea fi servit pe Amazon S3. Este un site JAMStack? Da, absolut!

Phil Hawksworth: Trecerea la un alt generator de site static, Hugo, care este construit cu Go! Din nou, s-ar putea să organizăm conținut în fișiere Markdown, adăugând interacțiuni în browser folosind JavaScript. Poate că nu apelăm la niciun API extern și poate că găzduiesc asta pe Google Cloud. Este JAMstack? Absolut! Vedeți, eu construiesc o temă aici. Folosind ceva de genul Nuxt, un alt generator de site static, acum construit în ecosistemul View. Poate că asta trage conținut din diferite fișiere adiacente? Din nou, s-ar putea să folosim interacțiuni JavaScript în browser, poate apelând API-uri pentru a face lucruri precum comerțul electronic, oferindu-i un alt site static. O altă infrastructură de găzduire precum Netlify, este un JAMstack? Da, este!

Phil Hawksworth: Dar am putea chiar să mergem, știi, să mergem și la capătul ăsta al scalei. Și gândiți-vă la o aplicație web realizată manual, progresivă, pe care am construit-o artizanal, rulată manual, JavaScript pe care am construit-o noi înșine. Îl împachetăm cu webpack. Poate că folosim jetoane web JavaScript și apelăm la API-uri pentru a face autentificare, interacționând cu diferite API-uri de browser, găzduind-o pe Azure. Da, acesta este și JAMstack!

Phil Hawksworth: Și, știți, toate aceste lucruri, și multe altele, pot fi considerate JAMstack, deoarece toate au un atribut în comun și nici unul dintre ele nu este servit cu un server de origine. Niciunul dintre ei nu trebuie să lovească un server care realizează logica la momentul solicitării. Acestea sunt servite ca active statice și apoi îmbogățite cu JavaScript și apeluri la API-uri.

Phil Hawksworth: Deci, din nou, vreau doar să reiterez că un JAMstack înseamnă că poate fi servit direct de la CDN. Așadar, vreau doar să scot în evidență câteva dintre impacturile și implicațiile acestui lucru, pentru că de ce am dori să facem asta? Ei bine, prima noțiune este despre securitate și avem o suprafață mult redusă pentru atac, aici. Dacă ne gândim (revenind din nou la această veche diagramă), locurile în care ar putea fi nevoiți să facem față unui atac, trebuie să securizăm lucruri precum echilibrul de încărcare, serverele web, serverele de baze de date. Toate aceste lucruri, trebuie să ne asigurăm că nu putem fi pătrunși de niciun fel de atac și, într-adevăr, de CDN.

Phil Hawksworth: Dacă cu cât putem scoate mai multe piese din acest puzzle, cu atât mai puține locuri care pot fi atacate și mai puține locuri pe care trebuie să le asigurăm. A avea puține părți mobile de atacat este cu adevărat foarte valoros. La Netlify, operam propriile noastre CDN-uri, așa că ne bucurăm de luxul de a putea monitoriza traficul care vine peste el și, deși toate site-urile găzduite pe Netlify, toate site-urile JAMstack pe care ți le poți imagina, niciunul dintre ele au o pagină de administrare WordPress pe ei, deoarece este complet decuplată. Nu există un administrator WordPress, dar vedem un volum uriaș de trafic, cercetând lucruri precum WP Admin, căutând căi de intrare, căutând vectori de atac.

Phil Hawksworth: Îmi plac foarte mult unele dintre lucrurile pe care le-a făcut Kent C. Dodds. Nu știu dacă sunteți familiarizat cu comunitatea React, probabil l-ați întâlnit pe Kent C. Dodds în trecut. El nu folosește WordPress, dar tot direcționează această adresă URL, WPAdmin. Cred că obișnuia să o direcționeze către un videoclip Rick Roll de pe YouTube. Cu siguranță a căutat oameni care au cercetat asta. Dar, ideea este că, decuplând lucrurile în acest fel și, într-un fel, mutând lucrurile care se întâmplă, construind timp din ceea ce se întâmplă în timpul solicitării, ne putem reduce drastic expunerea. Nu avem piese mobile la cerere. Piesele mobile sunt toate complet decuplate în timpul construirii. Potenţial, pe complet, bine, neapărat pe o infrastructură complet diferită.

Phil Hawksworth: Acest lucru, desigur, are și un impact asupra performanței. Revenind la vechiul nostru prieten de aici, locurile în care ar putea dori să încercăm să îmbunătățim performanța în stiva de aici, când există o logică care trebuie executată în aceste locuri diferite. Modul în care se întâmplă adesea acest lucru în stivele tradiționale este că încep să adauge straturi, să adauge straturi statice, pentru a îmbunătăți performanța. Deci, cu alte cuvinte, încercați să găsim modalități prin care să începem să ne comportăm ca și cum ar fi static. Nu trebuie să efectuați acea logică la fiecare nivel al stivei pentru a accelera lucrurile. Deci, începem să introducem lucruri precum stocarea în cache în întreaga infrastructură și locuri evidente pe care le-am putea găsi pentru a face asta în serverul web, mai degrabă decât să realizăm acea logică, vrem să servim ceva imediat fără a realiza acea logică.

Phil Hawksworth: Deci, este un fel ca un pas spre a fi pseudostatic. La fel și în serverele de baze de date, dorim să adăugăm straturi de cache la interogările cache-com. Chiar și în soldul scăzut, întregul CDN, te poți gândi la cache. Dar pe stiva tradițională, trebuie să ne dăm seama cum să gestionăm acel cache, deoarece nu totul va fi stocat în cache. Deci, există ceva logic despre. Ce trebuie să fie populat dinamic față de ceea ce poate fi stocat în cache. Și modelul JAMstack, totul este în cache. Totul este stocat în cache din punctul în care se termină implementarea, așa că ne putem gândi la asta complet diferit.

Phil Hawksworth: Prin urmare, acesta începe, într-un fel, să sugereze și la scalare. Și după amploare, vorbesc despre, cum gestionăm încărcături mari de trafic? Stivele tradiționale vor începe să adauge infrastructură pentru a se extinde. Deci, da, la cache. Începem să punem loc în stiva noastră tradițională. Asta va ajuta - într-o anumită măsură. Ceea ce se întâmplă de obicei este că, pentru a gestiona încărcături mari de trafic, vom începe să extindem infrastructura și să începem să adăugăm mai multe servere, mai multe piese pentru a gestiona aceste solicitări, costând aceste lucruri și estimarea încărcării este o suprasolicitare mare și poate fi o bătaie de cap pentru oricine face arhitectură tehnică. Cu siguranță a fost pentru mine, motiv pentru care începeam să înclin mult mai mult spre abordarea JAMstack, în care știu doar că totul este servit de la CDN, care este proiectat implicit pentru a gestiona scara, pentru a gestiona performanța chiar de la început. .

Phil Hawksworth: Așadar, vreau și eu să dau un semn din cap experienței dezvoltatorilor și impactului pe care acest lucru îl poate avea acolo. Acum, experiența dezvoltatorului nu ar trebui să fie văzută niciodată ca ceva care depășește experiența utilizatorului, dar cred că o experiență bună de dezvoltator poate reduce frecarea, poate permite dezvoltatorilor să facă o treabă mult mai bună de a construi experiențe excelente pentru utilizator!

Phil Hawksworth: Deci, atunci când ne gândim la locul în care trăiește experiența dezvoltatorului și unde se află aici domeniile de preocupare pentru un dezvoltator: ei bine, într-o stivă tradițională, ar putea fi nevoie să ne gândim la modul în care ajungem codul la toate aceste diferite părți ale infrastructurii și modul în care joacă toate împreună. În lumea JAMstack, într-adevăr, despre ce vorbim este această casetă aici, în partea de jos. Știți, cum rulăm construcția și ei, cum automatizăm o implementare pentru a primi ceva servit în primul rând? Și lucrul frumos este că, în modelul JAMstack, ceea ce faci în acea versiune depinde complet de tine.

Phil Hawksworth: Acesta este un spațiu cu probleme foarte bine definit, pentru că, în cele din urmă, încercați să construiți ceva pe care să îl puteți servi direct de la un CDN. Vrei să pre-rendați ceva, folosind orice instrumente doriți: fie că este un generator de site static construit în Ruby sau Python sau JavaScript sau Go sau PHP, aveți libertatea de a face acea alegere. Și astfel, asta poate crea un mediu mult mai frumos în care să lucrezi. Și, de asemenea, creează o oportunitate de a avea încredere reală pentru dezvoltatori, deoarece un atribut real al site-urilor JAMstack este că pot fi mult mai ușor servite ca implementare imuabilă și atomică.

Phil Hawksworth: Și vreau să mă îndepărtez de diapozitive doar pentru un moment, să descriu ce înseamnă asta, pentru că o desfășurare imuabilă și o desfășurare atomică pot... (care poate suna puțin ca și cum vorbește marketingul), dar ceea ce voi face, este că voi sări în browserul meu. Acum... de fapt, mă voi întoarce o secundă. Lasă-mă... doar să fac asta.

Phil Hawksworth: Iată-ne. Acest lucru va fi mai ușor. Sărind direct în pagină. Acum, Scott, îmi vei spune, Scott, dacă nu-mi poți vedea browserul, sper. Acum, presupunând că toată lumea poate vedea browserul meu.

Scott: Totul arată bine.

Phil Hawksworth: Excelent! Mulțumesc foarte mult!

Phil Hawksworth: Deci, ceea ce fac aici, este că folosesc Netlify ca exemplu, ca exemplu de serviciu. Dar, acesta este un atribut comun site-urilor care pot fi găzduite, static. Deci, când vorbim despre o implementare imuabilă, ceea ce ne referim este că, mai degrabă, fiecare implementare de cod trebuie să atingă o mulțime de părți diferite ale infrastructurii și să schimbe o mulțime de lucruri, aici nu modificăm starea site-ului pe server-ul. Creăm o instanță complet nouă a site-ului pentru fiecare implementare care a avut loc. Și putem face asta pentru că site-ul este o colecție de active statice.

Phil Hawksworth: Iată, mă uit la implementarea care a avut loc de pe propriul meu site. Îți voi oferi un răsfăț. Iată, așa arată. Este doar un blog, nu pare nimic deosebit de remarcabil sau incitant. Este un blog generat static, dar ceea ce am aici este fiecare implementare care s-a întâmplat vreodată, trăiește în perpetuitate, deoarece este o colecție de active statice care sunt servite de la un CDN. Acum, aș putea să mă întorc atât de departe cât mă poate purta istoria și să mă uit la site, așa cum era în... când a fost asta? Acesta a fost august 2016. Și, în virtutea faptului că este un set de active statice, putem găzdui acest lucru pe propria adresă URL, care trăiește pe perpetuitate și, dacă aș vrea, aș putea decide să intru și să-l public. implementare.

Phil Hawksworth: Deci, acum, oricine se uită la site-ul meu, dacă mă întorc la site-ul meu aici, dacă reîmprospătează pagina, acum aceasta este servită direct de la CDN cu activele care erau acolo înainte. Acum pot naviga din nou. Aici, puteți vedea. Uite, mă bateam pe asta, foloseam acești termeni groaznici precum randarea izomorfă și vorbeam despre JAMstack în 2016. Așadar, asta este acum ceea ce este difuzat live pe site-ul meu. Din nou, pentru că există implementări reciproce care trăiesc pentru totdeauna. O să-mi pun doar liniștea mea, un fel de liniște sufletească, o să — aceasta este prima pagină? Da. Mă voi întoarce la ultima mea implementare. Va trebui să închid din nou și să mă duc înapoi în lumea reală. Lasă-mă să mă asigur că este în regulă.

Phil Hawksworth: Bine! Grozav! Deci, acum, aceasta a revenit la difuzarea versiunii mele anterioare sau a celei mai recente versiuni a site-ului. Mă voi întoarce la keynote. Deci, acest lucru este posibil pentru că lucrurile sunt imuabile și atomice. Partea atomică a acesteia înseamnă, din nou, că desfășurarea este complet conținută. Deci, nu ajungeți niciodată la punctul în care unele dintre active sunt disponibile pe serverul web, dar unele dintre ele nu vor. Numai când totul este acolo în context și totul este acolo, complet, comutăm difuzarea site-ului la noua versiune. Din nou, acesta este genul de lucru pe care îl puteți face mult mai ușor dacă construiți lucrurile ca un site JAMstack care servește direct din CDN ca o grămadă de active.

Phil Hawksworth: Am observat că cronometrul meu sa resetat, după ce am trecut înapoi și înainte de la keynote, așa că cred că mai am aproximativ șase sau șapte minute. Spune-mi, Scott, dacă...

Scott: Deci, da, suntem încă buni vreo zece minute.

Phil Hawksworth: Zece minute? Bine, minunat!

Scott: Nu e nicio grabă.

Phil Hawksworth: Mulțumesc, ar trebui să fie bine!

Phil Hawksworth: Așadar, doar schimbând un pic și vorbind despre API-uri și servicii (din moment ce API-urile fac parte din JAMstack), tipul de servicii pe care apoi le-am putea folosi este în principal JAMstack. Știi, s-ar putea să folosim servicii pe care le-am construit intern sau s-ar putea să folosim servicii cumpărate. Există o mulțime de furnizori diferiți care pot face lucruri pentru noi și asta pentru că aceasta este expertiza lor. Prin intermediul API-urilor, s-ar putea să extragem conținut din sistemele de management al conținutului ca serviciu și există o grămadă de furnizori diferiți pentru acest lucru, care se specializează în oferirea unei experiențe grozave de gestionare a conținutului și apoi, expunerea conținutului prin API, așa că obișnuiai să fii capabil să le tragă înăuntru.

Phil Hawksworth: De asemenea, există diferite moduri prin care puteți deservi bunurile. Oameni precum Cloudary sunt grozavi la asta, pentru a face optimizarea imaginii, pentru a oferi active direct pe site-urile dvs., din nou, prin intermediul API-urilor. Sau cum rămâne cu comerțul electronic? Știi, există locuri precum Stripe sau Snipcart care ne pot furniza API, astfel încât să nu fie nevoiți să construim aceste servicii noi înșine și să intrăm în problemele foarte complexe care vin odată cu încercarea de a construi un motor de comerț electronic. De asemenea, identitatea, de la oameni precum Auth0 care folosesc Oauth. Există o mulțime de servicii care sunt disponibile și putem consuma aceste lucruri prin intermediul API-urilor, fie în browser, fie în timpul construirii, sau uneori, o combinație a ambelor.

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. So, how do we do that?

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. Thanks, Scott.

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. Hello everyone. Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. Dreapta? It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Phil Hawksworth: Îmi place foarte mult, pentru că termenul JAMstack poate fi cu adevărat înșelător, pentru că încearcă să acopere atât de multe lucruri diferite, iar punctul pe care încercam, probabil l-am ciocănit de multe ori în acel slide, este că poate fi de tot felul. de lucruri. Este atât de larg, dar cheia este pre-rendarea și găzduirea static de bază a site-urilor. Ne este foarte ușor să intrăm în războaie religioase despre locul unde trebuie să fie un site React. Trebuie să fie o aplicație React, pentru a fi un site JAMstack, sau este o aplicație React, deci nu poate fi JAMstack. Dar, într-adevăr, esențialul este, indiferent dacă utilizați JavaScript sau nu, dacă apelați sau nu API-uri, dacă pre-rendați și introduceți lucrurile într-o gazdă statică care poate fi foarte performantă, acesta este nucleul JAMstack.

Vitaly: Da, absolut.

Phil Hawksworth: Suntem foarte norocoși că browserele devin mult mai capabile, iar API-urile care există în browser-ul în sine ne pot permite să facem și mai multe. Deci, acest gen de deschidere și mai mult ușile, dar nu înseamnă că tot ceea ce construim ca site JAMstack trebuie să folosească totul. În funcție de ceea ce încercăm să oferim, așa ar trebui să începem să alegem instrumentele cu care ne jucăm pentru a implementa aceste lucruri.

Vitaly: Absolut. Îl avem pe Doran aici. Doran, cred că știu, Doran. Am sentimentul că îl cunosc pe Doran. El întreabă: „Te aștepți ca serverless să graviteze spre integrarea perfectă cu JAMstack de la [inaudible 00:44:36]? Ceea ce se numește A în JAM.

Phil Hawksworth: Aceasta este o întrebare grozavă, pentru că cred că funcțiile fără server sunt — pur și simplu merg atât de bine cu site-urile JAMstack, pentru că, în multe feluri, de fapt, cred că cineva m-a întrebat odată dacă site-urile JAMstack sunt fără server și așa că m-am chinuit despre acea întrebare, pentru că serverless este un termen atât de încărcat. Dar, din multe puncte de vedere, este grozav pentru că vorbeam, din nou și din nou, că nu există server de origine. Nu există o infrastructură de server pe care să o gestionați. De fapt, am scris odată o postare pe blog numită „Web Serverless”, pentru că lumea are nevoie de un alt termen popular, nu-i așa?

Phil Hawksworth: Și într-adevăr, genul de idee a fost, da, construim lucruri fără servere. Nu vrem să fim nevoiți să gestionăm aceste servere, iar funcțiile fără server, sau funcțiile ca serviciu, se potrivesc perfect în asta. Deci, în cazurile în care aveți nevoie de un API la care doriți să faceți o solicitare, unde într-adevăr nu este sens să faceți acea solicitare direct din browser. Deci, de exemplu, dacă aveți secrete sau chei în cererea respectivă, este posibil să nu doriți ca acele solicitări - acele informații - să fie expuse vreodată în client. Dar, cu siguranță, putem folosi proxy aceste lucruri și, de obicei, în mod tradițional, ceea ce trebuie să facem atunci este să pornim un server, să avem o infrastructură care nu făcea efectiv decât să gestioneze cererile, să îi adăugăm autentificare de securitate și să transmitem acele cereri. , proxy-i înapoi.

Phil Hawksworth: Funcțiile serverless sunt perfecte pentru asta. Sunt absolut ideale pentru asta. Așadar, uneori mă gândesc la funcții fără server sau la funcțiile unui serviciu, aproape ca o trapă de evacuare, în care ai nevoie doar de ceva logică pe un server, dar nu vrei să fii nevoit să creezi o întreagă infrastructură. Și puteți face din ce în ce mai mult cu asta și puteți stabili conductele de dezvoltare pentru fluxurile de lucru de dezvoltare, pentru funcțiile pe măsură ce serviciul se maturizează. Devine din ce în ce mai accesibil pentru dezvoltatorii JavaScript să poată construi aceste lucruri. Deci, da, chiar cred că acele două lucruri merg împreună foarte frumos.

Vitaly: Bine, acesta este un răspuns foarte cuprinzător. De fapt, am participat recent la o discuție, în care un inginer front-end de la Amazon vorbea despre funcțiile serverless și Lamda pe care le folosesc - aproape că eram plecat. Vorbea mereu despre Docker și Kubernetes și despre toate acele lucruri, Devox World, eu stăteam acolo, mă gândeam: „Cum a ajuns el acolo. Nu înțeleg ce se întâmplă!” Habar n-aveam ce se întâmplă.

Phil Hawksworth: Exact, dar treaba este că odinioară era... Am fost... Am acceptat că nu înțeleg nimic din lumea aceea, dar nu aveam nicio dorință, deoarece asta era pentru o cu totul altă disciplină. . Și această disciplină este încă foarte importantă. Știți, oameni care proiectează infrastructură - asta este încă foarte important. Dar acum simt că sunt tentată. Ca cineva cu un background de dezvoltare front-end, ca dezvoltator JavaScript, sunt mult mai tentat să vreau să joc în acea lume, pentru că instrumentele se apropie, oarecum, de mine.

Phil Hawksworth: Este mult mai probabil să fiu capabil să folosesc unele dintre aceste lucruri și să livrez lucrurile în siguranță, mai degrabă decât doar ca un experiment propriu, care este locul în care obișnuiam să mă aflu. Așadar, mi se pare că devenim mai puternici ca dezvoltatori web, ceea ce este interesant pentru mine.

Vitaly: Ca și Power Rangers, nu?

Vitaly: Un lucru vreau să te întreb, totuși, și acesta este de fapt ceva despre care am discutat deja, poate, acum o săptămână, dar tot am vrut să-l aduc în discuție, pentru că singurul lucru pe care l-ai menționat în sesiune a fost noțiunea de a avea o instanță de sine stătătoare pentru fiecare implementare, ceea ce este foarte cool. Întrebarea este, totuși, dacă aveți o misiune mare, cu zeci de mii de pagini, chiar nu doriți să redistribuiți fiecare lucru, de fiecare dată. Deci, în esență, dacă ai, cum ar fi, dacă folosești mai ales partea statică a lucrurilor. Deci, am avut această idee de ceva vreme și știu că acesta este de fapt ceva despre care ați adus în discuție ultima dată. Ideea desfășurărilor atomice.

Vitaly: Unde de fapt, literalmente, ți s-a oferit un fel de div între două versiuni diferite de instantanee ale set-up-ului. Deci, dacă spuneți, schimbați antetul peste tot, atunci, desigur, fiecare pagină trebuie redistribuită. Dar dacă schimbați, poate, o componentă, cum ar fi să spunem, carusel, care poate efectuează doar 1000 de pagini, atunci ar avea sens să redistribuiți 15000 de pagini. Dar doar ăștia 1000. Deci, putem ajunge acolo? Este o idee magică care există, sau este ceva destul de tangibil, în acest moment?

Phil Hawksworth: Cred că acesta este, probabil, Sfântul Graal pentru generatoarele statice de site și acest tip de model pentru că, cu siguranță, ați identificat probabil cel mai mare obstacol de depășit. Sau cel mai mare tavan de care te lovești. Și acestea sunt site-uri web care au multe, zeci de mii sau sute de mii sau milioane de adrese URL - ideea că construirea poate deveni foarte lungă. A fi capabil să detecteze care URL-uri se vor schimba, pe baza unei modificări de cod, este o provocare. Nu este de netrecut, dar este o mare provocare. Înțelegerea graficului de dependență pe întregul tău site și apoi implementarea inteligentă a acestuia - este foarte greu de făcut.

Phil Hawksworth: Pentru că, așa cum ați menționat, o schimbare a componentei ar putea avea implicații de mare anvergură, dar dvs. este dificil, întotdeauna, să știți cum va funcționa. Deci, există o serie de generatoare de site statice, proiecte care pun o oarecare greutate în spatele acestei provocări și încearcă să-și dea seama cum realizează regenerarea parțială și construirea incrementală. Sunt foarte încântat că perspectiva că asta s-ar putea rezolva ziua, dar în acest moment, este cu siguranță o mare provocare. Puteți începe să faceți lucruri cum ar fi să încercați să vă distribuiți în mod logic site-ul și să vă gândiți, din nou, la un fel de problemă cu migrarea. Ei bine, știu că această secțiune este independentă în ceea ce privește, felul, unele dintre activele pe care le folosește sau tipul de conținut care trăiește acolo, așa că le pot implementa individual.

Phil Hawksworth: Dar asta nu este ideal pentru mine. Acesta nu este chiar scenariul perfect. Una dintre abordările pe care le-am explorat puțin, doar ca o dovadă a conceptului, este să te gândești la modul în care faci lucrurile, cum ar fi utilizarea inteligentă a 404-urilor. Deci, de exemplu, un caz mare de utilizare pentru semne foarte mari, poate site-urile de știri este că, atunci când au nevoie de o adresă URL atunci când se întâmplă o știre de ultimă oră, trebuie să fie primii pentru a o pune în aplicare acolo. Trebuie să obțină o adresă URL acolo. Lucruri precum BBC News, veți vedea că știrile vor ajunge pe site, iar apoi peste orele suplimentare, se vor adăuga la ea, treptat, dar să ajungeți mai întâi acolo este esențial. Deci, a avea o construcție care durează 10 minute, 20 de minute, oricare ar fi ea, ar putea fi o problemă.

Phil Hawksworth: Dar, dacă conținutul este abstras și poate fi folosit pentru a fi apelat dintr-un API. Am menționat sisteme de management al conținutului care sunt abstracte, cum ar fi Contentful sau Sanity, sau o grămadă de acestea. Orice lucru care are un API de conținut se modifică în acea structură de conținut care va declanșa o construcție și vom trece prin rulare, dar celălalt lucru care s-ar putea întâmpla este că, ei bine, dacă publicați adresa URL pentru asta și apoi publicați acea adresă URL , chiar dacă build-ul nu a rulat, dacă cineva accesează acea adresă URL, dacă prima oprire pe 404 este în loc să spună „Nu l-am prins”, este de fapt să accesezi direct acel API, atunci poți spune , „Ei bine, versiunea nu s-a terminat încă pentru a o popula, dar o pot face în client.” Pot să merg direct la API, să o iau, să-l populez în client.

Vitaly: Hmm, interesant.

Phil Hawksworth: Deci, chiar dacă construirea încă se întâmplă, puteți începe să populați acele lucruri. Și apoi, odată ce construcția s-a terminat, bineînțeles că nu va atinge un 404. Ați accesa acea pagină care rulează static. Deci, există tehnici și strategii pentru a o aborda, dar totuși, este un răspuns foarte lung, divagator, îmi pare rău, dar concluzia mea este, da, asta este o provocare. Încrucișăm degetele, vom obține strategii mai bune.

Vitaly: Da, e grozav. Deci, mă întreb, deci, în acest moment, chiar nu ne gândim, nu doar la ce performanță în ceea ce privește livrarea conținutului, ci la cea în ceea ce privește performanța în ceea ce privește viteza de construire. La fel ca desfășurarea clădirii. Deci, acesta este, de asemenea, ceva pe care am căutat-o, de ceva vreme, de asemenea.

Vitaly: Încă un lucru pe care voiam să te întreb. Deci, acest lucru este interesant, ca această tehnică pe care ați menționat-o. Cum înveți despre asta? Acesta este doar ceva ce oamenii tind să publice pe propriile lor bloguri sau, este un mediu sau există un depozit central de unde puteți obține un fel de studiouri de caz, despre modul în care JAMstack - cum s-au mutat companiile în timpul descărcarii sau nu au reușit să se mute la JAMstack.

Phil Hawksworth: Deci, este un fel de maturizare a acestui peisaj, în acest moment. Adică, unele dintre aceste exemple, cred că sunt într-o poziție foarte norocoasă, lucrez undeva în care sunt într-un rol pe care îl joc cu jucăriile, găsesc modalități interesante de a le folosi și de a începe să experimentez cu ei. Deci, aceste dovezi ale conceptelor sunt, un fel, lucruri cu care pot să experimentez și să încerc să abordez aceste provocări. Dar, am menționat mai devreme, un studiu de caz care a fost prezentat la conferința JAMstack de la New York și, cu siguranță, evenimente de genul acesta, începem să vedem despre cele mai bune practici sau practici din industrie și abordări ale industriei despre care se vorbește la acest tip. a evenimentelor. Și cu siguranță, vreau să văd mai multe și să lucrez la mai multe studii de caz pentru a ajunge în locuri precum Smashing Magazines, astfel încât să putem împărtăși aceste informații mult mai ușor.

Phil Hawksworth: Cred că companiile mari și spațiul întreprinderii adoptă treptat JAMstack, în locuri diferite, în moduri diferite, dar lumea este încă înclinată să iasă acolo, așa că cred că de fiecare dată când o companie îl adoptă și își împărtășește experiență, cu toții putem învăța din asta. Dar chiar vreau să văd din ce în ce mai multe dintre aceste studii de caz să fie publicate, astfel încât să ne putem înclina în special asupra modului în care aceste tipuri de provocări sunt depășite.

Vitaly: Bine, deci, atunci, poate doar ultima întrebare de la mine, pentru că întotdeauna îmi place să citesc întrebări. Deci, terenul JAMstack, dacă ai putea schimba ceva, poate că există ceva ce ți-ar plăcea cu disperare să vezi, dincolo de implementări. Altceva care te-ar face foarte fericit? Asta ți-ar face ziua? Care ar fi asta? Ce este pe lista ta de dorințe, pentru JAMstack?

Phil Hawksworth: Ce întrebare. Adică, dacă nu am vorbit despre versiuni incrementale, asta ar fi...

Vitaly: Am făcut-o. E prea târziu, acum. Acest card a fost deja trecut. Avem nevoie de altceva.

Phil Hawksworth: Deci...

Vitaly: Ce vreau să spun, ca pe o platformă, dacă te uiți la platforma din spate, se întâmplă atât de multe lucruri interesante. Avem Houdini, avem componente web care vin și totul, deoarece ați putea schimba întregul peisaj al tuturor componentelor potrivite. Pe de altă parte, avem toată această lume magică, fantezică cu SS NGS și, desigur, evident, avem și aplicații cu o singură pagină și tot. De ce ești cel mai entuziasmat?

Phil Hawksworth: Voi fi obtuz aici, pentru că sunt atât de multe lucruri care se întâmplă, sunt interesante și există atât de multe capacități noi pe care le puteți folosi în browser. Lucrul de care mă încântă cu adevărat este că oamenii dau dovadă de reținere (râde) și, așa cum am spus, răspunsul plictisitor, dar îmi place să văd execuții grozave care se fac cu reținere, într-un mod atent - despre publicul larg. Este foarte distractiv și îmbucurător să construiești cu cea mai strălucitoare bibliotecă JavaScript nouă sau cu noul API de browser care, nu știu, zgârie și adulmecă capabilitățile browserului, de care avem nevoie disperată, în orice zi.

Phil Hawksworth: Dar îmi place foarte mult să văd lucruri despre care știu că vor funcționa în multe, multe locuri. Vor fi cu adevărat performanti, vor simpatiza cu browserele care există - nu doar pe birourile directorilor executivi și CTO care au primit jucăriile elegante, ci și pe oameni care au dispozitive cu o putere mult mai mică sau ei. Am condiții de rețea dificile și astfel de lucruri. Îmi place să văd experiențe interesante și experiențe bogate, livrate într-un mod care să fie înțelegător cu platforma și un fel de compasiune pentru publicul mai larg, pentru că cred că web-ul ajunge mult mai departe decât noi, dezvoltatorii, care construim lucruri pentru el. . Și sunt entuziasmat văzând lucruri interesante făcute, în moduri care ajung la mai mulți oameni.

Phil Hawksworth: Probabil că acesta nu este răspunsul pe care l-ai fost neapărat...

Vitaly: Oh, ăsta e un final frumos. Mulțumesc mult. Nu, este perfect, chiar așa este. Bine, am simțit că totul a mers bine! Vă mulțumim foarte mult că sunteți alături de noi! Îi dau lui Scott!

Phil Hawksworth: Grozav!

Vitaly: Sunt aici doar pentru a juca întrebări și răspunsuri. Deci, mulțumesc mult, Phil! Sunt încă aici, dar Scott, scena este a ta, acum! Poate ne poți împărtăși ce urmează pe Smashing TV?

Scott: O voi face, dar mai întâi, Phil, abia aștept să văd cum funcționează implementarea API-ului scratch-and-sniff. Sună foarte interesant. Și, Vitaly, JAMstackify este deja luat.

Vitaly: (abatut) Luat?! O putem cumpăra?

Scott: Nu, există!

Vitaly: Ei bine, e prea târziu. Întotdeauna întârzii.

Phil Hawksworth: Este interesant în felul său.

Vitaly: Asta e povestea vieții mele. Întotdeauna întârzii.

Scott: Membrii care urmează, cred că, joi, 13, îl avem pe bătrânul meu, Zach Leatherman, care vorbește despre ceea ce vorbește cel mai bine, adică fonturile. Deci, el vorbește despre cei cinci Y ai implementărilor fonturilor. Și apoi, sunt foarte interesat și de cel pe care îl avem pe 19, care este editarea video, cu JavaScript și CSS, cu Eva Faria. Așadar, rămâneți pe fază pentru ambele.

Scott: Deci, asta este din nou, joia viitoare, cu Zach Leatherman, iar apoi pe 19, cu Eva, care va vorbi despre editarea video în JavaScript și CSS. Deci, pe această notă, Phil, nu te mai văd, mai ești acolo?

Phil Hawksworth: Sunt aici!

Scott: În această notă, mulțumesc frumos tuturor! De asemenea, este cineva în, cam aproape de zona Toronto? Sau cineva care a vrut vreodată să viziteze Toronto? Avem o conferință care urmează la sfârșitul lunii iunie și mai sunt câteva bilete rămase. Deci, poate ne vedem pe unii dintre voi acolo.

Vitaly: Mulțumesc mult, tuturor celorlalți!

Vitaly: A , apropo, încă ceva! Poate Phil a menționat asta, dar avem și conferința JAMstack la Londra, în iulie. Deci, este ceva de care trebuie să fii atent. Dar mă închid și mă duc să-mi iau salata! Nu sunt sigur ce tu...

Scott: Bine, la revedere, tuturor!

Vitaly: Bine, la revedere, tuturor.

Asta e un Wrap!

Mulțumim din tot sufletul membrilor Smashing pentru sprijinul lor continuu și amabil – și abia așteptăm să găzduim mai multe seminarii web în viitor.

De asemenea, Phil va fi MCing la SmashingConf Toronto 2019 săptămâna viitoare și la JAMstack_conf — ne-ar plăcea să vă vedem și acolo!

Vă rugăm să ne spuneți dacă găsiți această serie de interviuri utilă și pe cine ați dori să luăm un interviu sau ce subiecte ați dori să tratăm și ne vom ocupa imediat.