Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficace possibile quei prodotti digitali che quotidianamente utilizziamo.Eccomi qua, sono mancato una settimana e vi chiedo scusa.Siete su Gitbar, io sono Brain repo e mi sto scusando perché in realtà ho saltato l'appuntamento di giovedì scorso.L'ho saltato perché sono super impegnato col lavoro e anche questa situazione coronavirus non ha aiutato ma tranquilli non sono infetto.Non ho preparato la vera e propria puntata anche perché questo periodo sto lavorando per un grosso cliente che mi assorbe il 90 per cento del mio tempo sono in ufficio dalle 8 del mattino a mezzanotte e mezzo l'una quindi credetemi anche volendo non sono riuscito a prepararlo però voglio parlarvi di un ragionamento che ho fatto l'altro giorno quando ho iniziato a pensare di realizzare il nuovo sito di Gitbar.Il sito del podcast ad oggi è semplicemente un'installazione di Laravel buttata dentro Heroku con una paginetta e si interfaccia all'API di Spreaker per ottenere le puntate e e quindi le informazioni tipo il titolo, l'immagine e il testo e linkando poi direttamente alla pagina di speaker per l'ascolto e questo va bene però in realtà volevo qualcosa di più volevo qualcosa di più perché tutto nasce dall'esigenza di indicizzare fare un po' di SEO al sito del podcast fare un po' di SEO per cercare di posizionarlo in quella lista di risultati riguardanti appunto i podcast di programmazione in italiano.Per farlo devo produrre dei contenuti.Una delle strategie che ho pensato è quella di generare i transcript.Caricare i transcript mi permetterebbe di essere indicizzato ancora meglio.Però essendo un podcast non proprio brevissimo, durando le puntate tra i 20 e i 30 minuti, il testo trascritto diventa un pochino lungo e lo spazio dell'input di testo dato da Spricker non permette il caricamento completo.Quindi ho pensato di fare semplicemente una pagina per ogni puntata dove inserisco le note dell'episodio, la trascrizione, i link ai capitoli e tutto quello che riguarda appunto tutte le informazioni dell'episodio che voglio passare quindi buona sostanza devo rifare il sito di github attualmente è un laravel però sta su heroku potrei continuare a tenere un laravel e semplicemente implementare fare un crude per l'inserimento delle degli episodi e e quant'altro però ho pensato che forse tenere un'installazione di Laravel solo per fare un sito pseudo-statico perché in realtà di questo si tratta Alla fine c'è un'impalcatura ma alla fine dei conti è un sito che cambia una volta a settimana fondamentalmente e cambia solo di quel di quella piccola porzione cioè un episodio in più nella lista e del testo e quindi un Laravel potreva essere Qual era l'alternativa? L'alternativa è senza dubbio quella di passare a un'architettura diversa.L'architettura diversa è l'architettura così chiamata Gemstack.Gemstack, questo nome che sembra così complesso è in realtà un un acronimo molto semplice per gemstack si intende un'architettura che va a generare dei siti statici in realtà un sito gemstack se vogliamo pensare a un sito gemstack ci viene molto semplice pensare alle documentazioni dei linguaggi o delle libri richiusiamo molto spesso sono dei siti gemstack oppure i siti che vengono stati nelle github pages anche quelli il 90 per cento dei casi sono appunto dei siti fatti con architettura gemstack.Di cosa si tratta? Si tratta semplicemente di siti o applicazioni che vengono in qualche modo rilasciati distribuiti attraverso dei file pre-renderdizzati e che vengono servite attraverso le cdn quindi non hanno bisogno di un server di un web server per girare.In realtà qual è il processo? Io ho un motore alcuni li conosciamo sono molto famosi jekyll, yugo, nuxt, gazby e ce ne sono una marea, cosa fanno? non fanno altro che prendere i contenuti, mergiarli, unirli con un template e andare a generare una serie di pagine html.queste pagine sono statiche quindi sono dei semplici file html magari css che vengono poi deploiati su delle cdn quindi innanzitutto si aumenta la performance perché essendo deployati su cdn ed essendo file statici non c'è bisogno che siano passati renderizzati da server a runtime per esempio non esponendo delle api o delle chiamate server al pubblico sono sicuramente più sicuri sono più economici ed è più facile che scalino questo perché in realtà i costi di hosting su una cdn sono decisamente inferiori rispetto a tenere un web server e poi non hanno tutte le rotture di scatole dovute al mantenere un web server o del codice che gira, roture di scatole.Altra cosa importante l'architettura gemstack prevede che tutto il contenuto del tuo sito sia su git quindi sia versionato quindi insomma posso in qualche modo andare avanti o indietro nella storia del mio sito per cui se ho fatto qualche fesseria posso tornare indietro ad 1/2 commit e ripristinare il sito alla versione precedente.Questa è una cosa molto importante.Però detto questo, voglio realizzare il sito di gitbar.Lo voglio fare creando i contenuti su markdown, che è il modo più facile per crearli.Tra l'altro è possibile inserire delle intestazioni dove inizializzo delle variabili e do dei valori nella testa del markdown, valori che poi possono essere interpretati e posizionati in spazi specifici del mio template.Per farlo utilizzo un motore si chiama jigsaw e usa i componenti di laravel e prendendo in pasto una lista di pagine di file markdown e dei template in blade mi va generare a buildare un sito statico che poi io posso andare a deployare.Questa cosa è molto interessante anche perché in realtà posso riutilizzare parte delle direttive blade, degli elementi blade che mi sono fatto per il sito quando ancora pensavo di volerlo realizzare sull'arabel semplicemente cambiando i puntatori alle variabili e sarà presto realizzato.il build si fa chiamando appunto uno script da linea di comando ed è rilasciato.In realtà il vero deploy ho intenzione di farlo su Netlify.Netlify è un servizio che ti mette a disposizione una cdn è un sistema di pipeline per non di pipeline di building di ci per buildare il tuo sito quindi tu cosa fai tu semplicemente vai a modificare i file markdown o i tuoi template fai la commit della modifica push su github, github o bitbucket che sono gli hosting per git, per progetti git e automaticamente se colleghi netlify a questo repository e configuri un file di configurazione appunto di netlify ma sono due righe credetemi dove gli dici quale script eseguire per fare la build del sito e qual è la cartella dove ci sarà il sito buildato, Netlify automaticamente si interfaccia a questo repository, rimane in ascolto quindi sa quando tu fai una push e builda il tuo sito e lo rilascia nella sua cdn rendendo quindi il sito facilmente raggiungibile all'indirizzo tuo progetto.netlify.com in realtà è possibile associare dei dns per cui alla fine riuscirai ad avere un sito con nome dominio.it.com quello che è insomma per cui così hai presto fatto il tuo sito in realtà jigsaw non è la soluzione più potente in questi giorni ho avuto modo di vedere gatsby e devo dire che me ne sono innamorato questo perché jigsaw permette il building di uno scritto di un sito da file markdown a meno che tu non scriva dei componenti specifici Gatsby invece ragiona in modo diverso si basa su JS e su javascript e usa React tu non fai altro che costruire delle pagine che non sono altro che componenti react poi ci sono tutta una serie di plugin che permettono a Gatsby di interfacciarsi con una serie di sorgenti che è questo il passaggio interessante di Gatsby.Se jigsaw permette di ricevere in ingresso dei file markdown bene Gatsby ti permette di ricevere dei file markdown, delle API delle pi che implementano graphql e tutta un'altra serie di sorgenti che sono davvero tantissime.Tutte queste sorgenti vanno a confluire dentro il build script di gatsby che runnando quindi eseguendo va a generare tutta una serie di pagine statiche.Sono pagine statiche quindi anche diciamo più simpatiche ai motori di ricerca quindi non devi fare nessun server side rendering cosa che invece dovresti fare facendo un sito con react se vuoi che sia indicizzato nel modo migliore.Bene questa è più o meno come rilascerò il sito quindi userò jigsaw questo perché è molto più semplice, anche se un domani potrei rifare tutto utilizzando Gatsby.Questo perché? Questo perché in realtà non precludo la possibilità di estendere il sito di Gitbar.Qualora volessi estenderlo, beh, potrebbe interessante anche inserire adesso non so quali, ma anche dei contenuti strutturati che possono venire da API o sorgenti più complesse, beh in quel caso adotterei i Gatsby.Mentre però pensavo a una ipotetica adozione di Gatsby, che ripeto non sarà nella fase 0, però intanto mi porto avanti col lavoro e provo a immaginarlo, potrei avere un problema.Oggi a generare i contenuti di Gitbar sono solo io.In realtà per il podcast, per il sito del podcast penso che sarò sempre solo io.Non ci saranno delle esigenze così stringenti, però se volessi proiettare la mia visione in modo più ampio e portare questo approccio anche ad alcuni clienti per esempio l'istituto finanziario che sto seguendo adesso questo periodo, potrebbe essere interessante.Qual è il problema in realtà? La fase di generazione dei contenuti.Io non posso chiedere al mio cliente di scrivere dei file markdown finché le genero io va bene ma se dovessi chiederlo a lui probabilmente avrei dei problemi.Quindi mentre ragionavo su questa cosa sono approdato nel fantastico mondo dei CMS headless chiamati così perché sono dei CMS senza testa quindi sono dei content management system che non hanno però il lato di front end.Qua all'inizio quando vi ho parlato di stack gem, quindi di gem stack, vi ho detto che uno dei vantaggi che aveva è appunto l'essere disaccoppiato infatti il nostro sito è completamente disaccoppiato dal motore di generazione contenuti.Chi ha avuto modo di lottare con wordpress sa quanto può essere interessante riuscire ad avere un CMS quindi un motore di gestione contenuti disacopiato col frontend e sa quanto inferno è gestire questi due elementi insieme in un unico monolita tanto che wordpress stesso wordpress.com quindi il lato commerciale quello che vende in realtà il motore l'applicazione per generare siti java stata sta andando e andata da qualche hanno in quella direzione creando wordpress.com in javascript quindi un front end per la generazione dei contenuti che poi vanno a confluire appunto essere renderizzati sul motore standard di wordpress.Fatta questa parentesi però in realtà io non adoro molto wordpress questo è un piccolo l'inciso che ci tengo a dirlo.Fatto questo apparenza di dico che ci sono una serie di prodotti commerciali molto interessanti che offrono dei pannelli di controllo per la generazione di contenuti uno di questi è Contentful che ti mette a disposizione appunto queste schermate per scrivere in modo semplice i contenuti senza dover creare dei file markdown.Naturalmente io cosa vado a vedere? Vado a cercarmi delle soluzioni open source, free, dove ci posso mettere le mani, giocare, piegarle a mia utilità, insomma a mio piacimento e sono approdato su questa piattaforma che non conoscevo e che si chiama Strapi.Strapi è un'applicazione fatta in JavaScript che non fa altro che generare un CMS headless.Quindi ti permette di creare da una parte la struttura del contenuto.Quindi che ne so, la mia puntata del podcast ha un titolo, un url a un file, una descrizione, un transcript, un'immagine, insomma, costruisco la mia struttura, la salvo, automaticamente ho un sistema pronto per fare il crude, quindi il create, retrieve, update, delete dell'episodio con un'interfaccia abbastanza semplice.La cosa che più mi ha stupito in realtà è che questi dati li vado ad inserire dentro strappi, strappi che tra l'altro può girare con una serie di database da SQLite a MongoDB passando per MySQL e Postgre.Una volta inseriti questi dati vengono esposti da strappi attraverso un API rest oppure attraverso un API GraphQL.Cosa molto interessante, questo perché in realtà dall'altro lato Gatsby, di cui vi ho parlato prima, si può interfacciare in fase di building con quest'API, estrapolare i contenuti, buildare il sito statico e deployarlo su una CDN.E quindi questa soluzione mi ha un po' stupito.Un'altra cosa che mi è piaciuta tantissimo di Strapi è la possibilità di costruire delle strutture di contenuto articolate.Come si fa? Per ogni contenuto si possono costruire dei campi, quindi se il mio contenuto è un oggetto immaginiamole come delle proprietà.E le proprietà sono test, long test, data, le proprietà classiche insomma di un database.Ma la cosa più importante in realtà è che si possono costruire dei componenti, dei componenti che vanno in qualche modo a offrirti, a strutturare delle proprietà complesse.Vi faccio un esempio.Immaginiamo di voler fare il sito degli alberghi della città di Lione.Ok? E' un esempio un po' banale ma per capirci.Bene, la struttura dell'albergo sarà nome, descrizione e poi avrò galleria fotografica.Bene, cosa andrò a fare? Andrò a fare un componente galleria fotografica che permette l'inserimento di una lista di fotografia e descrizione, anzi miniatura, fotografia grande e descrizione.Quindi mi vado a costruire il componente galleria che contiene una lista di componente foto della galleria.Il componente foto della galleria conterrà una foto, la descrizione e la miniatura.Una volta che andrò a creare questa cosa, lato back end, quindi pannello di controllo, cosa vedrò? Vedrò un form con una lista con un tastino più, cliccando su quel tastino più mi aprirà un'interfaccia dove potrò uploadare la mia miniatura, uploadare la mia foto grande e inserire la mia dita a scalia con un + sotto per inserire l'elemento successivo.Questa cosa è fantastica anche perché si può realizzare senza neanche una linea di codice.Un'altra cosa importante di Strapi e che mi ha affascinato credetemi è stata la possibilità di gestire i diritti in modo molto preciso questa cosa mi è piaciuta tantissimo questo perché in realtà Strapi permette anche un sistema di autenticazione che puoi fare insomma con OAuth e quindi le API poi ti rispondono a seconda dell'utente e ti possono rispondere che la lista degli alberghi lo vedono solo gli utenti di questo tipo autenticati e via discorrendo.Quindi in realtà c'è un sacco di funzionalità e soprattutto in una copiata Gatsby/Strapi mi permette di a) disaccopiare il motore di generazione del contenuto dal motore di visualizzazione quindi posso cambiare completamente la visualizzazione, la struttura del sito senza modificare il mio CMS.Posso deployare i contenuti su n siti diversi, ancora più importante.E quindi insomma sono senza dubbio delle tecnologie molto interessanti.Ritornando al piccolo, in questa fase il sito di Gitbar sarà fatto con jigsaw e dei file markdown, però non escludo un domani di implementare sempre sul gemstack questa architettura spero che la puntata vi sia piaciuta lo so è un po' diversa dalle puntate solite ma è una fortuna essere riuscito a registrare credetemi e anche per questa settimana è tutto mi scuso di nuovo per aver saltato l'episodio della settimana scorsa e vi ricordo che se vi fa piacere potete iscrivervi con il vostro client podcast a.gigbar il podcast dei full stack developer in italiano altra cosa importante per qualunque comunicazione segnalazione potete trovarmi su twitter @brainrepo brain come cervello, repo come repository.E nulla, ci sentiamo la prossima settimana.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.web.
