Fondamenti di JAMstack: cosa, cosa e come

Adoriamo spingere i confini del web e quindi abbiamo deciso di provare qualcosa di nuovo. Probabilmente hai sentito parlare di JAMstack, il nuovo stack web basato su JavaScript, API e Markup, ma cosa significa per il tuo flusso di lavoro e quando ha senso nei tuoi progetti?

Come parte della nostra iscrizione Smashing, organizziamo Smashing TV , una serie di webinar dal vivo, ogni settimana. Nessun problema: solo webinar pratici e fruibili con domande e risposte dal vivo, gestiti da professionisti rispettati del settore. In effetti, il palinsesto di Smashing TV sembra già piuttosto fitto ed è gratuito per i membri Smashing, insieme alle registrazioni, ovviamente .

Abbiamo gentilmente chiesto a Phil Hawksworth di organizzare un webinar spiegando cosa significa effettivamente JAMStack e quando ha senso, nonché come influisce sugli strumenti e sull'architettura front-end. Ora è disponibile anche il webinar di un'ora. Non potremmo essere più felici di dare il benvenuto a Phil al co-MC della nostra imminente SmashingConf Toronto (25-26 giugno) e alla JAMStack_conf London, che organizziamo anche dal 9 al 10 luglio di quest'anno. Quindi, entriamoci!

Phil Hawksworth: Eccellente, ok, allora entriamo nel merito. Solo per un saluto molto veloce, voglio dire che l'ho già salutato, Scott mi ha fatto una bella presentazione. Ma sì, attualmente lavoro in Netlify, lavoro nel team dell'esperienza degli sviluppatori lì. Speriamo di avere un sacco di tempo per domande e risposte ma, come ha detto Scott, se non hai la possibilità di porre domande lì, o se preferisci, puoi inviarle direttamente a me su Twitter, quindi il mio Twitter gestisce sono i miei nomi, sono Phil Hawksworth, quindi ogni volta che puoi sicuramente farmi domande su JAMstack o su qualsiasi altra cosa su Twitter.

Phil Hawksworth: Ma voglio iniziare oggi semplicemente tornando un po' indietro nel tempo a questa citazione che risuona davvero molto, molto fortemente con me. Questa è una citazione del meraviglioso Aaron Schwartz che, ovviamente, ha contribuito così tanto a Creative Commons e al web aperto e l'ha scritto sul suo blog nel lontano 2002, e ha detto: "Mi interessa non dovermi mantenere irritabile Server AOL, installazioni di Postgres e Oracle. Server AOL, ho dovuto alzare lo sguardo per ricordare a me stesso che all'epoca era un server web open source.

Phil Hawksworth: Ma questo mi suona molto forte. Inoltre, non voglio mantenere l'infrastruttura per mantenere vivo un blog, ed è di questo che stava parlando. Ed era in questo post sul suo blog ed era intitolato "Cuocere, non friggere". Stava scegliendo un termine che qualcuno che aveva recentemente costruito un CMS aveva iniziato a usare, e in un certo senso ha reso popolare questo termine sulla cottura (Cuocere, non friggere); quello di cui sta parlando è il pre-rendering piuttosto che il rendering on demand, quindi cucinare il contenuto in anticipo, piuttosto che friggerlo su richiesta quando le persone vengono a chiederlo, allontanando le cose dal tempo di richiesta e in una sorta di tempo di costruzione.

Phil Hawksworth: E quando parliamo di pre-rendering e rendering, ciò che intendiamo con questo è che stiamo parlando di generare markup. A volte mi sento un po' imbarazzato a parlare di tipo di rendering del server o di rendering isomorfo o molti di questi termini alla moda; Alcuni anni fa sono stato chiamato a una conferenza, la Frontiers Conference ad Amsterdam, quando stavo parlando di rendering sul server e qualcuno mi ha detto: "Vuoi dire generare HTML? Solo qualcosa che restituisce HTML?" Ed è, ovviamente, quello che voglio dire.

Phil Hawksworth: Ma tutto questo fa molto per semplificare lo stack. Quando pensiamo allo stack da cui serviamo i siti Web; Sto cercando di semplificare le cose, sono super entusiasta di provare a semplificare lo stack. E questo è il cuore di questa cosa chiamata "JAMstack" e voglio provare a spiegarlo un po'. La "JAM" in JAMstack sta per JavaScript, API e Markup. Ma questo non è abbastanza per aiutarci a capire cosa significa: cosa significa davvero?

Phil Hawksworth: Bene, quello che voglio provare a fare nella prossima mezz'ora circa, è che voglio in qualche modo espandere quella definizione e dare più di una descrizione di cosa sia JAMstack. Voglio parlare un po' dell'impatto e delle implicazioni di JAMstack e, sai, pensare a cosa può darci sul motivo per cui potremmo sceglierlo. Lungo la strada, cercherò di menzionare alcuni degli strumenti e dei servizi che saranno utili e, si spera, concluderò con alcune risorse in cui potresti voler approfondire e forse menzionare alcuni primi passi per ottenerti in corso.

Phil Hawksworth: Quindi, questo è il piano per la prossima mezz'ora. Ma, in un certo senso, voglio tornare sull'idea di semplificare lo stack, perché, si spera, le persone che si uniscono a questo o sono venute a guardare questo video in seguito, forse hai un'idea di cosa sia JAMstack, o forse è un termine completamente nuovo e sei solo curioso. Ma, alla fine, ci sono già molti stack là fuori. Ci sono molti modi in cui puoi fornire un sito web. Sembra che stiamo costruendo diversi tipi di infrastruttura da molto tempo, che si tratti di uno stack LAMP o MAMP o, non lo so, dello stack MEAN. Ce ne sono un sacco che fluttuano sullo schermo qui. Ce ne sono moltissimi.

Phil Hawksworth: Allora, perché mai dovremmo averne bisogno di un altro? Ebbene, JAMstack è, come ho già detto, JavaScript/API/Markup, ma se proviamo a essere un po' più descrittivi, JAMstack è pensato per essere un'architettura moderna, per aiutare a creare siti veloci e sicuri e app dinamiche con JavaScript/ API e markup pre-renderizzati, serviti senza server web, ed è quest'ultimo punto che è, in qualche modo, qualcosa che lo distingue e forse lo rende un po' più interessante e insolito.

Phil Hawksworth: Questa idea di servire qualcosa senza server web, suona magica o ridicola e, si spera, scopriremo cosa lungo la strada. Ma per cercare di fare luce su questo e descriverlo un po' più in dettaglio, a volte è utile confrontarlo con quello che potremmo pensare come uno stack tradizionale, o un modo tradizionale di servire le cose sul web. Quindi, facciamolo solo per un secondo. Esaminiamo, forse, come potrebbe apparire una richiesta quando viene servita in uno stack tradizionale.

Phil Hawksworth: Quindi, in questo scenario, abbiamo qualcuno che apre un browser web e fa una richiesta per vedere una pagina. E forse quella richiesta colpisce un CDN, ma probabilmente, più probabilmente, ha colpito qualche altra infrastruttura che stiamo ospitando, come le persone che possiedono questo sito. Forse abbiamo cercato di assicurarci che questo crescesse sotto molto carico perché, ovviamente, vogliamo uno spettacolo molto popolare e di successo. Quindi, forse abbiamo un sistema di bilanciamento del carico, che contiene una logica, che servirà quella richiesta a uno dei numerosi server Web di cui abbiamo eseguito il provisioning, configurato e distribuito. Potrebbero esserci diversi di questi server.

Phil Hawksworth: E quei server eseguiranno una logica per dire: "Ok, ecco il nostro modello, dobbiamo popolarlo con alcuni dati". Potremmo ottenere i nostri dati da uno dei numerosi server di database che eseguiranno una logica per cercare alcuni dati, restituirli al server Web, creare una vista che poi ripasseremo attraverso il sistema di bilanciamento del carico. Forse, lungo la strada, chiamando la CDN, nascondendo alcune risorse nella CDN, e dovrei chiarire, una CDN è una rete di distribuzione dei contenuti, quindi una rete di macchine distribuite su Internet per cercare di ottenere il servizio di richiesta il più vicino possibile all'utente e aggiungere cose, come la memorizzazione nella cache.

Phil Hawksworth: Quindi, potremmo riporre alcune risorse lì e, alla fine, restituire una vista nel browser, negli occhi dell'utente, che può quindi sperimentare il sito che abbiamo creato. Quindi, ovviamente, questa è una semplificazione eccessiva o una visione molto generale di come potremmo soddisfare una richiesta in uno stack tradizionale. Se lo confrontiamo con JAMstack, che esegue la manutenzione delle cose in un modo leggermente diverso, ecco come potrebbe apparire.

Phil Hawksworth: Quindi, ancora una volta, nello stesso scenario, stiamo iniziando in un browser web. Stiamo richiedendo una visualizzazione della pagina e quella pagina è già in una CDN. Serve in modo statico da lì, quindi viene restituito all'utente, nel browser e il gioco è fatto. Quindi, ovviamente, una visione molto semplificata, ma subito puoi iniziare a vedere le differenze qui in termini di complessità. In termini di luoghi di cui abbiamo bisogno per gestire il codice, profondamente il codice, tutte queste cose diverse. Quindi, per me, uno degli attributi principali di un JAMstack è che significa che stai costruendo un sito che può essere servito direttamente da una CDN o anche da un file server statico. CDN è qualcosa che potremmo voler mettere in atto per gestire il carico, ma alla fine, questo potrebbe essere servito direttamente da qualsiasi tipo di file server statico, tipo di infrastruttura di hosting statico.

Phil Hawksworth: JAMstack, in un certo senso, offre l'opportunità di ridurre la complessità. Confrontando solo queste due parti del diagramma su cui torneremo alcune volte, nel corso della prossima mezz'ora, puoi vedere che è un'opportunità per ridurre la complessità e ridurre i rischi. E quindi, significa che possiamo iniziare a godere di alcuni dei vantaggi di servire risorse statiche, e parlerò di cosa sono un po' più avanti. Ma potresti guardare questo e pensare: "Beh, fantastico, ma questo non è solo il nuovo nome per i siti Web statici?" È una cosa ragionevole da criticare quando dico: "Serveremo le cose in modo statico".

Phil Hawksworth: Ma voglio tornare su questo. Voglio parlarne un po' di più, ma prima di tutto, voglio, in qualche modo, parlare di questa nozione di stack e cosa diavolo è uno stack, comunque? E penso a uno stack come ai livelli di tecnologia che forniscono il tuo sito Web o applicazione. E non stiamo parlando della pipeline di compilazione o del processo di sviluppo, ma certamente il modo in cui serviamo i siti può avere un grande impatto su come sviluppiamo e come distribuiamo le cose, e così via.

Phil Hawksworth: Ma qui stiamo parlando dello stack tecnologico, dei livelli di tecnologia che effettivamente forniscono il tuo sito Web e la tua applicazione agli utenti. Quindi, facciamo un altro piccolo confronto. Parliamo per un secondo dello stack LAMP.

Phil Hawksworth: Lo stack LAMP, come ricorderete, è costituito da un server Web Apache, per eseguire operazioni come l'instradamento HCP e il servizio di risorse statiche. PHP, per un po' di pre-elaborazione, un'elaborazione ipertestuale così carina; applicando la logica, magari costruendo le viste per i modelli e quello che hai. E ha un po' di accesso ai tuoi dati, tramite il mio NISQL, e quindi LINUX è il sistema operativo che si trova al di sotto di tutto ciò, lo mantiene tutto in vita. Possiamo concludere insieme teoricamente come questo server web. E potremmo avere molti di questi server, in un certo senso, seduti insieme per servire un sito web.

Phil Hawksworth: Questa è una specie di sguardo tradizionale allo stack LAMP, e se lo confrontiamo con il JAMstack, beh, qui c'è un cambiamento fondamentale. Qui, stiamo effettivamente salendo di livello, piuttosto che pensare al sistema operativo e pensare a come gestiamo la logica per fornire un sito web. Qui stiamo ipotizzando che serviremo queste cose in modo statico. Quindi, stiamo eseguendo l'instradamento ACP e il servizio di risorse da un server statico. Questo può essere ragionevolmente fatto. Siamo diventati molto bravi in ​​questo, nel corso degli anni, costruendo modi per fornire siti Web statici o risorse statiche.

Phil Hawksworth: Questo potrebbe essere un CDN e, ancora una volta, ne parleremo tra un momento. Ma l'area di interesse per noi sta accadendo di più nel browser. Quindi, qui, è qui che viene consegnato e analizzato il nostro markup. È qui che può essere eseguito JavaScript e questo sta accadendo nel browser. In molti modi, il browser è diventato il runtime per il Web moderno. Invece di avere il runtime nell'infrastruttura del server, ora lo abbiamo spostato su un livello, più vicino all'utente e nel browser.

Phil Hawksworth: Quando si tratta di accedere ai dati, beh, ciò accade attraverso, possibilmente, API esterne, effettuando chiamate tramite JavaScript a queste API esterne per ottenere l'accesso al server, oppure possiamo pensare alle API come alle API del browser, essendo in grado di interagire con JavaScript con funzionalità proprio lì nel tuo browser.

Phil Hawksworth: Ad ogni modo, la chiave qui su JAMstack è che, stiamo parlando di cose che sono pre-renderizzate: sono servite in modo statico e quindi, possono essere progressivamente migliorate nel browser per utilizzare le API del browser, JavaScript , e cosa hai.

Phil Hawksworth: Quindi, facciamo questo piccolo confronto fianco a fianco qui. Ancora una volta, voglio solo ribadire che JAMstack è passato di un livello al browser. E se vediamo i due lati di questo diagramma, con lo stack LAMP a sinistra ed effettivamente, lo stack JAM a destra, potresti anche pensare che, beh, anche quando stavamo costruendo cose con lo stack LAMP, siamo ancora marcatura di output. Stiamo ancora emettendo JavaScript. Potremmo ancora accedere alle API. Quindi, per molti versi, JAMstack è quasi come un sottoinsieme di ciò che stavamo costruendo prima.

Phil Hawksworth: A volte parlavo di JAMstack come dello stack assicurato, perché garantisce un insieme di strumenti e tecnologie di cui abbiamo bisogno per fornire un sito. Ma, in entrambi i casi, è un modo molto semplificato di fornire un sito che, in un certo senso, elimina la necessità che le cose eseguano ed eseguano la logica sul server al momento della richiesta.

Phil Hawksworth: Quindi, questo può fare molte cose. Questo può, in qualche modo, semplificare le implementazioni e, ancora una volta, richiamerò questo diagramma di volta in volta. Se pensiamo a come implementiamo il nostro codice e il nostro sito, per ogni distribuzione, dalla prima, attraverso l'intero ciclo di vita dello sviluppo, fino alla vita del sito web. Nello stack tradizionale, potremmo dover cambiare la logica e il contenuto per ogni riquadro di quel diagramma.

Phil Hawksworth: Considerando che, nel JAMstack, quando parliamo di distribuzione, stiamo parlando di portare cose alla CDN, ottenere cose al server statico, ed è ciò che comporta la distribuzione. La build, il tipo di logica che esegue la build, che può essere eseguita ovunque. Non è necessario che venga eseguito nello stesso ambiente che ospita il server web. In effetti, non è così! Avvia la chiave per JAMstack. Mettiamo la separazione in ciò che accade al momento della richiesta, servendo queste risorse statiche, rispetto a ciò che accade al momento della compilazione, che può essere la logica che si esegue per creare e quindi per la distribuzione.

Phil Hawksworth: Quindi, questo tipo di disaccoppiamento è una cosa fondamentale, e su questo tornerò più avanti. Siamo molto bravi a servire file statici, e portare cose su una CDN o portare cose sul file system (il file server) è qualcosa in cui abbiamo visto enormi, tipo, progressi negli ultimi anni. Ci sono molti strumenti e processi, ora, che possono aiutarci a farlo davvero bene. Solo per richiamare alcuni servizi che possono servire bene le risorse statiche e fornire flussi di lavoro per portare la tua build in quell'ambiente, sono i soliti sospetti che potresti immaginare i grandi fornitori di infrastrutture cloud, come Azure, AWS e Google Cloud.

Phil Hawksworth: Ma poi ce ne sono altri. Quindi, quello in alto a destra è un servizio chiamato Surge, che esiste da alcuni anni. Ti consente di eseguire un comando nel tuo ambiente di build e distribuire le tue risorse nel loro ambiente di hosting. Netlify, il prossimo in basso, è dove lavoro e facciamo praticamente la stessa cosa, ma abbiamo anche un'automazione diversa. Potrei approfondire un'altra volta. E quello in basso, un altro sito di ambiente di hosting statico, chiamato Now.

Phil Hawksworth: Quindi, ci sono un sacco di diverse opzioni per farlo, e tutti questi spazi forniscono strumenti diversi per raggiungere la CDN, il più rapidamente possibile. Distribuire i tuoi siti nel modo più semplice possibile. E hanno tutti qualcosa in comune in cui si basano sul principio di eseguire qualcosa a livello locale. Penso spesso a un generatore di siti statici come a qualcosa che potremmo eseguire in una build che, quando lo eseguiamo, prende cose come contenuto e modelli e forse dati da servizi diversi e genera qualcosa che può essere servito in modo statico.

Phil Hawksworth: Possiamo visualizzarlo in anteprima localmente nel nostro server statico. Qualcosa che è piuttosto semplice da fare in qualsiasi ambiente di sviluppo locale, e quindi il processo di distribuzione che lo porta nell'ambiente di hosting e, idealmente, su una CDN per ottenere, in qualche modo, una scalabilità. Quindi, con quel tipo di basi stabilite, voglio affrontare un po' di un malinteso comune quando si tratta di siti JAMstack. E non mi sono fatto alcun favore aprendo questo come descrivendo i siti JAMstack come JavaScript, API e markup. Perché l'idea sbagliata comune è che ogni sito JAMstack debba essere JavaScript, API e Markup, ma questo genere di cose che abbiamo trascurato è che non dobbiamo usare tutti e tre — ognuno di questi è, una specie di , facoltativo. Possiamo usarne tanto, o poco, quanto vogliamo. Allo stesso modo in cui un sito stack LAMP non dovrebbe necessariamente raggiungere un database. Ora, in passato ho costruito cose che sono servite da un server Apache, su una macchina Linux, e ho usato PHP, ma non ho colpito un database e non inizierei a rinominare uno stack necessariamente per quello.

Phil Hawksworth: Quindi, se pensiamo a cos'è un sito JAMstack, allora potrebbero essere un mucchio di cose diverse. Potrebbe essere qualcosa che è stato creato con un generatore di siti statici, come Jekyll, che estrae contenuto da file YAML per creare un sito che non ha JavaScript, non colpisce affatto le API e lo serviamo su qualcosa, come GitHub Pages. Oppure, quello sarebbe un sito JAMstack. O forse stiamo usando un generatore di siti statici, come Gatsby, che è, piuttosto in un ambiente Ruby per Jekyll, ora questo è un generatore di siti statici JavaScript costruito nell'ecosistema React.

Phil Hawksworth: Potrebbe essere di nuovo il richiamo di contenuti e l'organizzazione dei file Markdown. Potrebbe arricchirlo con chiamate alle API, le API di GraphQL. Potrebbe fare cose nel browser, come eseguire l'idratazione JavaScript dei modelli di compilazione proprio lì nel browser. E potrebbe essere servito su Amazon S3. È un sito JAMStack? Sì, assolutamente!

Phil Hawksworth: Passando a un altro generatore di siti statici, Hugo, che è stato creato con Go! Ancora una volta, potremmo organizzare i contenuti nei file Markdown, aggiungendo interazioni nel browser utilizzando JavaScript. Forse non chiamando alcuna API esterna e forse ospitandola su Google Cloud. È JAMstack? Assolutamente! Vedi, sto costruendo su un tema qui. Utilizzando qualcosa come Nuxt, un altro generatore di siti statici, ora integrato nell'ecosistema View. Forse sta estraendo contenuto da diversi file adiacenti? Ancora una volta, potremmo utilizzare le interazioni JavaScript nel browser, magari chiamando le API per fare cose come l'e-commerce, servendogli un altro sito statico. Un'altra infrastruttura di hosting come Netlify, è un JAMstack? Sì!

Phil Hawksworth: Ma potremmo anche andare, sai, andare anche da questo lato della scala. E pensa a un'app web progressiva fatta a mano che abbiamo costruito artigianalmente, arrotolata a mano, JavaScript che abbiamo costruito noi stessi. Lo stiamo impacchettando con webpack. Forse stiamo usando token Web JavaScript e chiamando le API per eseguire l'autenticazione, interagendo con diverse API del browser, ospitandolo in Azure. Sì, anche quello è JAMstack!

Phil Hawksworth: E, sai, tutte queste cose, e molte altre, possono essere considerate JAMstack, perché condividono tutte un attributo in comune e cioè nessuna di esse viene servita con un server di origine. Nessuno di loro deve colpire un server che esegue la logica al momento della richiesta. Questi vengono serviti come risorse statiche e successivamente arricchiti con JavaScript e chiamate alle API.

Phil Hawksworth: Quindi, ancora una volta, voglio solo ribadire che un JAMstack significa che è in grado di essere servito direttamente dalla CDN. Quindi, voglio solo richiamare alcuni degli impatti e delle implicazioni di questo, perché perché dovremmo volerlo fare? Bene, la prima idea riguarda la sicurezza, e qui abbiamo una superficie di attacco notevolmente ridotta. Se pensiamo (tornando di nuovo a questo vecchio diagramma), i luoghi in cui potremmo avere a che fare con un attacco, dobbiamo proteggere cose come il bilanciamento del carico, i server web, i server di database. Tutte queste cose, dobbiamo assicurarci che non possano essere penetrati da nessun tipo di attacco e, anzi, dalla CDN.

Phil Hawksworth: Se più pezzi riusciamo a togliere da questo puzzle, meno posti possono essere attaccati e meno posti dobbiamo proteggere. Avere poche parti mobili da attaccare è davvero molto prezioso. In Netlify, gestiamo i nostri CDN, quindi abbiamo il lusso di poter monitorare il traffico che lo attraversa e, anche se tutti i siti ospitati su Netlify, tutti i siti JAMstack che potresti immaginare, nessuno di loro avere una pagina di amministrazione di WordPress su di loro perché è completamente disaccoppiata. Non esiste un amministratore di WordPress, ma vediamo un enorme volume di traffico, sondando cose come WP Admin, cercando modi per entrare, cercando vettori di attacco.

Phil Hawksworth: Amo davvero alcune delle cose che Kent C. Dodds ha fatto. Non so se hai familiarità con la comunità React, probabilmente hai incontrato Kent C. Dodds in passato. Non usa WordPress, ma instrada comunque questo URL, WPAdmin. Penso che lo instradasse a un video di Rick Roll su YouTube. Sicuramente ha trollato le persone che sono andate a cercarlo. Ma il punto è che, disaccoppiando le cose in quel modo e, in un certo senso, spostando le cose che accadono, accumulando tempo da ciò che accade nel tempo di richiesta, possiamo semplicemente ridurre drasticamente la nostra esposizione. Non abbiamo parti mobili al momento della richiesta. Le parti mobili sono tutte completamente disaccoppiate in fase di costruzione. Potenzialmente, completamente, beh, necessariamente su un'infrastruttura completamente diversa.

Phil Hawksworth: Questo, ovviamente, ha anche un impatto sulle prestazioni. Tornando al nostro vecchio amico qui, i punti in cui potremmo provare a migliorare le prestazioni nello stack qui, quando c'è una logica che deve essere eseguita in questi luoghi diversi. Il modo in cui ciò accade spesso negli stack tradizionali è che iniziano ad aggiungere livelli, aggiungere livelli statici, al fine di migliorare le prestazioni. Quindi, in altre parole, prova a trovare modi in cui possiamo iniziare a comportarci come se fosse statico. Non è necessario eseguire quella logica a ogni livello dello stack per accelerare le cose. Quindi, stiamo iniziando a introdurre cose come la memorizzazione nella cache in tutta l'infrastruttura e luoghi ovvi che potremmo trovare per farlo è nel server web, piuttosto che eseguire quella logica, vogliamo servire qualcosa immediatamente senza eseguire quella logica.

Phil Hawksworth: Quindi, è un po' come un passo verso, un po', l'essere pseudo-statici. Allo stesso modo nei server di database, vogliamo aggiungere livelli di memorizzazione nella cache alle query cache-com. Anche con un bilanciamento basso, l'intera CDN, puoi pensarla come una cache. Ma sullo stack tradizionale, dobbiamo capire come gestire quella cache, perché non tutto verrà memorizzato nella cache. Quindi, c'è una logica in merito. Ciò che deve essere popolato dinamicamente rispetto a ciò che può essere memorizzato nella cache. E il modello JAMstack, tutto è memorizzato nella cache. Tutto viene memorizzato nella cache dal momento in cui la distribuzione è terminata, quindi possiamo pensarci in modo completamente diverso.

Phil Hawksworth: Questo, quindi, inizia a suggerire anche il ridimensionamento. E per scala, sto parlando, come gestiamo grandi carichi di traffico? Gli stack tradizionali inizieranno ad aggiungere infrastruttura per scalare. Quindi, sì, alla memorizzazione nella cache. Stiamo iniziando a mettere a posto il nostro stack tradizionale. Questo aiuterà - in una certa misura. Ciò che accade in genere è che, per gestire grandi carichi di traffico, inizieremo a espandere l'infrastruttura e ad aggiungere più server, più pezzi per gestire queste richieste, costare queste cose e stimare il carico è un grande sovraccarico e può essere un mal di testa per chiunque faccia architettura tecnica. Certamente è stato per me, motivo per cui stavo iniziando a propendere molto di più verso l'approccio JAMstack in cui so solo che tutto è servito dalla CDN, che è progettata per impostazione predefinita per gestire la scala, per gestire le prestazioni fin dall'inizio .

Phil Hawksworth: Quindi, voglio anche fare un cenno all'esperienza degli sviluppatori e all'impatto che questo può avere. Ora, l'esperienza degli sviluppatori non dovrebbe mai essere vista come qualcosa che supera l'esperienza dell'utente, ma credo che una buona esperienza per gli sviluppatori possa ridurre l'attrito, può consentire agli sviluppatori di fare un lavoro molto migliore per creare esperienze utente eccezionali!

Phil Hawksworth: Quindi, quando pensiamo a dove vive l'esperienza dello sviluppatore e dove si trovano le aree di interesse per uno sviluppatore: beh, in uno stack tradizionale, potremmo aver bisogno di pensare a come ottenere il codice per tutti questi diversi parti dell'infrastruttura e come giocano tutti insieme. Nel mondo JAMstack, in realtà, quello di cui stiamo parlando è questa scatola qui in basso. Sai, come eseguiamo la build e loro, come automatizzare una distribuzione per ottenere qualcosa servito in primo luogo? E la cosa bella è che nel modello JAMstack, quello che fai in quella build dipende completamente da te.

Phil Hawksworth: Questo è uno spazio problematico davvero ben definito, perché in definitiva stai cercando di costruire qualcosa che puoi servire direttamente da una CDN. Vuoi pre-renderizzare qualcosa, usando qualsiasi strumento ti piaccia: che si tratti di un generatore di siti statici costruito in Ruby o Python o JavaScript o Go o PHP, hai la libertà di fare quella scelta. E quindi, ciò può creare un ambiente molto più piacevole in cui lavorare. Inoltre, crea un'opportunità per avere una vera fiducia da parte degli sviluppatori perché un vero attributo dei siti JAMstack è che possono essere molto più facilmente serviti come distribuzione immutabile e atomica.

Phil Hawksworth: E voglio, in un certo senso, saltare fuori dalle diapositive solo per un momento, per descrivere cosa significa, perché un dispiegamento immutabile e un dispiegamento atomico possono... (può suonare un po' come un discorso di marketing) ma quello che ho intenzione di fare è entrare nel mio browser. Ora... in realtà, tornerò indietro per un secondo. Lasciami... fallo e basta.

Phil Hawksworth: Eccoci qua. Questo sarà più facile. Saltando direttamente nella pagina. Ora, Scott, mi dirai, Scott, se non riesci a vedere il mio browser, spero. Ora, supponendo che tutti possano vedere il mio browser.

Scott: Sembra tutto a posto.

Phil Hawksworth: Eccellente! Grazie mille!

Phil Hawksworth: Quindi, quello che sto facendo qui, è usare Netlify come esempio, come esempio del servizio. Ma questo è un attributo comune ai siti che possono essere ospitati, in modo statico. Quindi, quando parliamo di una distribuzione immutabile, intendiamo che piuttosto che ogni distribuzione di codice deve toccare molte parti diverse dell'infrastruttura e cambiare molte cose, qui non stiamo mutando lo stato del sito su il server. Stiamo creando un'istanza completamente nuova del sito per ogni distribuzione avvenuta. E possiamo farlo perché il sito è una raccolta di risorse statiche.

Phil Hawksworth: Qui, sto guardando la distribuzione avvenuta dal mio sito web. Ti darò un regalo. Ecco a te, ecco come sembra. È solo un blog, non sembra niente di particolarmente straordinario o eccitante. È un blog generato staticamente, ma quello che ho qui è ogni distribuzione che sia mai avvenuta, sopravvive in perpetuo, perché è una raccolta di risorse statiche servite da una CDN. Ora, potrei tornare indietro il più lontano possibile dalla mia storia e andare a dare un'occhiata al sito, com'era indietro... quando è successo? Era agosto 2016. E poiché si tratta di un insieme di risorse statiche, siamo in grado di ospitarlo sul proprio URL che sopravvive in perpetuo e, se solo lo volessi, potrei decidere di entrare e pubblicarlo distribuzione.

Phil Hawksworth: Quindi, ora, chiunque stia guardando il mio sito Web, se torno al mio sito Web qui, se aggiorno quella pagina, ora viene servito direttamente dalla CDN con le risorse che erano lì prima. Ora posso navigare di nuovo. Qui puoi vedere. Guarda, stavo discutendo su questo, stavo usando questi termini terribili come il rendering isomorfo e parlando del JAMstack nel 2016. Quindi, questo è ciò che viene servito dal vivo sul mio sito. Ancora una volta, perché ci sono schieramenti reciproci che sopravvivono per sempre. Mi limiterò a mettere la mia, tipo di, tranquillità mentale, ho intenzione di — è questa la prima pagina? Sì. Tornerò alla mia ultima distribuzione. Dovrò chiudere di nuovo e riportarmi nel mondo reale. Fammi solo assicurarmi che sia tutto a posto.

Phil Hawksworth: Va bene! Grande! Quindi, ora, questo è tornato a servire la mia versione precedente o la mia ultima versione del sito. Tornerò al keynote. Quindi, questo è possibile perché le cose sono immutabili e atomiche. La parte atomica di ciò significa, ancora una volta, che lo schieramento è completamente contenuto. Quindi, non si arriva mai al punto in cui alcune delle risorse sono disponibili sul server web, ma alcune no. Solo quando tutto è presente nel contesto e tutto è lì, completo, si passa dalla pubblicazione del sito alla nuova versione. Ancora una volta, questo è il tipo di cosa che puoi fare molto più facilmente se stai costruendo cose come un sito JAMstack che serve direttamente dalla CDN come un insieme di risorse.

Phil Hawksworth: Ho notato che il mio timer si è azzerato, dopo essere andato avanti e indietro dal keynote, quindi penso che mi restano circa sei o sette minuti. Dimmi, Scott, se...

Scott: Quindi, sì, siamo ancora a posto per circa dieci minuti.

Phil Hawksworth: Dieci minuti? Ok, meraviglioso!

Scott: Non c'è fretta.

Phil Hawksworth: Grazie, dovrebbe essere buono!

Phil Hawksworth: Quindi, cambiando un po' marcia e parlando di API e servizi (poiché le API fanno parte di JAMstack), il tipo di servizi che potremmo essere in grado di utilizzare è principalmente JAMstack. Sai, potremmo utilizzare servizi che abbiamo creato internamente o potremmo utilizzare servizi acquistati. Ci sono molti fornitori diversi che possono fare le cose per noi, e questo perché questa è la loro esperienza. Attraverso le API, potremmo estrarre contenuti dai sistemi di gestione dei contenuti come servizio, e ci sono un sacco di fornitori diversi per questo, specializzati nel fornire un'esperienza di gestione dei contenuti eccezionale e quindi esporre i contenuti tramite API, quindi eri in grado di tirarli dentro.

Phil Hawksworth: Allo stesso modo, ci sono diversi modi in cui puoi servire le risorse. Persone come Cloudary sono brave in questo, per l'ottimizzazione delle immagini, per offrire risorse direttamente ai tuoi siti, ancora una volta, tramite le API. O che dire dell'e-commerce? Sai, ci sono posti come Stripe o Snipcart che possono fornirci API, in modo da non dover creare questi servizi da soli ed entrare nei problemi molto complessi che derivano dal tentativo di creare un motore di e-commerce. Allo stesso modo, identità, da persone come Auth0 che usano Oauth. Ci sono molti servizi disponibili e possiamo consumare queste cose tramite le API, nel browser o in fase di compilazione, o talvolta, una combinazione di entrambi.

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. Destra? 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 piace molto, perché il termine JAMstack può essere davvero fuorviante, perché sta cercando di coprire così tante cose diverse e il punto in cui stavo cercando di farlo, probabilmente l'ho martellato molte volte in quella diapositiva, è che può essere di tutti i tipi di cose. È così ampio, ma la chiave è il pre-rendering e l'hosting statico del nucleo dei siti. È molto facile per noi entrare in guerre di religione su dove deve essere un sito React. Deve essere un'app React, per essere un sito JAMstack, oppure è un'app React, quindi non può essere JAMstack. Ma, in realtà, il punto cruciale è che, indipendentemente dal fatto che tu usi JavaScript o meno, che tu stia chiamando API o meno, se esegui il pre-rendering e inserisci le cose in un host statico che può essere molto performante, questo è il nucleo di JAMstack.

Vitaly: Sì, assolutamente.

Phil Hawksworth: Siamo molto fortunati che i browser stiano diventando molto più capaci e le API che sono presenti all'interno dei browser stessi possono permetterci di fare molto di più. Quindi, questo tipo di apertura apre ulteriormente le porte, ma non significa che tutto ciò che costruiamo come sito JAMstack deve utilizzare tutto. A seconda di ciò che stiamo cercando di fornire, è così che dovremmo iniziare a scegliere gli strumenti con cui stiamo giocando per distribuire queste cose.

Vitaly: Assolutamente. Abbiamo Doran qui. Doran, credo di saperlo, Doran. Ho la sensazione di conoscere Doran. Sta chiedendo: "Ti aspetti che il serverless graviti verso la perfetta integrazione con JAMstack da [incomprensibile 00:44:36]? Ciò che viene chiamato A in JAM.

Phil Hawksworth: Questa è un'ottima domanda, perché penso che le funzioni serverless lo siano — vanno così bene con i siti JAMstack, perché in molti modi, in effetti, penso che una volta qualcuno mi abbia chiesto se i siti JAMstack sono serverless, e quindi mi sono distratto questa domanda, perché serverless è un termine così carico. Ma, in molti modi, è un successo perché stavo parlando, più e più volte, dell'assenza di un server di origine. Non c'è un'infrastruttura server da gestire. In effetti, una volta ho scritto un post sul blog chiamato "Web Serverless", perché il mondo ha bisogno di un altro termine alla moda, vero?

Phil Hawksworth: E davvero, il punto era, sì, stiamo costruendo cose senza server. Non vogliamo dover gestire questi server e le funzioni serverless, o funzioni come servizio, si adattano perfettamente a questo. Quindi, nei casi in cui hai bisogno di un'API a cui vuoi fare una richiesta, dove in realtà non è sensato per te fare quella richiesta direttamente dal browser. Quindi, ad esempio, se hai segreti o chiavi in ​​quella richiesta, potresti non volere che quelle richieste - quelle informazioni - siano mai esposte nel client. Ma possiamo certamente eseguire il proxy di queste cose e, in genere, tradizionalmente, ciò che dobbiamo fare è avviare un server, disporre di un'infrastruttura che effettivamente faceva poco più che gestire le richieste, aggiungere l'autenticazione di sicurezza e trasmettere tali richieste , delegandoli indietro.

Phil Hawksworth: Le funzioni serverless sono perfette per questo. Sono assolutamente ideali per questo. Quindi, a volte penso a funzioni serverless, o funzioni di un servizio, quasi come una via di fuga, in cui hai solo bisogno di un po' di logica su un server, ma non vuoi creare un'intera infrastruttura. E puoi fare sempre di più con questo e definire le pipeline di sviluppo per i flussi di lavoro di sviluppo, perché le funzioni come servizio stanno maturando. Sta diventando più accessibile per gli sviluppatori JavaScript essere in grado di creare queste cose. Quindi, sì, penso davvero che queste due cose vadano molto bene insieme.

Vitaly: Va bene, questa è una risposta molto esauriente. In realtà, ho partecipato a un discorso proprio di recente, in cui un ingegnere front-end di Amazon parlava delle funzioni serverless e Lamda che stanno utilizzando: ero quasi andato. Parlava sempre di Docker, e Kubernetes, e tutte quelle cose, Devox World, io ero seduto lì, a pensare: "Come ha fatto a finire lì. Non capisco cosa sta succedendo!” Non avevo idea di cosa stesse succedendo.

Phil Hawksworth: Esattamente, ma il fatto è che una volta era il... io ero... accettavo di non capire niente di quel mondo, ma non ne avevo alcun desiderio, dato che era per una disciplina completamente diversa . E quella disciplina è ancora molto importante. Sai, le persone che stanno progettando l'infrastruttura, questo è ancora davvero fondamentale. Ma ora sembra proprio che sono tentato. Come qualcuno con un background di sviluppo front-end, come sviluppatore JavaScript, sono molto più tentato di voler giocare in quel mondo, perché gli strumenti si stanno avvicinando, un po', a me.

Phil Hawksworth: È molto più probabile che io possa essere in grado di utilizzare alcune di queste cose e fornire le cose in modo sicuro, piuttosto che solo come un mio esperimento, che è dove ero solito pezzare. Quindi, sembra che stiamo diventando più potenti come sviluppatori web, il che è eccitante per me.

Vitaly: Come i Power Rangers, eh?

Vitaly: Voglio chiederti una cosa, però, e questo è in realtà qualcosa di cui abbiamo già discusso, forse, una settimana fa, ma volevo comunque tirarlo fuori, perché l'unica cosa che hai menzionato nella sessione era l'idea di avere un'istanza autonoma di ogni singola distribuzione, il che è davvero interessante. La domanda, tuttavia, è che se hai un compito di grandi dimensioni, con decine di migliaia di pagine, non vuoi davvero ridistribuire ogni cosa, ogni singola volta. Quindi, in sostanza, se hai, tipo, se stai principalmente usando il lato statico delle cose. Quindi, abbiamo avuto questa idea per un po' e so che in realtà è qualcosa che hai sollevato l'ultima volta. L'idea di schieramenti atomici.

Vitaly: Dove in realtà, letteralmente, ti è stata servita una sorta di div tra due diverse versioni di istantanee del set-up. Quindi, se dici di cambiare l'intestazione ovunque, allora, ovviamente, ogni singola pagina deve essere ridistribuita. Ma se si cambia, forse, un componente, come diciamo, carosello, che forse ha effetto solo su 1000 pagine, allora avrebbe senso ridistribuire 15000 pagine. Ma solo questo 1000. Quindi, possiamo arrivarci? È un'idea magica che c'è là fuori, o è qualcosa di abbastanza tangibile, a questo punto?

Phil Hawksworth: Penso che sia, probabilmente, il Santo Graal per i generatori di siti statici e questo tipo di modello perché, sicuramente, hai identificato probabilmente l'ostacolo più grande da superare. O il soffitto più grande in cui ti imbatti. E si tratta di siti Web che hanno molti, decine di migliaia o centinaia di migliaia o milioni di URL: l'idea che la build possa diventare molto lunga. Essere in grado di rilevare quali URL cambieranno, in base a una modifica del codice, è una sfida. Non è insormontabile, ma è una grande sfida. Comprendere qual è il grafico delle dipendenze nell'intero sito e quindi distribuirlo in modo intelligente: è davvero difficile da fare.

Phil Hawksworth: Perché come hai detto, un cambio di componente potrebbe avere implicazioni di vasta portata ma tu — è sempre difficile sapere come funzionerà. Quindi, ci sono un certo numero di generatori di siti statici, i progetti che stanno mettendo un po' di peso dietro questa sfida e cercano di capire come fanno la rigenerazione parziale e le build incrementali. Sono molto entusiasta che la prospettiva che possa essere risolta giorno, ma al momento è sicuramente una grande sfida. Puoi iniziare a fare cose come provare a condividere logicamente il tuo sito e pensare, ancora una volta, in modo simile al problema della migrazione. Bene, questa sezione che conosco è indipendente in termini di, tipo di, alcune delle risorse che utilizza o del tipo di contenuto che vive lì, quindi posso distribuirle individualmente.

Phil Hawksworth: Ma non è l'ideale per me. Non è proprio lo scenario perfetto. Uno degli approcci che ho esplorato un po', proprio come prova del concetto, è pensare a come si fanno le cose, come fare un uso intelligente dei 404. Quindi, ad esempio, un grande caso d'uso per segnali molto grandi, forse i siti di notizie è che quando hanno bisogno di un URL quando si verifica una notizia dell'ultima ora, devono essere i primi a farlo distribuire. Hanno bisogno di ottenere un URL lassù. Cose come BBC News, vedrai che la notizia arriverà sul sito Web, e poi gli straordinari si aggiungeranno ad essa, in modo incrementale, ma arrivare prima è la chiave. Quindi, avere una build che richiede 10 minuti, 20 minuti, qualunque cosa sarà, potrebbe essere un problema.

Phil Hawksworth: Ma se il contenuto è astratto e forse è stato chiamato da un'API. Ho menzionato i sistemi di gestione dei contenuti che sono astratti, come Contentful, o Sanity, o un sacco di quelli. Tutto ciò che ha un'API di contenuto cambia in quella struttura di contenuto che attiverà una build e andremo attraverso la corsa, ma l'altra cosa che potrebbe accadere è che, beh, se pubblichi il tuo URL per quello, e poi pubblicizzi quell'URL , anche se la build non è stata eseguita, se qualcuno ha rubato quell'URL, se la prima fermata sul suo 404 è invece di dire "Non ce l'abbiamo", in realtà è per colpire direttamente quell'API, quindi puoi dire , "Beh, la build non ha ancora finito di popolarlo, ma posso farlo nel client." Posso andare direttamente all'API, ottenerlo, popolarlo nel client.

Vitaly: Hmm, interessante.

Phil Hawksworth: Quindi, anche mentre la build è ancora in corso, puoi iniziare a popolare quelle cose. E poi, una volta terminata la build, ovviamente non raggiungerebbe un 404. Colpiresti quella pagina in esecuzione statica. Quindi, ci sono tecniche e strategie per affrontarlo, ma è comunque una risposta molto lunga e sconclusionata, mi dispiace, ma la mia conclusione è, sì, è una sfida. Incrociamo le dita otterremo strategie migliori.

Vitaly: Sì, è fantastico. Quindi, mi chiedo, quindi, a questo punto, non stiamo davvero pensando non solo a quali siano le prestazioni in termini di contenuto offerto, ma anche a quelle in termini di prestazioni in termini di velocità di costruzione. Come la distribuzione degli edifici. Quindi, anche questo è qualcosa che stiamo cercando da un bel po' di tempo ormai.

Vitaly: Un'altra cosa che volevo chiederti. Quindi, questo è interessante, come questa tecnica che hai menzionato. Come lo impari? Questo è solo qualcosa che le persone tendono a pubblicare sui propri blog o, è un mezzo o esiste un repository centrale in cui è possibile ottenere una sorta di case studio, di come JAMstack, di come le aziende si sono spostate durante lo scarico o non sono riuscite a trasferirsi JAMstack.

Phil Hawksworth: Quindi, in questo momento sta maturando un po' questo paesaggio. Voglio dire, alcuni di questi esempi, penso, sono in una posizione molto fortunata, lavoro da qualche parte in un ruolo in cui sto giocando con i giocattoli, escogitando modi interessanti per usarlo e iniziare a sperimentare con loro. Quindi, queste prove di concetti sono, in un certo senso, cose con cui posso sperimentare e provare ad affrontare queste sfide. Ma il caso di studio di cui ho parlato prima è stato mostrato alla conferenza JAMstack a New York e, certamente, eventi del genere, stiamo iniziando a vedere le migliori pratiche o le pratiche del settore e gli approcci del settore di cui si parla a quel tipo di eventi. E certamente, voglio vedere di più e lavorare su più casi di studio per arrivare in posti come Smashing Magazines, in modo da poter condividere queste informazioni molto più prontamente.

Phil Hawksworth: Penso che le grandi aziende e lo spazio aziendale stiano gradualmente adottando JAMstack, in luoghi diversi, in modi diversi, ma il mondo è ancora incline a uscire, quindi penso che ogni volta che un'azienda lo adotta e condivide i propri esperienza, tutti possiamo imparare da quello. Ma voglio davvero vedere sempre più di questi casi di studio pubblicati, in modo da poterci concentrare in particolare su come superare questo tipo di sfide.

Vitaly: Va bene, quindi, forse solo l'ultima domanda da parte mia, perché mi piace sempre leggere le domande. Quindi, la terra di JAMstack, se potessi cambiare qualcosa, forse c'è qualcosa che ti piacerebbe disperatamente vedere, al di là degli schieramenti. Qualcos'altro che ti renderebbe davvero molto felice? Questo renderebbe la tua giornata? Cosa sarebbe quello? Cosa c'è nella tua lista dei desideri, per JAMstack?

Phil Hawksworth: Che domanda. Voglio dire, se non avessimo parlato di build incrementali, sarebbe...

Vitaly: L' abbiamo fatto. È troppo tardi, adesso. Questa carta è già stata superata. Abbiamo bisogno di qualcos'altro.

Phil Hawksworth: Allora...

Vitaly: Voglio dire, come su una piattaforma, se guardi la piattaforma posteriore, ci sono così tante cose eccitanti che accadono. Abbiamo Houdini, abbiamo componenti web in arrivo e tutto il resto, dal momento che potresti cambiare l'intero panorama di tutti i componenti giusti. Dall'altro lato, abbiamo tutto questo mondo magico e fantasioso con SS NGS e, ovviamente, abbiamo anche applicazioni a pagina singola e tutto il resto. Di cosa sei più entusiasta?

Phil Hawksworth: Sarò ottuso qui, perché ci sono così tante cose che stanno succedendo, è eccitante e ci sono così tante nuove funzionalità che puoi utilizzare nel browser. La cosa che mi entusiasma davvero sono le persone che mostrano moderazione (ride) e, come ho detto, una risposta noiosa, ma adoro vedere grandi esecuzioni eseguite con moderazione, in modo premuroso, riguardo al pubblico più ampio. È davvero divertente e gratificante creare con la nuova libreria JavaScript più brillante o la nuova API del browser che, non lo so, graffia e annusa le funzionalità nel browser, di cui abbiamo disperatamente bisogno, da un giorno all'altro.

Phil Hawksworth: Ma mi piace davvero vedere cose che so funzioneranno in molti, molti posti. Saranno davvero performanti, saranno in sintonia con i browser esistenti, non solo sulle scrivanie di CEO e CTO che hanno i giocattoli sfarzosi, ma anche di persone che hanno dispositivi molto meno potenti, o loro ' ci sono condizioni di rete difficili e questo genere di cose. Mi piace vedere esperienze interessanti ed esperienze ricche, fornite in un modo che sia compatibile con la piattaforma e in un certo senso compassionevole per un pubblico più ampio, perché penso che il Web vada molto più lontano di noi, gli sviluppatori, che costruiscono le cose per esso . E mi emoziono vedendo cose interessanti fatte, in modi che raggiungono più persone.

Phil Hawksworth: Probabilmente non è la risposta che eri necessariamente...

Vitaly: Oh, questo è un bel finale. Grazie mille. No, è perfetto, lo è davvero. Va bene, ho sentito che tutto è andato bene! Grazie mille per essere con noi! Sto distribuendo a Scott!

Phil Hawksworth: Fantastico!

Vitaly: Sono qui solo per giocare a domande e risposte. Quindi, grazie mille, Phil! Sono ancora qui, ma Scott, il palco è tuo, adesso! Forse puoi condividere con noi cosa sta per succedere su Smashing TV?

Scott: Lo farò, ma prima, Phil, non vedo l'ora di vedere come funziona l'implementazione dell'API scratch-and-sniff. Sembra molto interessante. E, Vitaly, JAMstackify è già stato preso.

Vitaly: (sconsolato) Preso?! Possiamo comprarlo?

Scott: No, esiste!

Vitaly: Beh, è ​​troppo tardi. Sono sempre in ritardo.

Phil Hawksworth: È eccitante a modo suo.

Vitaly: Questa è la storia della mia vita. Sono sempre in ritardo.

Scott: I prossimi membri arriveranno, credo, giovedì 13, abbiamo il mio vecchio papà, Zach Leatherman, che parla di ciò di cui parla meglio, che sono i caratteri. Quindi, sta parlando delle Cinque Y delle implementazioni dei caratteri. E poi, sono anche molto interessato a quello che abbiamo in arrivo il 19, che è l'editing video, con JavaScript e CSS, con Eva Faria. Quindi, resta sintonizzato per entrambi.

Scott: Quindi, di nuovo, giovedì prossimo, con Zach Leatherman, e poi il 19, con Eva, che parlerà di editing video in JavaScript e CSS. Quindi, su quella nota, Phil, non posso più vederti, sei ancora lì?

Phil Hawksworth: Sono qui!

Scott: A questo proposito, grazie mille a tutti! Inoltre, c'è qualcuno nella, tipo, vicino alla zona di Toronto? O qualcuno che ha mai voluto visitare Toronto? Abbiamo una conferenza in arrivo alla fine di giugno e mancano ancora alcuni biglietti. Quindi, forse vedremo alcuni di voi lì.

Vitaly: Grazie mille a tutti gli altri!

Vitaly: Oh, a proposito, solo un'altra cosa! Forse Phil l'ha menzionato, ma abbiamo anche la JAMstack Conference a Londra, a luglio. Quindi, anche questo è qualcosa a cui prestare attenzione. Ma sto firmando e vado a prendere la mia insalata! Non sono sicuro di cosa tu-

Scott: Ok, arrivederci a tutti!

Vitaly: Va bene, ciao a tutti.

Questo è un involucro!

Ringraziamo gentilmente gli Smashing Member dal profondo del nostro cuore per il loro continuo e gentile supporto e non vediamo l'ora di ospitare altri webinar in futuro.

Inoltre, Phil sarà MCing alla SmashingConf Toronto 2019 la prossima settimana e al JAMstack_conf — ci piacerebbe vederti anche lì!

Per favore, facci sapere se trovi utile questa serie di interviste e chi vorresti che intervistassimo, o quali argomenti vorresti che trattassimo e ci occuperemo subito.