Bene e benvenuti su Geekbar, un'altra settimana e un altro episodio oggi però sono da solo e in realtà sento un po' questa solitudine ma non preoccupatevi durerà veramente poco perché sto già preparando un'altra serie di interviste con una serie di ospiti super interessanti ho già spoilerato qualcosa nel gruppo Telegram ma presto saprete di più Detto questo, prima di iniziare, come sempre, vi devo ricordare i nostri contatti info@gitbar.it via email o @brainrepo su Twitter nel nostro gruppo Telegram, mi raccomando iscrivetevi se non l'avete ancora fatto cercandolo nella casellina di ricerca @gitbar e poi in tutti gli aggregatori di podcast però detto questo, piccola pausa e iniziamo Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Non amo usare le giustificazioni ma questa settimana è stata terribile tanto che non sono riuscito a organizzare, a collegare tutto, nel senso collegare il calendario con gli ospiti che avevo pianificato per cui tutte le interviste sono saltate alla settimana prossima.quindi aspettatevi delle novità.Per cui sono rimasto solo soletto e come nei bei vecchi tempi ho preparato una puntata monografica.In realtà non ho avuto granché tempo di preparare questa puntata, però ci sono un po' di cose che volevo condividere con voi.In quest'ultimo periodo mi avete parlato tanto di Gatsby e di Next.js E' proprio su questo che vorrei incentrare la chiacchierata di oggi, anche perché questi giorni mi trovo a lavorare nel porting di un sito per un cliente da Jigsaw, che è un generatore statico di siti web fondamentalmente, a Gatsby.qua si apre tutto un mondo relativo al gem stack mondo che devo dire abbiamo iniziato ad affrontare in una dei primi episodi in uno dei primi episodi dei primissimi episodi di github l'episodio numero 9 ma che riprendiamo in mano dopo un annetto circa o poco meno Cercando di ampliare un po' la visione mettendo sul tavolo quelli che secondo me sono i due player che entrano di petto nel mondo del Jamstack.Ma innanzitutto prima di parlare di Jamstack e di utilizzarlo come termine centrale, diamo un po' un senso a questa parola.Allora, Jamstack è un acronimo dove gli elementi fondamentali sono appunto le lettere che vanno a comporre la parola gem."J" sta per JavaScript, "A" sta per API e "M" sta per markup.Quindi parla di tutte quelle tecnologie che utilizzano da una parte il JavaScript per dare interazione ai nostri siti, dall'altra l'API per attingere ai dati e dall'altra il markup quindi l'html e mettiamoci anche il css anche se non è propriamente markup per dare poi la presentazione da una parte strutturale dall'altra estetica delle nostre pagine.Occhio che però è un po' improprio mettere l'elemento e la voce API in questo termine anche perché le API non sempre sono l'elemento centrale per la generazione di questi siti ma lo andremo a vedere dopo.Per cui andando poi a mettere un po' di tassellini sul significato di JAMstack possiamo definirlo come un'architettura che si pone come obiettivo quello di in qualche modo strutturare un web che sia un pochino più moderno e che abbracci una serie di caratteristiche che sono dei benefici molto importanti appunto nel mondo del web.In primis è la velocità.Perché? Perché tutti i siti che entrano poi nell'ecosistema di Jamstack sono dei siti prevalentemente statici.Questo vuol dire che in realtà la struttura viene generata una volta, attraverso appunto delle operazioni di pre-rendering che possono essere fatte a build time e una volta che generate abbiamo una pagina da servire, abbiamo un file da mandare al browser e tutto questo fa sì che la distribuzione di queste informazioni il time to first byte e quant'altro sia comunque molto molto molto veloce.Dall'altra parte abbraccia il concetto della sicurezza eliminando la necessità quindi di un web server che deve elaborare qualcosa per restituire la pagina certo è che riduciamo la superficie ad attacco e quindi la nostra struttura di conseguenza sarà più sicura e sarà tanto più sicura quanto sarà facile scalare con questa struttura perché servendo esclusivamente delle pagine statiche il nostro sito scalerà molto molto bene e abbraccerà anche la caratteristica della portabilità.Ognuno di noi sa che quando deve rilasciare un sito deve guardare le caratteristiche dell'hosting che lo ospita.Se io decido di pubblicare un WordPress a quel punto dovrò guardare se l'ecosistema, l'hosting che in qualche modo farà girare e ospiterà il mio sito sia in grado, nel caso di WordPress, di far girare i PHP.questo non è più necessario perché perché essendo delle semplici pagine html beh la portabilità è un elemento fondamentale un elemento centrale che appunto gli permette di essere rilasciate praticamente dappertutto.Un altro elemento molto interessante è il concetto di atomic deploy.Gemstack spesso si basa sul ragionamento del pre-rendering.Quindi quando viene renderizzato il sito, cosa vuol dire renderizzato il sito? Prendo da una parte il contenuto, dall'altra il markup, metto tutto insieme e mi escono delle pagine HTML con del JavaScript e del CSS.Quando io faccio questa operazione io ho uno stato atomico della applicazione, cioè uno stato che la descrive nella sua interezza dove la modifica è autocontenuta e questa è una caratteristica importante appunto del rilascio in ambiente con l'architettura gemstack.Però a questo punto sorge un ragionamento necessario quando si lavora con questo tipo di stack.Perché? Perché questo tipo di stack è entrato prepotentemente nel panorama del web e spesso lo si abbraccia, abbracciandone i dolori e i benefici, anche quando magari non è il caso di utilizzarlo.E qua emerge appunto la necessità di fare un ragionamento prima dell'utilizzo di questo stack, di questa architettura.Quando si fa un ragionamento di questo tipo, specie questo, mi piace riferirmi sempre a un grafico, uno schema fondamentalmente mentale, che Michael Geers ha pubblicato nel suo libro Micro front end in action che ho qua con me, quando parla, edito da Manning, quando parla di document to application continuum, cioè ci sono dei ragionamenti da fare, delle analisi da fare quando noi andiamo a sviluppare l'elemento che vogliamo pubblicare sul web.Questa cosa può sembrare molto complessa ma è semplicissima.Cioè dobbiamo chiederci l'elemento che io sto andando a rilasciare è un documento o è un'applicazione? Cioè fornisce come elemento centrale esclusivamente delle informazioni che vengono fruite in modo statico oppure genera delle esperienze attraverso l'interattività.E qua la domanda, la risposta a questa domanda diventa difficilissima.Per rispondere a questa domanda è necessario considerare la definizione dell'elemento che vogliamo creare non in modo statico, non a compartimenti stagni cioè non è o bianco o nero ma dal concetto di documento al concetto di application c'è tutta una gradazione di grigio che poi è quella gradazione di grigio che va a definire va a raccontare va a raggruppare tutte le progressive web app e molte delle single page app.Chiudiamo per un attimo questa parentesi.Insomma quello che noi dobbiamo chiederci è se la nostra applicazione è content centric quindi il core centrale della nostra applicazione è basata sul contenuto o behavior centric è basata sull'interazione.Ed ecco che riemerge, quando noi ci spostiamo nella parte più content-centric, riemerge una figura, anzi due direi, figure che sono state ai vertici per tanti anni per quanto riguarda la generazione di siti.Sono Jekyll che si basa su Ruby e Hugo, o Hugo, non saprei come pronunciarlo voi ormai lo sapete che io con le pronunce sono una schiappa totale che si basa su Go.Cosa, che particolarità hanno questi due generatori di siti statici? Fondamentalmente utilizzano dei template engine, nel caso di Jekyll utilizzano Liquid che è un template engine tipico di Ruby o nel caso di Hugo utilizzano Go Templates e cosa fanno a fare vanno a attraverso questi template unire del contenuto, in caso di Jekyll Markdown, nel caso di Hugo, o Jason, Yammel, Toml, Markdown e vanno a poi a generare delle pagine HTML.Di qui abbiamo tanti vantaggi tipici del JAMstack che vi ho raccontato prima.Però oggi qualcosa cambiata.Dopo l'uscita di Yugo e Jekyll un sacco di cose in realtà nel panorama dello sviluppo web sono apparse prepotentemente.Adesso io non so precisamente la posizione, non sono andato a vedermi precisamente la posizione nella timeline, però diciamo che React è entrato prepotentemente nel panorama dello sviluppo web e con React è entrato anche un modo di creare fondamentalmente dei layout.Da una parte l'interattività che questa che questa libreria ci ci dà, dall'altra il fatto della sua adozione massiva ha fatto sì che in un modo o nell'altro questa libreria stessa prendesse posto nel mondo dei generatori statici di pagine html di siti.Un elemento che in realtà ha bustato questa questa dozione è stato il fatto che React ha sviluppato un modo per far sì che le applicazioni React potessero essere renderizzate anche lato server side.Potendo essere renderizzate quindi trasformate in html fondamentalmente attraverso appunto l'uso del server side utilizzando node, beh a quel punto React ha preso il bollino, il ruolo, uno dei ruoli di React è diventato il fatto di essere anche un template ng.La particolarità di React e anche la contraddizione fondamentalmente è che React è pensato per l'interattività e immaginarlo a costruire, a disegnare una pagina statica potrebbe essere una forzatura.Però è anche vero che la generazione, lato server-side o lato building, momento di build poi lo andiamo a vedere nel dettaglio, delle nostre pagine genera dell'HTML che però può essere idratato lato client per diventare poi interattivo.Immaginate come quando acquistate il latte leofilizzato, voi lo mettete sul tavolino ma poi ci aggiungete l'acqua e tutto il latte diventa latte reale e così allo stesso modo agisce una pagina.perché? perché viene generato dell'html, la struttura di questa html viene definita utilizzando react e quindi utilizzando JSX e contestualmente lato client quando verrà visualizzato a quel punto diciamo si animerà, prenderà vita perché react si attiverà e andrà a cambiare solo quello che poi va a cambiare con l'interazione.Un altro elemento che è entrato di prepotenza nel mondo della generazione di siti statici è l'MDX.Per parlare dell'MDX dobbiamo fare due passi indietro e tornare a parlare del Markdown.Una delle fonti di contenuto che utilizzavano Jekyll e Hygge è il Markdown.Infatti la caratteristica di questi generatori statici di siti è che tu tu puoi o potevi scrivere dei contenuti direttamente come file markdown quindi molto asciutto senza troppa sintasi senza troppo boilerplate contenuto che poi veniva iniettato e strutturato all'interno di questi template.Con l'avvento di React e con credo anche l'evoluzione delle tipologie di pagine che si pensano, si stanno sviluppando, si è affacciato all'orizzonte un nuovo concetto di Markdown chiamato MDX.Cosa permette l'MDX? L'MDX è come diciamo un'ibridazione tra il Markdown e il JSX.JSX come sapete bene è il linguaggio di template che React usa e serve per definire i React Element scusate ma la particolarità è che noi possiamo con MDX inserire all'interno del nostro Markdown direttamente dei componenti JSX e quindi tenere l'eleganza, l'essere dry asciutto del markdown ma allo stesso tempo munirlo, aumentarlo con la potenza data appunto dai componenti scritti in JSX.Su questo ci sarebbe da fare una puntata anzi io me l'appunto e poi magari ne riparliamo tra un po'.e comunque diciamo il mondo corre veloce e forse quei template engine come go templates e liquid template engine o blade utilizzato da jigsaw forse non sono più sufficienti per creare dei siti che possano arrivare a quei livelli in realtà credo che molto dipenda dall'esperienza di sviluppo che sia ormai React è entrato prepotentemente ovunque quindi trovarcelo anche in questo contesto potrebbe non essere una cosa così stupefacente e quindi con l'ingresso di React in questo mondo, beh, sono apparsi una serie di player.Due dei più famosi sono Gatsby e Next.js.In realtà Gatsby e Next.js differiscono per alcune caratteristiche che poi andremo a vedere, che è anche diciamo la domanda che molti di voi mi hanno fatto però voglio fare sempre due passi indietro e provare a guardare il mondo di React.Solitamente quando sviluppiamo un'applicazione React la prima cosa che ci viene insegnata è quella di aprire il nostro terminale e scrivere npm create react app.In questo caso creiamo, avviamo, gettiamo le basi per un progetto React.Cosa fa Create React App? Create React App va a costruire la struttura, il boilerplate di un progetto, ma crea questo boilerplate molto basico, non troppo opinionato che poi, come molti di voi sanno, è uno dei motivi per cui amo React.ma probabilmente noi abbiamo bisogno di qualcosa in più qualcosa in più può per esempio essere avere delle linee guida su come costruire su react e qui entrano in gioco gatsby e next Vi ci tengo sempre a ricordare a tenere a mente quella sfumatura di grigio che è il continuum tra app e sito perché in funzione proprio di questo continuum di queste gradazioni di grigio noi andremo a scegliere anche la tipologia di framework da utilizzare se utilizzare create react app che ci lascia praticamente abbastanza liberi quasi a pascolo brado nello sviluppo della nostra applicazione che gira su client quindi che fa le chiamate adjax sul nostro server o se utilizzare Gatsby e Next che vanno oltre a fornire delle linee guida in termini di sviluppo vanno anche a risolvere alcuni limiti che Create React App possiede.Fondamentalmente qual è il contesto? Il contesto vede Gatsby come uno strumento per la generazione di siti statici quindi siti che non hanno bisogno di un server che gira con PHP o con Node che risponde alle domande ma semplicemente di un server che risponde a ogni chiamata http col filetto html javascript css necessario per soddisfare quella richiesta.Dall'altra nextjs che nasce in realtà con un fine un pochino diverso che è quello di fornire delle pagine renderizzate lato server quindi con un runtime che genera le pagine e le restituisce indietro un po come fanno i nostri siti con laravel, i nostri vecchi siti con rails e quant'altro.Ok ok però next ha delle caratteristiche che in realtà gli permettono per esempio tra le tante cose di andare a generare anche lui un sito statico quindi a generare delle pagine html javascript e css direttamente in fase di build.Naturalmente come potete immaginare l'approccio alla generazione di questi file è molto diverso ma prima di parlare dell'approccio verso la generazione di questi file ci tengo a fare il punto sui vari concetti client-side rendering, server-side generation e server-side rendering.Sono delle sigle che troviamo spesso quando leggiamo di questi framework chiamiamoli così poi magari anche in proprio e a queste etichette probabilmente anche necessario aggiungere a fiancare dei significati.So che molti di voi queste cose le sanno però credo che sia anche importante fare un pochino il punto e provare a inquadrare la panoramica in modo in modo generale.e arrivato il momento di stappare le birre perché Hangtime23 ci ha offerto tre birre a testa per cui noi beviamo alla sua salute e lo ringraziamo per aver supportato il nostro podcast e mi raccomando quando ci invitate le birre ricordatevi di scrivere il vostro nome così vi possiamo ringraziare nel migliore dei modi intanto ce la beviamo.Quando si parla di client-side rendering si parla di quel processo di renderizzazione che avviene sul client quindi quando il client attinge i dati magari attraverso l'accesso a delle API è in fase di visualizzazione quindi all'interno del browser unisce i dati con la struttura questo è il comportamento tipico di create react app di cui vi parlavo prima come funziona precisamente il flow è così la pagina intanto io richiedo una pagina e la pagina mi viene restituita dal server in questa pagina non ci sono i dati non ci sono le informazioni è solo la struttura insieme alla pagina mi viene restituito anche il css e del javascript ma questa pagina come vi dicevo non ha i dati per cui in fase di caricamento quando avete caricato la pagina nella pannella nel browser sarà la pagina stessa a chiamare l'api e a richiedere i dati e magari contemporaneamente mostrare il caricamento quando il server risponde il client prende i dati e a partire da questi dati utilizzando react.jsx va a mostrare a strutturare la vista.Questo è il comportamento tipico delle single page application ed è ciò che rende la nostra pagina molto veloce.In realtà riceviamo una pagina abbastanza leggera e poi abbiamo un time to first byte molto molto rapido perché? Perché non essendoci nessuna renderizzazione lato server, il nostro server deve restituirci semplicemente quello skeleton, quella struttura che poi si occuperà di fare le chiamate.Quindi una cosa che può fare senza troppi calcoli e senza troppa esigenza computazionale.Quali sono però i contro? Beh, che non esiste un pre-rendering iniziale, quindi coi dati.per cui la pagina che viene restituita è una pagina che non mostra come vi dicevo prima le informazioni e questo potrebbe essere negativo per il SEO o per la SEO perché può essere negativo? perché sappiamo che i motori di ricerca prediligono, pur indicizzando i contenuti che vengono caricati dinamicamente entro un lasso di tempo limitato quindi i primi secondi del caricamento della pagina adesso non so esattamente fino a quando cioè il momento in cui i crawler dei motori di ricerca hanno un timeout in fase di attesa di renderizzazione però i dati che arrivano a questo crawler sono uno skeleton vuoto senza le informazioni quindi il motore di ricerca più difficilmente indicizza questo tipo di applicazioni applicazioni che vediamo spesso utilizzate magari per mostrare i contenuti dietro paywall per fare una dashboard un e-commerce e se noi dobbiamo proiettare questo tipo di approccio all'interno del nostro documento tu application continue quindi quella sommatura di grigio stiamo molto sulla parte dell'application e magari un po meno sulla parte del document perché già di per sé il concetto di document presuppone che ci sia tanto contenuto e tanto contenuto forse ha senso che sia indicizzato sui motori di cerca anche se qua ci va un dipende è grande grande come una casa l'esempio per esempio l'esempio dei dei dei paywall potrebbe essere uno di questi A seguire c'è l'approccio un po' vecchio.L'approccio che abbiamo utilizzato tanti anni con Wordpress o Drupal che è appunto l'approccio server-side-render.Questo approccio diciamo presuppone che sia il server che generi la pagina e che quindi invì questa pagina al client.Cosa succede? Io richiedo una pagina, il server riceve la mia richiesta, crea partendo dal template la mia pagina e la restituisce già bella completa.Questo è il classico approccio alla Next.js.Occhio che per avviare questo tipo d'approccio noi abbiamo bisogno di un runtime che gira sul server quindi abbiamo bisogno di un serverino che faccia questo tipo di operazioni ogni volta che il nostro utente richiede la nostra pagina quindi sarebbe come fare un salto indietro nel tempo però occhio che ci sono delle particolarità specie abbracciando next.js che rendono da una parte indispensabile questo tipo d'approccio dall'altra molto potente.Quali sono i pro di questo approccio? Intanto che la pagina che viene restituita contiene già il contenuto quindi non ci sono dei caricamenti da aspettare, dei loadings da mostrare nella pagina presuppone che il contenuto possa cambiare costantemente e allo stesso tempo riesce a soddisfare quei requisiti tipici che ci vengono richiesti dall'asseo quindi il fatto di restituire una pagina già con le informazioni beh quello è un vantaggio mica da ridere.Ci sono però dei contro.Uno di questi è il time to first byte che è comunque più lungo.Che cos'è il time to first byte? Come vi ho detto prima è il momento in cui il server inizia a inviare il primo byte di dati verso il client.Questo lasso di tempo è conseguente al tempo che ci mette il nostro runtime a prendere i nostri documenti, prendere il nostro template insieme al template engine andare a mergeare per creare poi la risposta da servire.Un altro contro è che diventa veramente più difficile utilizzare delle cdn per servire questo tipo di contenuti e in più nel caso specifico di un ecosistema con javascript il pre-rendering quindi la creazione di questa pagina statica avviene in un contesto che è quello del server quindi nel contesto di node questo fa sì che in fase di pre-rendering di generazione della pagina statica non si abbia la possibilità ad accedere alle web api come il contesto che ne so window o document che su node non esistono.Quando a senso usare questo tipo d'approccio? Questo tipo d'approccio ha senso usarlo quando ci sono tante pagine da mostrare e quindi si ha bisogno di magari pagine che cambiano frequentemente si ha bisogno di dare un'informazione sempre fresca e in funzione della richiesta che arriva.Di contro, ci sono delle condizioni tali per cui non è necessario che questa informazione sia sempre fresca o meglio questa informazione non cambia così costantemente così rapidamente in lassi di tempo così veloci per cui c'è un contesto dove ha senso generare staticamente una volta le pagine statiche e poi servirle come se fossero dei semplici file.Entriamo nel mondo del server side generation.Cosa fa? In fase di build, quindi di creazione di costruzione, in fase di build, il nostro sistema va a generare tanti filetti HTML.realtà poi va a generare tanti filetti javascript e nel caso specifico di Gatsby e di Next anche dei file JSON.Poi vi spiego anche il dettaglio di questo che è file che vanno a identificare le varie pagine del nostro sito e vengono generati in fase di build.Vengono generati quindi quando la nostra macchina o il nostro sistema di continuous pipeline di building nel nostro sistema di continuous integration avvia la creazione di queste di queste pagine questo fa sì che quando il nostro client richieda un'informazione avendo noi buildato costruito a priori tutte queste paginette possiamo servirle in modo molto veloce eliminando completamente o riducendo al minimo il time to first byte perché la pagina è già generata dobbiamo solo andare a prenderla e servirla e permettendoci di utilizzare delle cdn ci sono dei contro anche in questo caso con questo approccio.Il contro è il fatto che la fase di building se il nostro sito è molto grande diventa lento, molto lento.Quando i contenuti scalano crescono diventa quasi impossibile buildare sotto i 15-20 minuti, un'ora.Gatsby ha inventato delle soluzioni come il conditional page builds o l'incremental builds, ma secondo me non siamo ancora allo stato dell'arte.Per cui c'è questo tipo di problema.E poi un altro problema che ci trasciniamo.anche qua le pagine vengono generate nel contesto di node nel nostro server nel nostro caso nel nostro computer o nella pipeline di building quindi di build quindi il contesto di generazione nel contesto node non ho accesso a API e un contesto che non è uguale perfettamente al contesto di esecuzione queste sono diciamo le tre modalità c'è però da fare un piccolo una piccola nota a margine sia per quanto riguarda il server side rendering che il server side generation quello che otteniamo nel caso del server side rendering grazie al runtime la server side generation perché è stato fatto in fase di build è una pagina html che ha quel contenuto.In realtà però Next e Gatsby ci danno una cosa in più.Next e Gatsby nascono in un contesto dove esiste React quindi dove l'esigenza di avere delle applicazioni responsive interattive anche se trattano dei contenuti è molto sentita e molto forte per cui probabilmente non è sufficiente avere delle pagine di contenuto.E se queste pagine di contenuto in qualche modo utilizzando gli approcci alla Jekyll e a Yugo ravvivavamo con l'utilizzo di JavaScript custom, noi attraverso l'uso appunto di react abbiamo la cosa di cui vi dicevo prima cioè la reidratazione quindi cosa succede il server nel caso del server side rendering o l'eventuale cdn nel caso del server side generation mi restituisce una pagina html con già i contenuti dentro un javascript quando la pagina viene completamente caricata il file javascript viene eseguito il file javascript fondamentalmente si basa su react quindi diciamo che react si attiva cerca di capire fa le sue esecuzioni cerca di capire cosa è diverso da quello che il server ha generato o la nostra macchina la la pipeline di build ha generato e lo va a sostituire creando e dando vita e dando interazione a quelle interfacce che prima erano statiche questo credo sia rivoluzionario nell'approccio next e gasby che pur essendo diversi perché next è più concentrato sul server side rendering metto una una postina un asterisco enorme perché poi l'andremo a vedere e gasby è più concentrato sullo static side generation però il fatto che una volta che la pagina carica sul browser si possa attivare in qualche modo è la parte più entusiasmante è anche la parte che dà i superpoteri perché noi abbiamo da una parte una generazione lato server o lato build dall'altra abbiamo un'attività di client side rendering che lavora parallelamente e poi c'è un outsider cioè ci sono delle situazioni prima vi ho detto che next era più incentrato sul server side rendering quindi gira su un runtime devi avere un serverino con node che fa le sue robe e ti restituisce le pagine già con le informazioni In realtà questo non è propriamente così perché Next ti dà diverse possibilità.Say Gatsby è un sistema che ti permette di fare della generazione di siti statici un po' come abbiamo detto Jekyll e Hygge quindi in fase di build.In più cosa fa? Va a reidratare e riattivare e dare superpoteri a Quest.Next oltre a avere un runtime che serve delle pagine che poi si attivano ha anche la possibilità di generare staticamente delle pagine e la cosa bella di Next è il fatto che queste varie modalità quindi server side rendering, static site generation, client side rendering possono essere combinate in ambiti specifici della tua applicazione cioè io devo fare il mio sass ok ho bisogno di della pagina chi siamo pricing e della guida ok quella parte decido di farla generata staticamente quindi in fase di build io mi genero delle paginette html a corredo ci sono dei javascript che vengono utilizzati e dei JSON che vengono utilizzati poi per riattivare la pagina quando si fa una navigazione lato browser quindi lato javascript e non con delle chiamate dirette alla pagina e e poi posso decidere di utilizzare magari un altro approccio per il server side rendering per mostrare i prodotti nel mio catalogo prodotti perché i miei prodotti sono 100.000 se dovessi buildare le pagine una per prodotto probabilmente ci vorrebbe troppo tempo in fase di building tante energie per prodotti che magari i nostri clienti neanche vedono quindi l'approccio diciamo con next lo vedo un po più libero ci sono poi tutta un'altra serie di caratteristiche che andiamo a vedere però già questo differenzia un attimino i due framework e in qualche modo ne assegna anche un mercato, ne assegna una parte di quella sfumatura del continuum application document di cui vi parlavo prima.Però next ci dà un'altra un altro elemento.I signori di Vercel che sono poi quelli che l'azienda che è andata a creare Next ha provato a unire il concetto di server side rendering con il concetto di static site generation utilizzando un sistema a cache molto interessante che si chiama incremental static regeneration.Come funziona fondamentalmente? In fase di build il nostro server genera una pagina quindi quando il nostro client richiede quella pagina riceve direttamente la pagina con già i dati dentro.Ma cosa succede se questa pagina è tra quelle pagine che decidiamo di non generare che a questa pagina possiamo far vivere un flow diverso possiamo fare in modo che se la pagina non è generata il nostro il nostro utente quando va ad accedervi vedrà un caricamento lato client in In background il nostro client, il browser del nostro utente farà una richiesta a questa pagina.Il server cosa farà? Al posto di fare server side rendering, quindi generare la pagina e restituirla direttamente, lui cosa fa? Genera la pagina in background, restituisce la pagina al browser, ma poi la salva tra le pagine generate staticamente.Questo fa sì che l'utente successivo può accedere in tempo zero a quell'informazione.In più, in realtà, ci sono delle modalità che permettono di dare dei tempi di time out di vita alle nostre pagine e quindi rigenerarle per avere dei contenuti sempre freschi.su next ci sono tantissime possibilità da questo punto di vista.In questo caso con l'incremental static regeneration ci sono una marea di vantaggi.Intanto c'è la generazione inclementale che va a coprire un importante problema di Gatsby che vediamo tra un po'.C'è la possibilità di avere un'asseo fatta bene perché stiamo osservando delle pagine che hanno già i dati e pagine che però possono essere anche stoccate nelle cdn per essere servite molto rapidamente e adesso quindi facciamo salire su ring next e gatsby in realtà molto ho già detto sulle differenze tra questi due sistemi cioè per la generazione statica di siti possono essere utilizzati indistintamente.Ci sono delle caratteristiche che vediamo proprio adesso sulla gestione di come vanno ad attingere ai dati.Però fondamentalmente entrambi possono generare dei siti statici.Oltre ai siti statici però Next da tutto un altro ventaglio di possibilità che possono essere combinate per andare veramente a rispondere all'esigenza non solo di siti ma di siti applicazioni complesse dal mio punto di vista riescono a coprire molto più spazio di quel continuum application e document.Però iniziamo a provare a capire perché in realtà può essere utile il server side rendering o l'incremental static regeneration quindi sia la possibilità di renderizzare lato server e restituire sia il fatto di renderizzare lato server salvare in cache e restituire possono essere utili perché si è notato che con Gatsby se noi abbiamo dei siti molto grandi diciamo che il tempo di building diventa enorme.Gli sviluppatori di Gatsby hanno fatto dei test su 10.000 o 100.000 articoli utilizzando Markdown e in realtà le build diventano enormi per cui hanno sentito l'esigenza di mettere anche loro una pezza.Quindi Next ha messo il suo ventaglio di server-side rendering incremental static generation e Gatsby cosa ha fatto dal suo lato? Beh Gatsby a gennaio del 2020 quindi poco più di un anno fa ha lanciato Gatsby Cloud.Gatsby Cloud che cos'è? Fondamentalmente è un servizio che ti permette di buildare in rete il tuo sito si appoggia magari al tuo github e quando fai una una push lui attiva, triggera il building del tuo sito e lo deploia poi di conseguenza in alcuni dei loro spazi.Se non sbaglio loro basano la loro architettura su AWS ma non vorrei sbagliare.Cos'è successo però? Che ad aprile loro hanno lanciato le incremental build.cosa sono le incremental build? sono delle build che in modo intelligente vanno a vedere fondamentalmente cosa stai aggiungendo quali contenuti stai aggiungendo e vanno a buildare solo quelli.occhio che però questo servizio è disponibile solo su gatsby cloud è un boost interessantissimo perché se noi immaginiamo un sito di 8000 pagine al posto di buildare in 15 minuti builda in 4 secondi quando noi abbiamo dei siti che cambiano spesso 15 minuti contro 4 secondi fanno la differenza però come vi dicevo è disponibile solo su Gatsby cloud e soprattutto quando tu hai un sito di 100.000 articoli il problema lo senti ed è stato quello infatti diciamo l'obiettivo l'obiettivo che ha portato poi tutto lo staff di Gatsby a ragionare su un modo per ottimizzare la building fondamentalmente ci sono riusciti creando una una sorta di conditional page build quindi un sistema che capisce quale parte del sito buildare e quale non.In realtà è molto particolare perché hanno fatto un'analisi su quali sono gli elementi che attivano la build, quindi quali cambiamenti devono far partire la build.Per esempio quando cambio il codice del mio sito.In quel caso quando cambio, che ne so, la mia struttura del template deve triggerare probabilmente un full build.Quando cambia qualcosa nel file system o quando un file mdx cambia beh deve buildare solamente probabilmente il contenuto che è cambiato quindi diciamo che hanno investito parecchio diciamo sull'ottimizzazione delle performance anche se questo è del tutto opinionato quindi prendetela per quello che vale una mia considerazione quando si raggiungono questi limiti e numeri probabilmente ha senso da una parte lanciare, lasciare la semplicità dell'ecosistema di Gatsby, quindi tanti plug-in fatti anche molto bene, per andare ad abbracciare il mondo di Next dove magari ci sono meno plug-in ma veramente hai quella d'utilità per mischiare e dire ok queste pagine io le genero staticamente queste le faccio server side rendering vero è che mi devo mi dovrò pagare l'hosting dove dove far girare il runtime il server dove far girare il runtime javascript che si occupa della della generazione delle pagine dal tuo server però ciccia se è un sito di 100.000 pagine e voglio raggiungere questi questi queste performance probabilmente sono anche disposto a investire da quel punto di vista.Vi ho anticipato che Gatsby ha un ecosistema assurdo, un ecosistema che in realtà non è ancora presente su Next.Su Gatsby ci sono un gozziliardo di plugin, uno per ogni sorgente di dati.Voi immaginate una sorgente di dati? Esiste un plugin.Immaginate una funzionalità? Volete fare dei feed RSS? Ok, esiste un plugin.Volete modificare le immagini ottimizzandole per dimensione per qualità esiste un plugin volete per credetemi mettere le analitiche di google o di quale a qualunque altro sistema di a noi esiste un plugin e se veramente un plugin per tutto perché gasby è pensato per essere plugin centrico questo da una parte ti dà un ecosistema sulla me ricorda quasi adesso lancio il flame pronto per essere un un git fighter mi ricorda quasi l'ecosistema dei plugin di di di di di di wordpress perché perché qualunque cosa tu sviluppi ha senso per loro che interagisce magari quei dati o col flow col processo di building per loro ha senso svilupparla attraverso l'uso di un plugin quindi attaccandoti a quello che è il processo di generazione attraverso dei metodi all'interno del Gatsby node tu puoi praticamente fare di tutto e hai tutto bello ordinato in plugin diversi.Dall'altro canto Next non ha tutte queste funzionalità out of the box ma c'è anche da dire che svilupparle su Next se sai quello che vuoi le puoi fare molto rapidamente perché l'ambiente nel quale ti trovi è più friendly.Lo vediamo tra pochissimi secondi quando parliamo di dati, di come vengono trattati i dati, che è la differenza fondamentale tra Gatsby e Next.Per quanto riguarda invece la documentazione, entrambe le documentazioni sono fatte in modo assurdamente bene.Devo dire che la differenza è che Gatsby dà una serie di path da percorrere per diciamo apprendere tutto quello che ti serve anche abbastanza gradualmente.Next usa un approccio che mi è piaciuto tantissimo nel senso che all'inizio di ogni lezione, di ogni tutorial, di ogni pagina della documentazione lui ti fa qualche domandina per farti capire o ti chiede se hai capito quelle precedenti quindi se per caso hai qualche lacuna molto facilmente ritorna indietro e completi il gap no quindi sulle docs niente da dire per quanto riguarda la CLI quindi la command line interface per creare le applicazioni fino a qualche tempo fa in realtà erano entrambe abbastanza abbastanza crude non c'era tanto da fare si avviava il comando si generava o Gatsby o Next per Gatsby ti passava il template, il linguaggio se volete usare TypeScript e così questo tipo e ok per Next in realtà il passaggio a TypeScript era veramente banalissimo basta rinominare i file .ts aggiungere altre due cosette e praticamente il progetto è già out of the box in TypeScript e questa cosa è veramente comodissima perché in realtà ti porta a scrivere il tuo codice, il tuo codice di business quindi l'applicazione che vuoi fare in tempi rapidissimi senza perderti in boilerplate, configurazioni di web, pack che possono anche essere fighe quanto volete però alla fine ci perdi tempo e spesso ci perdi il tempo che invece dovresti dedicare per sviluppare gli elementi più riguardanti il business.Qua è uscita la mia parte da imprenditore, dall'imprenditore che fu.In realtà però la vera differenza tra i due sistemi sta su come questi sistemi trattano i dati.Perché? Perché in realtà Gatsby lo fa in un modo molto particolare.Cioè è Gatsby che decide come i dati devono essere trattati.Perché tutti i dati che fai girare nel processo di generazione del tuo sito con Gatsby passano per una struttura GraphQL.Quasi tutti sappiamo che cos'è Grafquel se andate a cercare poi tra i vari episodi di Gitbar dovreste trovare un episodio dove parlo di Grafquel uno dei primi quindi anche la qualità magari non è una delle migliori ma se dovessi raccontarvelo in un po in poche parole Grafquel è il figlio di una note di sesso folle tra SQL e JSON quindi dove io posso fare le query e richiedere dei campi dei dati così come faccio in SQL però con una struttura quasi un po' simile al JSON.Per cui cosa faccio? Quando entro inizio a lavorare in modalità Gatsby entro nell'ottica di scrivere delle query in GraphQL molto vicina al mio componente e poi sarà la mia pagina il mio componente React che poi sarà la mia pagina e delegare a Gatsby tutto il processo che fa sì che io poi in quella pagina ho i dati.In realtà questo processo lo delego a Gatsby o ai plugin che stanno accanto e che girano insieme a Gatsby e come vi ripeto ce ne sono 70 miliardi da dato a Strapi a WordPress e chi più ne ha più ne metta.Devo dire che io in alcuni contesti percepisco l'elemento GraphQL centrale forse alle volte un po' overkill, quindi sovradimensionato per in realtà quello che si va a fare, specie se il sito che si va a fare è il portfolio o il blog della situazione quindi lo percepisco molto più molto sovradimensionato e c'è anche da aggiungere che in realtà questo GraphQL è un mondo che poi in fase di deploy di produzione non esiste perché GraphQL in produzione non lo vedrei più ma avrai tanti file JSON con le strutture di dati fatte esattamente per quello che ti servono per andare poi a reidratare, nel caso ti dovesse servire, le pagine in fase di navigazione lato javascript e lato client.Next invece usa un altro approccio ed è chi segue il gruppo telegram capisce anche perché ha catturato la mia attenzione adesso veramente guardo Next con tanto interesse, utilizzo next in un paio di progetti miei e che next ti lascia libero ti da pochissimi strumenti alcuni di questi sono get static props, get static paths, mi sa che si chiamano così o get server props, la get static props ti serve per andare a prendere le informazioni nel caso stai facendo una generazione statica delle pagine, get server props nel caso stai facendo server side rendering ma l'implementazione la fai tu.E questo potrebbe essere un problema perché in realtà queste funzioni tu le trovi a fianco al tuo componente React ma queste funzioni girano su Node.Questa cosa può confondere un po' tanto che ho letto di tante persone che insomma un po trovano dei problemi perché usano relay magari all'interno.Bisogna capire bene il comportamento però sono delle semplici funzioni che tu metti accanto al tuo componente dove istruisci next su come recuperare i dati.E un po questa è la differenza base ci sono tantissime differenze tra Gatsby e Nod.Se devo darvi i miei veramente 2 cents e dire quando userei uno o quando userei l'altro beh Gatsby l'userei in siti statici piccoli e medi non enormi perché perché in realtà ti permette di essere produttivo in tempo zero hai bisogno di dimensionare l'immagine bisogna fare qualunque cosa tu hai tutto nella lista dei plugin ma se tu hai bisogno di generare qualcosa di custom in un contesto magari più da applicazione ma non necessariamente in un contesto dove magari è molto grande ti puoi permettere di avere un server o cose di questo tipo beh a questo punto può avere next in realtà next anche senso quando tu vuoi realizzare una cosa molto semplice per esempio un blog il tuo blog personale e non vuoi portarti appresso la complessità di tutto il sistema di plugin e di graph ql che gatsby insomma ti propone questa è la mia visione in realtà parlando di next ci sarebbe da dire tantissime altre cose però in realtà questa puntata era one shot molto rapida quindi non ha avuto neanche troppo tempo per prepararla ma diciamo che troveremo il modo per approfondire magari con un ospite questo questo tipo d'argomento se se vi interessa."E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Questa settimana tocca a me portare un balocco per il momento del paese dei balocchi dei baluchi ma voglio stare molto legato al tema che stiamo affrontando oggi.Infatti voglio portarvi l'informazione nel mio piccolo riguardante la Gatsby Conf, la conferenza online gratuita su Gatsby che si terrà il 2 e il 3 marzo.quindi mi raccomando se vi interessa gatsbyconf.com.Ci tengo anche a ricordarvi che tra poco, ad aprile, ci sarà il VIEW DAY organizzato dal GRUSP, una giornata interamente dedicata a VIEW.js.Io sono la persona meno adatta a parlare di view comunque è una conferenza molto interessante che si terrà online sono aperte le call for paper quindi mi raccomando se siete interessati a fare un talk o a proporre il vostro talk beh potete andare direttamente su 2021 punto view day punto it e avete la possibilità di applicare appunto per proporre il vostro talk contestualmente anche perché siamo partner del GRUSP in questo in questo progetto community partner del GRUSP abbiamo la possibilità di avere un biglietto gratuito per la conferenza è un codice sconto sempre per andare e vedere la conferenza quindi da una parte vi chiedo una mano per suggerirmi il modo migliore per assegnare questo ticket gratuito quindi se avete delle idee mi raccomando proponetele dall'altra se siete interessati ad avere questo ticket sconto mi raccomando entrate nel gruppo telegram e scrivetelo e miracolosamente pioverà dal cielo.Spero che questo episodio vi sia piaciuto.Forse vi sarete anche un po' annoiati ma per me era importante oltre a condividere con voi la mia esperienza usando questi due strumenti anche quella di dare quelle risposte che probabilmente durante quella famosa live di Twitch del mese scorso e non sono riuscito a dare in modo compiuto e preciso quindi diciamo che questa volta ci ho provato Spero di esserci riuscito Vi ricordo i contati molto molto rapidamente info che ho c'è la github.it @brainrapper su tweet o github.it come per raggiungere il nostro gruppo telegram e vi do appuntamento alla prossima settimana dove avremo un ospite quindi non sarò da solo e con una sorpresa quindi mi raccomando stay tuned nel gruppo detto questo da Lione è tutto alla prossima ciao GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con BrainRepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica] [Musica]
