Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Oggi ho un ospite, ma prima di annunciarvi il mio compito, quello un po' palloso, è di ricordarvi i nostri contatti.Info@gitbar.it e @etbrenrepo sono i modi canonici per contattarci.in alternativa c'è il nostro gruppo telegram gruppo telegram che conta ben 811 membri mancate molti ascoltatori non si sono ancora iscritti al gruppo telegram vi stiamo aspettando per iscrivervi basta cercare gitbar podcast nel vostro client telegram preferito e niente seguirci troverete tantissime discussioni non ultima una di bella discussione sulle tastiere meccaniche che è partita oggi.Insomma noi di poche cose parliamo.Tastiere meccaniche e RAL sono sempre presenti nel nostro gruppo Telegram.Detto questo e bando alle ciance è il momento di presentarvi il nostro ospite.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 Ho con me un collega che è un Senior Developer a Nier Form e anche un Node Core Engineer o Ingenier, non l'ho ancora capito, siamo alla puntata quasi 130, 120, non so ancora come pronunciarlo, ma va bene Fa parte del team di DevRel di Nier Form, e qua un po' un orgoglio di maglia, di squadra Ho con me Paolo in sogna.Ciao Paolo, come va? Ciao a tutti, buonasera.Tutto bene, una meraviglia.Vi premetto che se sentite qualcuno in sottofondo è il mio gatto che non è in grado di essere mutato, quindi vi chiedo scusate l'anticipo, non ho modo.Ma non ho semplicemente modo.Ma si chiama Schrodinger per caso? Ma magari, guarda, ma magari.ci dovevo pensare, no non c'è modo, sono dieci anni che mi miacolo in tutte le riunioni quindi non c'ho modo fantastico, sì mi è sembrato di vederti in qualche riunione di lavoro con il gatto che ti passeggia attorno, è fantastico Paolo, la prima domanda che ti voglio fare è tu sei un old core engineer o engineer, metti dove vuoi l'accento io non nascondo il mio accento sardo come ci siamo detti prima che cosa vuol dire, quali sono i compiti e come si diventa? allora, per quanto riguarda i compiti è simile a un...passatemi il termine, qualunque contributo all'open source quindi chiunque può alzarsi la mattina a fare una patch su Node e una PR su Node e vedersi la mergiata in pratica, andare su Master.Chiaramente essere un core engineer ti dà, tra virgolette, dei privilegi in più, ma anche delle responsabilità.In particolare, chiaramente uno può gestire le proprie PR in autonomia, perché di solito si possono auto-mergiare le proprie PR trascorso un determinato numero di te, di ore, dopo la provale e così via, quindi non serve qualcun altro lo facendo invece.Puoi ovviamente gestire la CI di Node, che non è basata esclusivamente su GitHub Actions, ma è testata su una quantità decisamente elevata di combinazioni di sistema operativo, macchine, architetture e così via.E quindi uno può gestirsi l'anatomia invece di aspettare un altro membro dell'organizzazione che ti dica "aspetta, te la faccio girare".Anche perché la CI ci mette diverse ore a finire.per quel discorso delle tante configurazioni presenti.Poi chiaramente è un discorso tra virgolette di fede privilegiata, ovvero se io sono membro, diciamo sono tra virgolette ascoltato di più, nel senso ho una certa reputazione, quindi se dico una cosa la gente tende a fidarsi, non automaticamente, sia chiaro, ci sono discussioni che vanno per le lunghe, anche per diversi mesi, però chiaramente uno dice, ok, questo è membro, quindi per lo meno presuppongo la buona fede, poi c'è la questione tecnica che va diciamo su un altro binario però per lo meno c'è una questione di buona fede, anche perché ricordo, Nod chiaramente è usato in contesti critici un po' ovunque quindi ogni riga di codici che viene approvata deve essere controllata, è chiaro che magari se la fa un membro ci si sta meno, tra virgolette, meno rigorosamente sopravviene una questione un po' più snella e ovviamente come dovere c'è il controllo appunto di mantenere la qualità di node alta di controllare quello che viene mandato su GitHub, di quello che gira sulla CI e di occuparsi del merge delle CI di tutti quanti, coordinare i rilasci e così via a seconda del tipo di engagement che c'è data singolarmente Domanda, ma questa è una curiosità, hai parlato più volte in questi primi minuti di CI, sono curioso, dove gira la CI di Node? Se si può dire.Bella domanda, non ne ho idea.Per me c'è un sito di riferimento, che credo sia pubblico, sul dominio node.js.org, le le macchine sono macchine, attenzione, sono macchine fisiche sponsorizzate da diverse società e mantenute da diverse società tra cui Automarchetta, NearForm, una di queste, che ne sponsorizza diverse perché ricordo, l'hai già detto tu sicuramente in altri episodi, Mauro, ma NearForm è sempre stata molto partecipe nello sviluppo di Node e sin dai tempi di Node 0.12, credo, qualcosa dimostrò solo una decina di anni fa e sono sempre stati sponsor pesanti dell'ecosistema, tra cui anche il commitment nel fornire delle macchine per Node.js gestite da NearForm per la disposizione della CI di Node.Quindi come NearForm, come molte altre società ovviamente.Tra l'altro, da quello che ho visto, nirform ha scommesso su node quando praticamente nessuno stava scommettendo, è stata una bet vincente e non lo dico perché la società dove lavoro ma perché comunque ho visto e ho vissuto questo tipo di investimento in open source da parte di nirform, tra l'altro se non mi sbaglio, questo lo devo dire, quando sono entrato in NearForm funziona che il primo periodo di rodaggio, tra virgolette, lo fai in un team che si occupa esclusivamente di open source e mi pare che tu fosti proprio il mio primo reviewer della mia prima PR in NearForm, che era una PR su Autocannon No, era una PR su Fastify Multipart Uploader.Uno dei due.-Bello, bello.Se te lo ricordi tu mi fido e ti è andata bene, perché sono uno dei reviewer meno pignoli, credo, con cui ho avuto a che fare.C'erano certi decisamente più pignoli di me.Però in generale sì, in realtà è una bella...Il metodo di Nierform ha sempre funzionato.Io sono quattro anni che sto lì e il team di Open Source, cioè il commitment all'Open Source è sempre stato elevato al punto di destinare molte risorse interne di Neo4j all'Open Source, non solo a Node Core, anche tutto lo stack che mi hai appena citato tu, Fastify, Autocannon, adesso Mercurius e tanti altri.Cioè ci investiamo molto semplicemente perché poi, e te lo dico proprio come questione Open Source, alla fine non ci nascondiamo dietro un dito.facciamo profitto dall'open source e è nostra responsabilità morale supportare l'open source in maniera anche economica, nel senso di dire lo stiamo usando, ci guadagniamo sopra, non possiamo semplicemente sfruttarlo come vampiri dobbiamo impegnarci attivamente per la sostegno dell'open source.Si, concordo con te e tra l'altro, ripeto, è una grande nave scuola per portare gli sviluppatori, che per quanto senior siano quando entrano, in un contesto dove la complessità non è quella del crudino della chiesa come direbbe Carmine, cioè dove non c'è sta cover flow che ti spiega come devi fare le cose quando fai certe cose.Io mi era capitato di guardare e fare delle robe per la GraphQL Federation, fare un una roba che doveva praticamente andare a convertire un API GraphQL in API federata, ma dove tu però non avevi l'accesso al server che esponeva la GraphQL e di questo probabilmente ne faremo un episodio.Cioè una roba del genere raga non la trovi su Stack Overflow, ti devi andare a leggere le specifiche di GraphQL magari dal sito della federation, dal sito di Apollo, un bel documento di specifica che ti dice come l'hanno pensato andarti a vedere gli internals di Mercurius se stai usando Mercurius che è il server GraphQL per Fastify Per Fastify o anche può essere utilizzata qualche altra parte, non sono sicuro credo sia generico credo sia generico ma non ci metterei manco io la mano sul fuoco anche perché io lo uso solo su Fastify eh anche io cosa, ma Stepheno non usa altro quindi non per far sponsor a Matteo che non ne ha bisogno però tra parentesi ti è andata bene che beccata a me come first reviewer? Io ho appena entrato in Nearform e sono entrato subito sotto le grinfie del buon Matteo che mi ha fatto una capa tanto sulle promise all'epoca.Bellissimo! Dico agli ascoltatori c'è un vecchio video che è ancora però molto attuale, è di James Nel che non so Mauro se tu hai conosciuto, hai potuto riconoscere.Sì l'ho conosciuto di sfuggita però, ma il video lo ricordo benissimo perché è stato uno dei video più importanti a livello di carriera che abbia mai visto.A beneficio degli ascoltatori si chiama Broken Promises, è un workshop sull'utilizzo delle promises in JavaScript.Per riassumerlo in due parole, se pensate di sapere usare le promises, vi sbagliate malissimo, ma male, male, male.Ci sono cose brutte che si fanno con le promise che non dovrebbero succedere e James, un nostro ex collega, James Nell, abbastanza conosciuto appunto, un altro contributor di Node, le ha analizzate in maniera divina e più imparavi, più ti sentivi con la sindrome dell'impostore, mettiamola così, perché è quello che abbiamo fatto noi negli anni.sono cose brutte mettiamola così.Sì, tra l'altro poi tutto dipende dal fatto che spesso se non si è avuto questo stimolo spesso si ignorano alcuni passaggi dell'event loop di Node.js pensando che sia una roba semplice in realtà anche a seconda del module system che usi cambia tutto quindi lo mettiamo nelle note dell'episodio.Tra l'altro Jason Snell adesso lavora per Cloudflare.Diciamo al momento, secondo il suo stream Twitter, che io sappia, è la mente ditro i workers che sono sono stati rilasciati, hanno portato molte parti della piattaforma web su Node, perché ricordo Node e browser sono due cose distinte in molti casi, quindi attenzione quando lo fate, sono rischiati di farvi molto molto male.Sì, e ve ne rendete conto quando fate girare Jest? Non lo so, non lo posso dire.allora allora mi avete mi avete su una trappola bastard allora non ho nulla contro gesto in particolare ma proprio in un progetto di nier form gest mi ha fatto talmente male che mi stava venendo l'orticaria perché sappiate cari ascoltati che gest fa cose che non dovrebbero essere fatte specialato server mocca tutto quanto speciale promise speciale timer speciale cosa se potete evitate gesti che vi fate un piacere, anche se non sembro.No, no, concordo con te perché mi trovo più o meno nella stessa situazione per quello che era un rant nascosto.Sì, una trappoluna.Andiamo avanti perché potremmo rimanere ore a parlare di JavaScript.Voglio chiederti, tu attualmente fai parte di un team di Dev Relations, no? Del team di Dev Relations di di NearForm.Ma intanto la domanda che spesso sorge e che mi sorgeva anche prima di entrare in questa organizzazione e vivere in questo tipo di cultura, quanto impatto ha dal tuo punto di vista il team di DevRelation nei confronti di mondo open source e anche cattura del cliente perché alla fine l'obiettivo è quello.Cioè tu hai la percezione fattiva che quello che stai facendo sta caturando il cliente pur facendo un'opera di divulgazione, pur facendo rilascio open source? Oppure lo vedi lontano il fine ultimo? Allora, è una domanda piuttosto complessa per diversi motivi.Innanzitutto, a livello formale, il team di DevRel esiste dall'inizio di quest'anno.Però, ti dico, a livello formale, ad esempio io ci sono entrato a inizio aprile full time, mentre prima ci stavo part time perché erano ancora, diciamo, erano ancora dei progetti in sospeso.Ma, in generale, il punto è, a livello formale il team esiste, mettiamo, dall'inizio dell'anno.facciamo dal primo gennaio '22, probabilmente non è completamente preciso, ma poco importa.L'attività di DevRel di NearForm è molto precedente.Se andate sul blog di NearForm anche adesso, ci sono dei miei post strettamente tecnici, quindi non finalizzate al cliente, datati 2018-2019, mi pare...forse ho fatto uno all'anno, più o meno, involontariamente.La questione è, viene chiamato developer relations, perché è quello che facciamo, e il nostro focus è la developer experience, perché non c'è solamente l'open source.Voglio dire, Microsoft ai tempi avrebbe potuto rilasciare, a butto lì, le API di Windows 95 in open source, non c'era problema, tranne che le API erano terrificanti da usare, se qualcuno di voi ha esperienza nell'interfaccia di Windows 95/98, non ricordo neanche se è MFC o simili, no? Il problema è che noi cerchiamo anche di promuovere best practice, standardizzata nel settore, non è che vogliamo essere noi a imporre le nostre al resto del mondo, però cerchiamo di diciamo diffondere quelle che se nella nostra esperienza con tanti clienti, con persone da tutto il mondo, perché ricordo che Nierform è remote only, quindi siamo sparsi in tutto il pianeta.Quindi gente con i più vari background, sia culturali che tecnici, che ha avuto diverse esperienze tecniche, così via.Quello che secondo noi sono le best practice.La butto lì.Noi abbiamo uno stack di riferimento, come tu hai citato prima, Fastify.Il punto non è tanto usare Fastify di per sé.È un bellissimo software.si usa, ci piace, fine, c'è un ottimo grado di soddisfazione per lo sviluppatore.Il punto per noi è, se tu conosci un altro framework che ha il minimo livello di overhead come Fastify, usa quello se sei più contento.La butto lì.C'è gente in NearForm, non faccio il nome, non è per niente fan di TypeScript, però fornisce i tipi di TypeScript nei propri software perché lì va il settore, quindi diciamo ci adeguiamo tra virgolette dove più o meno va il settore.È chiaro che se il settore continuo usare, la butto lì, le promises all'interno degli event handler di Node, dobbiamo essere lì brutali e maternali dicendo questa roba vi tornerà male, aperto e chiuso parentesi, non fatelo, vi tornerà male indietro, quindi non dovete farlo, qui dobbiamo essere categorici, altrimenti cerchiamo di essere il veicolo, data la nostra visibilità di quello che si sta diffondendo, dei trend, un attimo, che si stanno diffondendo.E di sottoporre anche all'attenzione del pubblico i progetti magari più interessanti con cui ci imbattiamo, i software più interessanti che facciamo, anche semplicemente come spunto per crescere la comunità open source in generale.Questo è per quanto riguarda i developer, perché ci possiamo nascondere dietro un dito, ma alla fine la maggior parte di noi developer lo fa sia per guadagnarci soldi, ma sia perché gli piace.Siamo comunque appassionati nel settore.l'astra grande maggioranza.Allora, dobbiamo essere soddisfatti in quello che facciamo.Per come la vedo io, e qui parlo a titolo strettamente personale, ma più o meno l'idea è quella, se il developer è soddisfatto, è più produttivo e torna al cliente.Se il developer può sviluppare velocemente una feature che ci volevano due mesi, magari te la riesci a fare in due settimane, nel caso davvero ideale.Quindi anche in questo torna il cliente.In più, anche banalmente, quando il cliente chiede un aiuto al NearForm senza integrarlo col proprio team di sviluppo, semplicemente dire "questa è la reputazione di NearForm, sono gente che ci crede, si fa anche evangelizzazione".Adesso il termine in italiano suona male, ma in inglese purtroppo così diciamo.E quindi anche il cliente vede il tipo di azienda che siamo, dinamica, attenta all'esterno, attenta all'interno, che cerca di innovare continuamente e così via.Che poi è la natura per cui il team è stato codificato, diciamo sei mesi fa, in maniera formale, ma lo facciamo da quando Nier Form è nata.Chiaro, bellissimo.Tra l'altro, devo dire che il tuo team ha in mano delle cosettine fighe, molto fighe.Non per ultimo, l'ultimo o penultimo progetto sul quale hai lavorato? L'ultimo in cui ho lavorato per cliente Prima di passare full time nel team di DevRel è stato molto interessante per diversi motivi.Allora, ne possiamo parlare.Intanto faccio anticipo.Si parla di IPFS, giusto? Sì, esatto.Interplanetary File System.Solo che io sono un po' una capra.La mia preparazione su ipfs non è così profonda quindi anche per gli ascoltatori che non avessero approfondito l'argomento che cos'è ipfs? Allora, premettiamo che quando ho iniziato a lavorare nel progetto anche io di ipfs sapevo quanto ne so adesso di registrare un podcast cioè niente niente niente nella maniera più assoluta non ne non ne sapevo nulla.Che ti dico, e qui è più, se mi conti della battuta, è più una questione di marketing per eventuali project manager in ascolto.Lì una cosa interessante del progetto è stata anche che per la prima e tuttora ultima volta ho dovuto studiare una quantità di abstract per capire che cavolo fosse IPFS e come funzionasse, mostruosa.Comunque, divagazione a parte.IPFS, che è umilmente chiamato interplanetario di file system, appunto, non è altro che una rete di peer-to-peer completamente decentralizzata.Quindi non c'è nessuna autorità di controllo centrale.Ogni host è responsabile di mantenere i file che ha dichiarato in precedenza, anche se la rete accetta, come diciamo, il contratto di IPFS, che i file effettivamente siano volatili.Piuttosto che fare riferimento al single host, si spera nella replicazione dell'informazione.Quindi si spera, vabbè, l'host che ce l'aveva in cistà, ce l'ha qualcun altro.Ora, la cosa interessante è che in realtà tutti noi, perlomeno noi degli anni '80 e '90, abbiamo familiarità con un componente di IPFS, che adesso vi nominerò e vi sarà...a qualcuno di voi vi farà scattare un flash nel cervello.ovvero ai buoni tempi di Emule, KASA e simili, la rete cademlia, o CAD, per chi ricorda, che all'epoca non sapevo cosa facesse, mi stava profondamente sul cavolo, perché col NAT TFAS dovrebbere una follia farla funzionare, ma lasciamo perdere.La cademlia non è altro che una hash table distribuita a livello globale, che ti consente quindi di partizionare lo spazio di informazioni di una tabella per sapere quale host ha disponibile un determinato contenuto.Tenete conto che a livello di IPFS gli host sono completamente anonimi, cioè un PIRID che grossomodo corrisponde a uno SHA, uno SHA, un MD5, pensatelo un po' come volete, grossomodo è uno completamente anonimo, Addirittura, infatti, c'è sia la richiesta dell'informazione, sia la richiesta del routing per avere l'indirizzo ipfisico di un host, partendo dall'IPID.Quindi è una rete completamente decentralizzata.L'idea di base è che su IPFS si possono caricare dei file che sono scomposti in blocchi, con algoritmi che adesso ovviamente non sono rilevanti.Ognuno degli host si mantiene un blocco dei file originali e quindi ognuno può tramite la DHT di Kademlia riottenere informazioni su chi ha il blocco, riottenerle e quindi ricostruire il file una volta ottenuti tutti i blocchi necessari.Esattamente come succedeva ai tempi di Emule, per dirsela, diciamo, se siamo italiani e la pirateria sappiamo un cos'è.Quindi ricapitolando, i peer hanno questa hash table che dice "ok, questo hash, questo id è relativo a questo contenuto" e puoi andarti a prendere il vero contenuto a quest'ip a questa porta.Esatto.L'idea di base è che se io in precedenza so che c'è un file caricato, Ah, attenzione, dei file non c'è un motore di ricerca.Un'altra cosa importante da dire.Una volta che tu hai codificato il file, secondo un formato che viene utilizzato, che è il formato car file, tu del file ottieni uno SHA del blocco.Ed è l'unico modo per riprendere quel file.Se tu perdi l'informazione dello SHA, non c'è modo di trovarlo.Esistono online dei motori di ricerca.sono servizi addizionali, ma diciamo l'IPFS originale non prevede la ricerca.Dire, guarda, ho il file che ha 'sto nome, dimmi a quale SHA corrisponde per richiederlo nella rete.Questa è una cosa, un'operazione non esiste.L'idea è che tu hai caricato il file nell'IPFS, in seguito lo vuoi recuperare, oppure vuoi dire a qualcuno di recuperarlo, gli passi lo SHA.Devi mantenere tu traccia del file dell'ISHA che hai creato.Una volta che tu hai creato lo SHA, la cosa funziona così.apro il mio client IPFS, si collega a una serie di nodi locali trovati secondo la vicinanza geografica.A quel punto io dico, voglio questo sha-file, lo chiedo a tutti i miei vicini.Se qualcuno sa chi ce l'ha, mi risponde, altrimenti inoltre ai propri vicini, che inoltre nei propri vicini, e così via fino ad esaurire le possibilità della rete.Quindi si cerca di fare una visita in profondità del grafo.Mi ritorno all'informazione indietro, A quel punto faccio una seconda query per sapere quest'host che ha il file, dov'è il suo indirizzo IP, insomma, il modo per raggiungerlo con i protocolli di rete standard, con lo stesso criterio di HT, query indestate e così via.A quel punto mi collego con un terzo protocollo direttamente all'host e gli chiedo il file.Fine.Sì, tra l'altro poi c'è tutto un sistema, no? affinché il file possa essere replicato, quindi quando io scarico il file posso decidere se tenerlo o mi sbaglio, giusto? In modo da rinviare alla rete o meno.C'è il concetto di...perché il discorso...ho messo alcuni dettagli tecnici, ma il punto è che quando io chiedo il file, se un host non ce l'ha magari se lo può cercare per me e magari anche opzionalmente prescaricarlo e quindi in seguito magari se io rifacessi la query, quello stesso host che mi è più vicino ce l'ha.però se fai una cosa del genere devi avere un'operazione di garbage collection altrimenti a un certo punto esplode lo storage se tu fai le query per chiunque però quello che tu descrivi si chiama pinning e dici "questo file io voglio che ci sia per sempre" quindi lo metto a parte rispetto al garbage collection domanda, ma questa è prevalentemente una curiosità Abbiamo detto che quando io salvo il file, quello è...il file è quello è.Ma una delle caratteristiche dei file sui pfs è che sono immutabili.Sì, esatto.E noi viviamo in un mondo che è in qualche modo mutabile.Quindi esiste un modo per, se ci buto un file di testo, avere una versione 2, 3n? il semplice fatto che l'hai modificato.Perché il punto è...Allora, dovete ragionare in questa maniera.Omettendo dei dettagli tecnici che potete andare facilmente a riperire, il punto è che quando viene creato un file, viene calcolato lo SHA del file.Quindi se tu del file cambi il contenuto, cambia lo SHA.E sei costruito a reuploadarlo.Quindi nella rete, formalmente, esistono entrambe le versioni.che non è un problema perché non collidono.L'unico vantaggio nei formati che ci sono è che se il file originale era una directory, perché non si è ristretto solamente ai file, si è ristretto alla...puoi mettere anche directory, intere, se tu cambi un singolo file, l'unico shut che cambia è quello del contenuto del file, specialmente se non cambia il nome al file, Il resto dell'archivio è immutato e quindi non deve essere ri-uploadato completamente.Ok, quindi c'è comunque un modo per indicare i riferimenti tra directory e file.Mi sto prendendo qualche passaggio.C'è un protocollo chiamato UnixFS, che è un formato che grossomodo lo puoi vedere come una rappresentazione di una directory, di un...*sospiro* scusami...di un file tree utilizzando grossomodo JSON più o meno, JSON che poi viene dato in pasto a protocol buff per questa prima nella...le tecnologie usate, quindi è molto efficiente a livello di dati ed è molto human readable, abbastanza facilmente.- Se io domani volessi creare un nodo IPFS quindi compreso un un server, no? IPFS, cioè una macchina che ha la sua bella hash table, la DHT, la distribuite hash table con i suoi ID e il puntatore agli IP e magari volessi condividere dello storage Ah, in quel momento in cui non so come ma lo faccio, io non posso permettere solo a certi host di caricare file o posso? Come posso controllare quello se io tiro su un server per i PFS, quello che mi si carica o meno addosso? Non puoi.Allora, mettiamola così, con la referenza...Allora, facciamo una premessa.Tutti i protocolli di APFS sono pubblici e disponibili su GitHub.Il che significa che se tu di base scarichi il client reference per i PFS che è scritto in Go, quindi è un singolo eseguibile statically linked e così via, Lo fai partire, quindi fai ipfs daemon, e ti parte il daemon che funziona sia da client che da server simultaneamente.A quel punto c'è una CLI collegata che puoi utilizzare per controllare quali file vuoi scaricare in funzione di client.Questo se tu prendessi il client non modificato.È chiaro che se tu ti scarichi il sorgente Go, fai le belle modifiche che ci piacciono tanto fare quando forkiamo una repo, puoi cercare di fare un controllo su cosa ti viene caricato.Però la domanda che ti faccio io è come fai a controllarlo? Perché ti ricordo che tu perdi l'identità dei file.Per intenderci, se tu hai un file da 2 GB, mettiamola così, quel file viene diviso in blocchi da 256 KB.Tu, a seconda di come funziona la rete, perché fondamentalmente i contenuti vengono partizionati sulla rete, potresti riceverne un singolo blocco da 256 KB che è assolutamente inutile, privo di contesto.Quindi come fai a rilevare se qualcosa devi filtrare o meno? Non dico che sia impossibile, ma è una di quelle operazioni che non si fanno perché è nell'atto pratico, è priva di senso, è tecnicamente possibile, però è priva di senso.ma scusa quando io faccio un upload di un file su EFS io mi connetto in qualche modo a un server? no, ti connetto ai nodi vicini ok quindi spedisco dei chunk ai nodi in questo modo la teoria praticamente è questa ogni nodo assume una posizione in uno spazio di indirizzamento quindi diciamo come se fosse un array ordinato, assume una posizione in uno spazio di indirizzamento di 2^256, quindi mostruosamente vasto.Poi facendo dei calcoli matematici classici, con le operazioni di divisione per modulo, eccetera, ogni chunk viene assignato a un particolare indice e viene mandato a tutte le macchine che fanno parte di quell'indice a cui tu puoi avere accesso.Mi spiego meglio.Allora, lo spazio diviso in due è elevato alla 256.Viene fatto il calcolo.In ogni bucket, che si chiamano bucket, c'è un numero determinato di macchine.Tu finisci in un bucket.Crei un blocco.Quel blocco, lo SHA, viene fatto l'operazione in modulo, viene assegnato a uno di questi bucket.A quel punto si verifica tu fisicamente a quali di queste macchine, secondo te, hanno quel bucket di destinazione e ci mandi i chunk.quindi è chiaro che a seconda del chunk un chunk può finire da per esempio nell'indice 1, un altro nell'indice 63 e così via ok quindi praticamente quando tu attivi un server di pfs e tu stai condividendo comunque dello spazio non sai, non gestisci chi interagisce col tuo spazio perché il punto il punto è il diciamo quello se la vogliamo mettere sulla politica è l'effetto collaterale di avere una rete completamente decentralizzata.Ma ci vuole se ragioniamo all'inverso vi ho fatto l'esempio di Emule.Perché Emule ai tempi va ad uscire la rete CAD? Era una cosa buona.Perché non c'erano più server a cui collegarsi e che vanno e venivano mandati giù dalla dall'NPA e robe simili.Perché non c'era modo.infatti dovessero gestire il fatto che invece non mando giù il file server, mando giù direttamente tutto il software, cioè evito che si possa scaricare il software per farlo.Perché? Perché il controllo centrale non ci doveva essere.Quelle sono questioni politiche del progetto IPFS su cui personalmente non entro, no, non per qualcosa, perché non ho gli strumenti per essere esaustivo, però il punto è quello.A livello tecnico voglio farti una domanda, questa è una curiosità, ripeto io non conosco il protocollo fino a ieri quando mi sono visto un paio di video per capire un po' di quello di cui si parlava.Ma per quanto riguarda la resilienza del file, ti faccio un esempio, io uploaddo il mio file, questo file viene diviso in chunk e in termini con dei calcoli matematici e in termini di prossimità viene distribuito a una serie di nodi che sono quelli immaginiamo più vicini nel grafo no? Si, attenzione non confondere, non è vicinanza geografica, è vicinanza nel grafo che non corrisponde alla vicinanza geografica giusto per essere precisi.Sì sì ok Chi e soprattutto come faccio ad avere un minimo di garanzia che il chunk sia resiliente in quel nodo, non sapendo chi è il padrone del nodo, non avendo quel tipo di trust, come faccio ad avere la garanzia che pincopallo spenga il server e io mi perdo un chunk che è di vitale importanza nella composizione del file finale? Allora, questo, premetto che tutto quello che sto per dire non l'ho verificato, perché non aveva a che fare col progetto, quindi non mi sono documentato in merito.Però da come ho capito io, che è quello che mi sono fatto in idea io durante lo svolgimento del progetto, ci sono due metodi.Innanzitutto il pinning, che ti dicevo prima.Dichiari che questo file dovrebbe essere permanente, quindi i nodi si impegnano, se hanno disponibilità, a renderlo permanente, se hanno abbastanza storage.Poi c'è un'altra iniziativa collegata a IPFS chiamata Filecoin, se non ricordo male, ma potrei sbagliarmi sul nome, in cui ci sono dei nodi con altri protocolli esterni di IPFS che si impegnavano a tenere i file per un determinato numero di giorni, ore, c'erano dei contratti automatici in cambio di criptovalute.Questo è un altro processo più o meno automatizzato.Dice guarda io ho 5 giga a disposizione, ti rimetto a disposizione per la bottolina settimana e tu in cambio mi dai, faccio per dire, un millesimo di bitcoin, non sono un'unità di misura adeguata ma diciamo l'idea di base è quella.E' chiaro che se questi filecoin.Il punto è che questi nodi sono nodi ad alta capacità di storage e ad alta capacità di network, quindi non sono il classico cliente che avvieremmo io e te sul nostro portatile.Diciamo vediamo come...tipo i miner praticamente, sono l'idea del miner, però in maniera un po' meno molesta, mettiamola così.E' più utile.Ho capito.Adesso mi ricollego, nel senso che ho visto dei siti che ti permettevano di fare l'upload e ti rendevano disponibile il file su ipfs.In quel caso io non sto usando il client di ipfs, glielo sto dando in pasto sotto forma di, non so, una pagina web con un upload, quel nodo crea il file, ma come fa a dire "storamelo su questo server"? Non può.Non può, il punto è che questi che usano il file coin cercano di essere presenti con tante macchine.Sì ma tu non mi puoi dire mettimela su questa macchina a meno che non vai a scrivere sul DHT questo file, questo chunk ce l'ho io.Quella è la prima e la seconda è poi tu ricordi che ti dicevo che tu vieni affinato a un bucket sul DHT in base al tuo PRAID, d'accordo? Il PRAID è generato dalle tue chiavi di per ogni buget di di criptografia pubblica e privata.È chiaro che le chiavi sono facili da generarsi in generale in pochi secondi, no? Quindi in teoria tu puoi puoi avere duecentocinquantase macchine e se ti giochi bene come vengono generate le chiavi pubbliche e private puoi avere una macchina per ogni bucket.Quindi la probabilità che tu finisca come destinatario delle dei file sono levate chiaro? Cioè diciamo è è tuo voglio avere un un PID il cui modulo secondo lo sciacquo sia uno, rigenero le chiavi fino a che non ottengo quel valore.Ok Aiuto perché questo approccio mi sembra...non credo di averlo capito bene, ti dico la verità Paolo, perché io sono la pincopallo SRL, questo voglio capire, io sono a Pincopallo SRL e offro il nuovo servizio "uploada con me i tuoi file su IPFS" e ti garantisco che sono resilienti.Come faccio a garantirtelo? E quel è il motivo per cui il progetto che abbiamo creato esiste.Ce ne parli? Hai centrato il punto del perché esiste quel progetto, perché se tu ti affidi alla rete IPFS standard, non è facile garantirlo, non puoi dare il 100%, specialmente con un servizio commerciale.Quindi tu devi avere delle macchine che gestisci che sai che fondamentalmente...Il punto è quello, quando tu uploadi tramite IPFS, o meglio, quando tu uploadi con quelli che si chiamano gateway, quello che tu hai citato prima, cioè servizi web che ti fanno uploadare su IPFS e si chiamano gateway, o meglio in gergo sono chiamati gateway, non so per quale motivo.La questione è che tu le uploadi sulle macchine che sono dietro, diciamo, il servizio web e queste macchine sono disponibili come client IPFS, quindi effettivamente tu stai uploadando sulla rete IPFS.Ma il punto di base è che il tuo punto di contatto per uno che utilizza un servizio web che funziona differentemente da IPFS, è che comunque le tue macchine sono sempre lì.Ed è quello il punto.È in quel modo che il gateway ti garantisce che il file sia sempre lì.Altrimenti, se tu utilizzi l'IPFS standard del client Go, l'unico modo per garantire che il file sia lì è sperare l'elevata replicabilità del file, ovvero che il file sia desiderato da molta gente, sia preso da molta gente, quindi automaticamente replicato all'infinito.Di nuovo per tornare all'esempio di Emilio, c'erano film che non vedeva nessuno e che sui milioni erano introvabili.Quelli sputtanati, butto lì Fast & Furious per citare qualcosa dell'epoca, lo trovavi in dieci secondi.Perché? Perché ce l'avevano tutti.Sì, ma dovendo raccontare un po' il progetto nel quale hai lavorato, che cos'era e come funzionava? Era proprio uno di questi gateway.Allora, è uno di questi gateway che ti consentono di fare l'upload dei file via web per IPFS E il problema di questo gateway era che, se posso, il miglior problema che una società si possa trovare ad affrontare, ovvero andava talmente bene che non riusciva più a gestire il carico.Cioè, la ricezione da parte del pubblico era stata ben oltre le aspettative di dimensionamento del sistema, essere arrivati a un punto in cui il sistema non riusciva più a gestire la crescita, non riusciva più a gestire la richiesta degli utenti, e non riusciva più a rendere disponibili file.Per il seguente motivo, una cosa che ti ho omesso prima quando ti illustravo l'IPFS è che quando tu fai partire il nodo, diciamo, tu fai partire un nuovo nodo, prima che tu diventi realmente effettivo nella rete del DHT, ci possono volere dei tempi molto elevati, che si può andare dalle poche ore a 48 ore reali.Intanto ci puoi mettere due giorni prima di essere effettivo sulla rete.Adesso tu immagini bene che se tu stai su un sistema che gestisce milioni di upload al giorno, in continuo momento, e ogni volta che aggiunge una macchina, questa macchina viene vista due giorni dopo sulla rete, è inutile, non riesce a gestire comunque il carico.quindi il cliente si è rivolto a Niaform dicendo "Ma riusciamo a fare un pruvo concept di un'architettura che possa scalare all'infinito e abbia le stesse feature?" e questo è il progetto in...Paolo scusa ti faccio una domanda sì ti faccio una domanda perché ci mette fino a due giorni? Perché devi scoprire i vari nodi, i nodi si disconnettono e disconnettono di continuo e prima che tu abbia una copertura efficace su DHT, e qui fidatevi di me perché non ho capito niente, manco io, cioè io so che per stare efficace su DHT ci vuole molto tempo per motivi tecnici che negli abstract ad un certo punto mi sono perso, erano troppi dettagli, però il punto è che quello che ho capito così a spanne è che per avere una copertura completa in tutti i bucket, tutte le connessioni, la rete di gossip sub e così via, ci vuole molto tempo.Nei casi peggiori, due giorni.però è un valore medio.Diciamo è un valore medio.Ok, chiaro.Però il punto allora il punto mettiamola così per semplificare la questione.Ci vuole del tempo, tanto anche se fosse un'ora.Se tu hai un burst improvviso nella rete non ti puoi permettere di rendere disponibile una macchina dopo un'ora.Hai perso il burst, la gente ha avuto ha ricevuto dei belli dei cinque zero tre o simili e se n'è beatamente andata.verissimo, verissimo.chiaro scusami.No, figurati.E dove ero? E dicevo come funziona, eri arrivato all'architettura che avete messo in piedi, come funziona? Come fa a scalare così rapidamente? Qual è il segreto? Allora il segreto è che il segreto è solo che si riassume in una singola parola che sembrerà strana adesso che ho visto tutta la premessa che ho fatto, ma è quello il semplicemente che l'architettura è completamente stateless.Ovvero, il punto è che noi, come NearForm, abbiamo analizzato tutti i vari punti dello stack che vi ho descritto, quindi l'IPFS, il DHT cademlia, il protocollo bitswap, che non vi ho ancora nominato, ma in pratica è quello che quando ti connetti all'host per chiedere il file, all'host di destinazione finale, si utilizza un protocollo chiamato bitswap.Noi abbiamo analizzato a fondo il protocollo BitSwap, il DHT, il formato di archiviazione dei file e così via, e ne abbiamo tirato fuori un'architettura basata, nel nostro caso, su componenti AWS, ma poi farò un piccolo commento in seguito, basato su componenti AWS piuttosto di base, per intenderci, Dynamo S3, SQS e basta, in realtà sono questi tre.E Lambda, se non ci mancava Lambda.Ogni componente di questo stack è stateless, quindi in grado di essere autonomo, è idempotente ed è full tolerance, quindi può essere riavviato in qualunque momento e in qualunque numero.Con questo criterio di dimensionamento della rete, essendo stateless possiamo aggiungere nodi all'infinito fino a quando AWS non ci dice "ragazzi cari, state facendo partire troppe lambda" noi continuiamo a far partire lambda le code vengono esaurite, i file vengono serviti e così via in realtà la cosa figa di lambda nonostante il costo Io immagino sia costoso quando ci sono dei picchi, però è che veramente può scalare quasi a infinito o comunque secondo il dimensionamento di AWS che sicuramente è uno dei più grandi al mondo.In realtà una cosa che magari gli ascoltatori saranno molto interessati a sapere Lambda ha una fregatura nascosta.E mi spiego meglio.Il tipo di operazione che noi facciamo, anche se noi lavoriamo su file di terabyte, potenzialmente potrebbero essere terabyte, siccome utilizziamo gli stream di Node.js, non carichiamo mai il file in memoria, quindi a livello di footprint sulla RAM sono un centinaio di mega.Ora uno sarebbe portato a pensare, "Vabbè, utilizzo la Lambda base a 128 megabyte".E fine.Ecco, questa potrebbe essere la peggiore idea che uno può avere, perché in Lambda tutte le prestazioni sono una funzione della RAM, il che significa che se tu, anche se utilizzi 100 MB di RAM, metti la Lambda da 128, la rete è lentissima, quindi il tempo di processamento è estremamente elevato, quindi noi siamo stati costretti a mettere anche solo con l'utilizzo massimo di 100 megabyte le lambda da un giga che ovviamente impatta i costi Chiaro io Visto che l'hai l'hai introdotto ci tengo a Pinare un un episodio che abbiamo fatto qualche tempo fa con Alex Casalboni di AWS dove si spiega proprio questo fattore.Alex ha realizzato anche un tool che permette di dimensionare le lambda e vedere in funzione appunto del dimensionamento gli impatti sulla cpu, sul tempo di elaborazione e quindi se andate a scorrere lo storico lo trovate nell'episodio 62.E' molto interessante questa cosa.E a livello di progetto quindi, oltre a questo, qual è stata la parte più challenging? Il DHT, proprio il DHT.Perché la parte di indexing...allora diciamo che il progetto era diviso in tre parti, l'indexing, il publishing, quindi il DHT, e quello che abbiamo chiamato Peer Subsystem, ovvero quello che serve file tramite Bswap.Dall'esterno la potete vedere banalmente come un file server, l'ultima parte.Allora, la prima parte è intuitiva.Si prende un file, lo si analizza, si salva con i dati su Dynamo per poter in seguito riservire i contenuti.La parte di Peer Subsystem è abbastanza triviale.Accede alle tabelle di cui vi ho appena parlato, vede se il file c'è e se c'è lo serve al client.Fine.Fino a qua ci siamo, giusto? Ora, il problema è la parte di publishing, perché in teoria, come vi accennavo prima, quando io ho un file disponibile, devo far sapere alla rete che ce l'ho io, altrimenti lascia il tempo che trovo ad avere il file giusto, perché nessuno sa che ce l'ho io, non è disponibile.Ora, il problema è questo.Quello che non vi ho detto sono i numeri di upload, della piattaforma, noi raggiungiamo i diversi milioni di upload al giorno di singoli file.Ora, ogni car file, cioè il content archive file, il formato che viene utilizzato, vedetelo più o meno come una serie di blocchi concatenati con poche informazioni di indexing, ogni car file contiene migliaia, se non di più, in casi peggiori, blocchi internamente.Vi fate facilmente un'operazione mentale, si va che noi dobbiamo pubblicare la disponibilità di diversi miliardi di blocchi al giorno.E questo era il punto.Questa era una delle più grandi challenge del progetto.Cioè, quando siamo arrivati qui, sono stati dolori.Sono stati davvero dolori.Quindi la challenge è stata risolvere questo problema.soprattutto nel discorso che l'ambda in questo caso ci avrebbe dato la zappa sui piedi perché non potevamo nella rete connetterci utilizzando un singolo peer ID da sorgenti diverse c'era il rischio di andare ad impattare lo stesso host di destinazione le connessioni diverse sarebbero state unificate e l'ambda sarebbe impazzito praticamente non si arriva a vedere il a livello di di rete non si io qua mi sono mi sono perso eh perché allora il punto è questo immagina questo tu in decision file lo devi pubblicare pubblicare significa guardate ce lo sulla rete di HT dici guardate questo file adesso ce l'ho io quindi se qualcuno ve lo chiede mandatelo da me fino a qua ci siamo ok giusto ora come ti ho detto è è stateless il punto quindi l'idea faccio parte una lambda collegata come evento di SQS ogni volta che un blocco viene indicizzato parte la lambda e lo pubblica questa è l'idea di base.Lo pubblica vuol dire, lo va a scrivere sul DHT giusto? Sì, ma scriverlo sul DHT Il punto è che scrivere sul DHT significa collegarsi a uno vicino e dirgli guardacelo io Perché ricordati, non c'è un'autorità centrale.Quindi il punto è sempre, devo collegarmi a qualcuno, vedi, li guarda ce lo io se qualcuno te lo chiede.Ci siamo fino a qui? Sì, sì.Sì.Ok.Il punto è questo.Come ti dicevo in precedenza, tutto su IPFS si basa sul concetto di Pirah ID.Allora, la questione è, quando tu pubblichi sul DHT, fondamentalmente l'informazione che viene salvata è semplicemente una coppia PIR ID, BLOCK IT.Punto.Tutto qua.Ora, quello che succede è che quando tu apri una connessione con un host nella rete di IPFS che per chi è interessato a tecnica di vita sarebbe LIB P2P apri una connessione annunciando il tuo PIR ID come prima cosa che è quello che nel TCP viene fatto quando tu apri una socket cell, indirizzo IP sorgente, in pratica, no? Allora il punto è questo.Se mi arrivano più blocchi, faccio partire più lambda di pubblicazione, c'era un elevato rischio che queste lambda si collegassero, più di una lambda si collegasse allo stesso host, l'host ricevesse da connessioni diverse lo stesso peer ID e cercasse di unificare le connessioni.E diceva "Oh, guarda, è lo stesso che ha perso una connessione e ne ha aperta un'altra".Questa sarebbe l'idea di base.Per l'host che non sa che stiamo parlando di lambda, la l'altra è una Lambda cerca di unificarle e a livello di routing di rete impazzisce tutto non non funziona la comunicazione perché una Lambda viene servita all'altra no chiarissimo sì sì eh quello è è quello ti puoi immaginare che incubo è stato risolvere quella cosa perché non c'era una soluzione perché il punto di base noi stavamo centralizzando un' architettura decentralizzata e quindi era un incubo operazione di destinazione la con l'aiuto del cliente che ci ha fornito un sistema intermedio di pubblicazione che delegava, che faceva quello che in gergo viene chiamato "delegated content routing", quindi noi dovevamo solamente pubblicare a quel sistema.Qui un'altra cosa interessante che mi piace...Che lui faceva pezzettino per pezzettino faceva la pubblicazione, no? Esatto.La cosa però simpatica...Mi immagino come andare a scrivere su una coda con un worker che poi uno per uno va a pubblicare.Ci sei vicino, ci sei vicino perché in realtà non era una coda ma era una blockchain di aggiornamenti.Ovvero si pubblicava la blockchain di aggiornamenti, "Guarda c'ho un nuovo aggiornamento, guarda c'ho un nuovo aggiornamento", prima o poi il server di destinazione se lo sarebbe andato a scaricare tutti di seguito.La cosa divertente è che in questo caso abbiamo utilizzato un'operazione bizzarra, per il MapReduce che tutti conosciamo, per fare in modo che la cosa funzionasse.Perché anche qui la concorrenza che il Lambda ci garantisce ci è tornata indietro, nel senso ci addiava problemi.Perché puoi ben immaginare che se io sto pubblicando un nuovo aggiornamento e devo aggiornare la testa della coda, il link, diciamo, alla testa della coda, se due Lambda lo fanno simultaneamente, una delle due esclude l'altra.C'è una risk condition.Quindi anche lì abbiamo utilizzato un sistema di MapReduce che in pratica, per arrivare alla fine della storia, siamo partiti da un miliardo di blocchi da pubblicare al giorno, diciamo nell'ordine del miliardo, noi lo riusciamo a fare con 100.000 invocazioni.Perché raggruppiamo e poi c'è una lambda finale la cui concorrenza è fissata a uno e fa un solo aggiornamento al secondo della head e riusciamo tutto sommato a tenere il traffico.ci sono problemi di crescita.Questa è la cosa più figa del progetto, se posso.Non è...lo dico per gli ascoltatori, se vi siete persi alcune parti, non è facile provare a immaginare, a visualizzare quello che Paolo sta dicendo.Però, grosso modo, se ci sono riuscito io ad avere un'immagine, penso sia possibile.Anche perché, diciamocelo, sono delle delle challenge che non affrontiamo tutti i giorni, questo tipo di sfide.In quattro anni questo allunga il progetto più complesso che ho mai affrontato, ma a dire allunga.Aggiungo anche che io vi ho condensato in mezz'ora quello che sono stati quattro mesi di lavoro, ma non per per vantarmi, ma per dire certo, vi sto facendo una zippatura mostruosa di quattro però se non ci sono i primi quattro mesi di eh di switch mentali, follie varie, grafici e robe varie è chiaro che sarete riuscirete in perdonatevi il termine imbambaliti completamente da stasera perché non è ehm io vi dico come dicevo prima ci ho messo due settimane solo a leggere gli abstract per capire come funzionasse IPFS travite gli abstract poi ho dovuto sperimentare poi fai la prima piossier poi ti rendi delle magagne nascoste nei protocolli perché tu cerchi di centralizzarlo e così via dopo quattro mesi si è arrivato al progetto finale che è tuttora in produzione e sta macinando una barca di dati chiaro chiarissimo prima hai fatto un cenno quando hai detto che gira su AWS ma c'era una postilla sul fatto di altri cloud mi è sembrato di capire giusto? Esatto.Allora, la postilla è questa.In breve, come vi ho detto inizialmente, IPFS per questioni etico-politiche è un progetto che è democratico, è inclusivo, nel senso che l'idea è che chiunque può in qualunque istante far partire un nodo IPFS.La cosa si è tradotta anche nella creazione di questo progetto.Il problema è che questo requisito ovviamente come tutti si aspettano mica ti viene detto all'inizio ti viene detto a metà progetto tu immagina che dopo due mesi stai impelagato fino alle alla vita nell'acqua di AWS e ti dicono oh guarda questo in teoria dovrebbe funzionare su tutti i cloud perché non possiamo fare il lock in su AWS non per noi ma se qualcuno un giorno lo vuole far partire deve poterlo fare la cosa in che cosa si è tradotta che in pratica noi nell'immediato non è cambiato nulla perché non è che abbiamo abbiamo improvvisamente cambiato storage, stiamo comunque su S3, stiamo su Dynamo e così via.Però nel creare il sistema, siamo dovuti essere attenti a non andarci a chiudere su componenti specifiche di AWS, ma su componenti virtualmente appartenenti a qualunque cloud o in generale anche addirittura su sistemi on-premises.In particolare, io vi ho citato Dynamo S3, SQS e Lambda, ma qualunque di questi, anche in maniera ibrida, se vi volete proprio fare del male o fare del male ai vostri DevOps, può essere sostituita con, non so, Google Cloud, con Azure, perché ci sono le piattaforme di serverless, ci sono database distribuiti e ci sono sistemi di coda.Lo puoi fare on-premise se ci metti un Kubernetes, ci metti Redis, magari anche a fare la coda, fare sia lo storage che la coda, e così via.S3 lo puoi sostituire se ti vuoi fare veramente male con l'FTP, e così via.Quindi i componenti sono interscambiabili.Il loro ruolo non lo è e devono avere alcune caratteristiche di base, ad esempio il sistema di code deve avere il controllo della concorrenza, altrimenti il publishing non funziona.Però in generale ci puoi mettere qualunque cosa, RabbitMQ, voglio dire, ci può andare benissimo.La cosa è stata interessante perché c'ha un requisito non tecnico non è stato tradotto per nessun modo tecnico si è tradotto a livello profondo per molti via ehm politico etici e per carità condivido anche non metto in dubbio eh su l'impostazione del progetto dal punto di vista tecnico quindi anche eh vabbè mi sto vantando, mi voglio vantare del fatto che ce la siamo gestita anche su su requisiti non funzionali arrivati tra capo e collo un altro modo per dirlo, ma un po' di vantare mi è consentito, se posso.Mi spiego, al momento, che io sappia, l'architettura non è stata pubblicata, quei documenti di cui ti ho parlato, però sono presenti.Quando verranno pubblicati, ci saranno a disposizione di chiunque dei grafici di flusso, fondamentalmente, che mostrano come sono interconnessi i vari componenti e quali sono i vincoli dei vari componenti.Di quello, diciamo, non me ne sono occupato della presentazione formale, quindi non so quali metodologie utilizzeranno, però quei componenti sono disponibili.Chiunque ci va a dare un'occhiata e dice "guarda, qua c'erano messo lambda, io sto Google Cloud, devo sostituire lambda con l'equivalente in Google Cloud".Diciamo, è più una questione funzionale.Il punto è che ci sono dei grafici che verranno diffusi, che mostrano l'architettura a livello alto, perché l'architettura a livello alto, Abbiamo fatto un'implementazione di reference, per certi versi, anche se questa è in produzione, che può essere sostituita.In ogni caso, le repo su GitHub sono pubbliche.Chiunque se la può andare a prendere.Nel momento in cui ho scritto le repo, ho cercato di isolare i layer a basso livello, in modo tale che uno semplicemente piglia un file e lo sostituisce con...Che ti devo dire? Toglie l'SDK di S3 e ci metti l'SDK di Google Cloud, la cosa funziona perfettamente, con le dovute minime magagne di adattabilità sì, di adattamenti, però è poca roba, mettiamola così chiaro, chiarissimo e stack tecnologico utilizzato per questo progetto? è quello che ti ho detto prima EWS come, diciamo, piattaforma di riferimento - C'è CDK o Terraform? - No, Terraform, i devops stanno su Terraform.Node.js versione 16 con un runtime customizzato su lambda, visto che all'epoca non c'era ancora Node 16.Dipendenze ridotte al minimo.e se posso non voglio buttare Diciamo non voglio criticare il discorso di la stichetta di sdws ma siamo riusciti a farlo senza le stiche di Ews sui componenti sul coso la maggior parte dei componenti Anche perché facendo così siamo riusciti a ottenere a incrementare anche le prestazioni bizzarramente ci parli di questa cosa perché me ne parlavi prima in privato e mi dicevi che è stato un po un game changer abbandonare gli SDK.Sì, allora la storia è questa.Allora noi inizialmente quando abbiamo scritto questo e l'abbiamo verificato sul client BitSwap che è quello che serve ai file allora abbiamo detto "ok, vediamo che succede, vediamo dove stiamo con le prestazioni rispetto alla reference Go".Allora, alla reference Go T-SERVS abbiamo creato un benchmark con una serie di file e il benchmark, diciamo, il client Go su una macchina X5 Large su EC2 serviva questo set di prova dei file in tre secondi.Questo era il nostro tempo.Ora, la questione è questa.Noi sapevamo benissimo che la reference Go legge i file in locale.Quindi dici, vabbè, non saremo mai veloci come Go, perché semplicemente noi leggiamo i file via rete, quindi c'è la latenza di rete che va considerata.Il punto è, vediamo se riusciamo a avvicinarci a quel tempo, vediamo se riusciamo a stare...avevamo posto una deadline iniziale del 100% in più di Go, quindi stare entro i sei secondi, circa, per avere una reference così, diciamo, un benchmark di riferimento.Andiamo a far girare la prima implementazione del codice che utilizzava l'SDK di AWS.Stavamo a 13 secondi, quindi decisamente lenti.Ora, il punto non è tanto il benchmark di per sé, ma siccome il punto...Dobbiamo cercare di essere più veloci possibile per non dover far scalare all'infinito lambda, per una questione di costi.Dobbiamo lavorarci.Cerchiamo di migliorare le prestazioni.Abbiamo inizialmente, essendo Node.js, e si è detto, se c'è l'IO che fa la tensa, aumentiamo la concorrenza delle operazioni per cercare di comprimere le operazioni.Utilizzando il pacchetto NPM chiamato Pmap, per chi non lo sapesse, in pratica fa una...consente di far partire una serie di promise in parallelo, limitandone la concorrenza.Quindi abbiamo un controllo della concorrenza.In pratica un promise.all con concorrenza massima, per metterla, diciamo, ai minimi termini.Nonostante questo, le prestazioni non sono migliorate.Sono da 13 secondi, siamo scesi a 11, ma andiamo ancora ben lontani.Anche ci siamo chiesti come possiamo migliorare la cosa.Utilizziamo un agent HTTP sul node per risparmiare sull'apertura delle connessioni, visto che i nostri host di destinazione sono sempre gli stessi, ovvero i server di S3 e di Dynamo.Nonostante questo, stavamo ancora a 8-9 secondi, se non ricordo male.Alché ci è venuta in mente una cosa.L'HTTP, come tutti ben sapete, supporta il pipelining, quindi tu puoi far partire una barca di richieste ed è il canale poi a risponderti in ordine e secondo la velocità.però, diciamo, massimizzi l'utilizzazione del canale TCP.Ci siamo poi anche resi conto che, nonostante l'SDK, le AWS, che sia S3 o che sia Dynamo, funziona tramite REST API, sono comunque delle REST API.Anche l'SDK utilizza le REST API.Allora abbiamo detto, togliamo di mezzo l'SDK, scriviamo a mano, visto che tanto sono operazioni ridolle, quindi sono GET, sono molto semplici.Scriviamo a mano noi le richieste di GET in HTTP.Utilizziamo il client HTTP 11, che è una riscrittura del client HTTP di Node.js, che è molto veloce.Massimizziamo l'agent, massimizziamo l'HTTP pipelining e vediamo che succede.Cos'è successo? Il BitSwap Peer subsystem rispondeva ai messaggi in 2,5 secondi, ovvero con questo crocchetto del pipelining siamo riusciti ad essere più veloci del client go nonostante noi leggiamo le richieste da remoto mentre il client go le legge in locale.Figo, quindi questo dimostra che spesso...sai cosa emerge da questa storia? Che è una cosa che ho imparato a fare non tanto tempo fa e che spesso utilizziamo delle librerie o dei tool senza provare a capire cosa facciano sotto il cofano no? E poi però arriva un momento dove è necessario capirlo perché è necessario conoscere ciò che stai facendo girare perché spesso dei limiti che noi andiamo a cercare nel nostro codice talvolta possono venire anche dalle librerie di terze parti per cui quando, questa è una linea guida che mi son dato, quando comunque includo una libreria di terze parti un occhio al sorgente ce lo butto sempre magari ne capisco l'1% il 2% però uno sguardo può essere può essere importante A) per sviluppare quella curiosità, b) per sapere dove mettere mano quando abbiamo questo tipo di problemi nel senso almeno da dove partire per andare a esplorare e c) anche per capire come utilizzarla al meglio.Certe volte a me è capitato ci sono dei parametri che non sono pubblici.Spesso con alcune librerie magari tipizzate male o dove se ci passi sopra non è chiarissimo che tipo di parametri prende e per che cosa li prenda che basta buttarci un occhio e capisci che magari metà delle funzioni e degli arzigogolamenti che stai facendo nel tuo codice te li fa la libreria in modo molto più pulito bastava passargli quel parametro Ah guarda, è scoperchiato il vaso di Pandora un progetto precedente a Niofom era proprio quello andare a vedere che facevano i librerii di un progetto che aveva le brillanti prestazioni di gestire tre richieste al secondo massimo, una cosa del genere.Una cosa brutta, brutta, brutta.Se posso fare una mezza marchetta, quando vi capitate in questa situazione, NearForm ha rilasciato sotto licenza OpenSource Clinic.js.Clinic.js.Uno dei tool si chiama Clinic Flame.che, data una determinata operazione, ti fa vedere dove spende più tempo il processore, se si parla solamente di CPU time.Ti posso garantire che per la mia esperienza l'80% delle volte sono dipendenze brutte brutte brutte, ma veramente brutte, se posso citarne una ma senza voler essere cattivo, è solo che è l'esperienza.le WSSDK versione 2, quando quello che c'è adesso era 2, era una monstrosità, faceva cose che non dovrebbero essere fatte e si toglieva di mezzo un'altra, ah, un'altra, parlando di Promesis scusate, se qualcuno di voi ancora utilizza Bluebird, vi vengo a cercare, levate di mezzo Bluebird Bluebird è un overhead che voi non avete idea, levatelo di mezzo, a parte non c'è più motivo di averlo ma levatelo di mezzo perché non avete idea di quello che ti fa.Quello è un altro.Sì, non sei la prima persona che me lo dice.In realtà io credo di non usarlo ormai da anni.Non c'è più motivo.Da che c'è stata Sinka Wait, Bluebird ha perso di senso.Aveva senso ai tempi di Node 4 e 6 forse, ma già da 8 in poi non ha senso, siamo ben oltre il legacy adesso.Purtroppo ci sono progetti legacy che ce l'hanno ancora e non hanno idea che le prestazioni li derivano da una semplice libreria di promise, che tolta ti fa guadagnare una barca di tempo.Comunque hai parlato Paolo di flame graphs, no? In modo tangente.Che anche quelli nella mia carriera professionale sono stati dei game changer.Nel senso che io per esempio lavorando non più tardi, guarda, non più tardi, questo pomeriggio io stavo facendo un lavoro utilizzando Framer Motion che è una libreria per react per fare animazioni e interazioni Ci avevo dei frame drop Ho guardato il flame graph e ho capito perfettamente direttamente dal browser dove dovevo intervenire per risolvere il problema adesso Leggere un flame graph a prima chitono non è una cosa semplice, in realtà perché può spaventare magari il flame ha una profondità molto ampia e quindi ti ci perdi, però dopo che l'hai fatto una volta...cioè...bomb! Tanta roba e riesci a capire cosa sta realmente succedendo.Flame FlameGraph e Debugger per me sono stati il salto quantico a livello di produttività quando ci sono dei bug.Io ho smesso di utilizzare console.log a destra e a manca, se mi manca il debugger sono morto.Eh ma è così, è così.Io tramite il FlameGraph ho scoperto che in JavaScript il ciclo for_of, cioè for const e of array per intenderci, è mostruosamente più lento del vecchio ciclo for allo stile C++.Quindi for int=0, C++ e così via, è molto più veloce anche in JavaScript.Cosa che nessuno sa, ma a maggior parte delle volte non te ne frega.però se tu vai a vedere il flame graph e vedi che quel for è quello che viene chiamato un hot path, cioè un path continuo, allora li ti rendi conto che sei costretto ad ottimizzarlo e scriverlo alla C++.Sì, perché poi talvolta il lavoro appunto di andare a far marciare un'applicazione che ti risponde tre richieste al secondo, questo deve essere, cioè una lettura attenta di quello che succede.Poi, ritorniamo al crudino della chiesa, se stai facendo il crudino della chiesa te ne freghi anche, però quando le applicazioni scalano e devi concentrarti su queste cose, come il progetto che avete fatto sui PFS, no? Cioè nel senso, poteva funzionare com'era, però poi il progetto scala, si uploadano milioni di file, si trasferiscono milioni di file, la roba deve funzionare anche quanto tanta gente.Ma è così infatti su quel progetto di quel cliente potete credermi o meno ma levando Bluebird e ottimizzando questo tipo di cicliforo quindi senza andare a toccare i dati altre cose non vi immaginate chissà che abbiamo fatto di ottimizzazione solo facendo questo che però ci è costato 6-7 mesi di lavoro per trovare tutti i punti in cui andava a rompere le scatole eccetera abbiamo dimensato i tempi di boot e le richieste sono passate da 3 a se non ricordo male 60 solo facendo questo, togliendo questo codice brutto brutto brutto ignorando dei dati, i server, quel che ti pare.Sì sì sì, chiarissimo.Paolo, stavo guardando l'orario, stiamo come sempre andando lunghi, quindi il mio compito in questo momento è quello di avviarci alla chiusura.Ti chiedo come il nostro solito se ti viene in mente qualcosa da condividere con noi che sia un libro, un talk, uno script, qualunque cosa che pensi valga la pena essere condiviso con la nostra community.Riconducono il paese dei balocchi! Ah, il paese dei balocchi! No, ma uno ve l'ho detto in precedenza, il po' di genzinella, andatevelo a guardare.E' tragicomico, mettiamola così.Perché lui la ve la dà in modo leggero, però, mettiamola così, almeno vi riconoscerete in almeno un paio di situazioni, altrimenti c'è qualcosa che non va.e se non vi riconoscete nessuna delle situazioni siete pregati di mandare il curriculum a niar form che siamo interessati così se si usate già le promesse in maniera perfetta e cristallina eccetera quindi fatevi sentire nel caso aggiungo anche un altro sito per essere invece più sul leggero non so chi lo conosce è vecchio vecchio vecchio lo leggevo già vent'anni fa all'università già lo leggevo perché esisteva storia della sala macchine si chiama, di Davide Bianchi, un nostro connazionale che è in Olanda, da sempre suppongo, da almeno 20-30 anni che sta lì, è un programmatore sistemista della precedente generazione rispetto alla mia, quindi ha buoni buoni quarant'anni di carriera adesso e ha pubblicato una infinità di storie della sala macchina, ovvero di situazioni tragicomiche con gente più o meno informatizzata.Dimmi tu Mauro, il sito lo dico a voce oppure lo metterai un link da qualche parte come vuoi che faccia? Lo mettiamo comunque nelle note dell'episodio quindi magari me lo mandi in chat e io lo condivido.Per chi è interessato a voi c'è soft.tinoland.org, semplice, piuttosto semplice.Ci sono dentro ed è storico, sì, me lo ricordo anch'io dal periodo dell'università.Vedo che, appunto, è operativo da prima del 2003.Mottoroso, ci sarà qualche ascoltatore, non era manco un ato il che mi fa piangere, ma lasciamo perdere, siamo di un'altra generazione.ma vabbè parte quello facciamo finta che esiste già da 2003 e non eravate manco nati quando è nato sto sito però c'è roba gustosa mettiamola così.Molto gustosa sì e soprattutto divertente.Anche io ho un balocco questo balocco viene direttamente da un altro balocco nel senso che qualche tempo fa quando c'è stato da noi Matteo Collina va parlato della sua newsletter.Questa settimana Matteo nella sua newsletter ha condiviso tra i vari articoli interessanti che condivide tipo l'architettura micro servizi, il viaggio verso l'architettura micro servizi di airbnb oppure come stripe ha migrato a typescript c'è un articolo che non emerge tantissimo ma è super super super interessante il titolo è "Building datacentric apps with a reactive relational database" cioè è l'idea di switchare paradigma utilizzando un concetto che è quello della reattività e qua mi collego se vi siete persi il mio talk per Code Emotion, peggio per voi perché nel talk che ho fatto a Code Emotion dove parlavo di Supabase ma tranquilli c'è anche una puntata se volete recuperarla, si è spiegato esattamente come si può realizzare la parte reattiva del database utilizzando delle funzioni native di Postgre che sono una figata colossale, tanti cuori bellissimi per Postgre, eviva i monolithi, no comunque tanti cuori per Postgre e quest'articolo entra nel dettaglio e spiega appunto che pattern utilizzare per provare a immaginare un nuovo modo di fare delle applicazioni.In fondo le nostre applicazioni non sono più delle semplici pagine che ci vengono risposte da una richiesta HTTP ma magari sono delle interfacce React che devono reagire a seconda di cose che succedono e ci mettiamo sotto i WebSocket che risvegliano robe e fanno robe.Beh c'è un approccio più metodico nello svilupparlo è una roba che mi ha interessato tantissimo penso di realizzare anche un piccolo un piccolo POC giusto per provare io vi metto il link nelle note dell'episodio perché secondo me ne vale la pena [Musica] Paolo io ho trattenuto tantissimo comunque è stato fighissimo vedere che in realtà anche attorno a questi progetti che sono innovativi e disruptive.Alla fine nascono delle esigenze, quelle di scalare, di dare dei prodotti commerciali, per cui bisogna un po' aggirare dei grossi ostacoli o trovare delle soluzioni.Dei grossi ostacoli quando si innova e alla fine si scala.Stai affrontando dei protocolli nuovi/vecchi, comunque non standard per alcune cose e quindi devi trovare delle soluzioni che non trovi su StarCoverFlow, giusto? StarCoverFlow? Ce l'ho manco provata su StarCoverFlow, però mentirei se non ti dicessi che mi sono divertito un mondo.Quando Matteo mi ha affidato il progetto sapevo che mi ci sarei divertito, perciò penso abbia pensato a me.È stato estremamente divertente.Frustrante, ma divertente.Esatto, infatti la domanda per chiudere era quella.Hai avuto dei momenti dove non trovavi la luce? E come hai reagito per andare avanti? Non ho reagito io, è arrivata mia moglie, ha detto "dopo 8 ore staccati da là, io e tua figlia ti aspettiamo e si va avanti".No, scherzo, a parte, in realtà, allora adesso la battuta è la battuta, però è veramente così.nel senso nel mio caso come molti di quelli che lavorano da remoto se non ci sono le famiglie a staccarti dal computer non c'è altro modo di dirlo siamo fottuti perché tutti tu e io gli ascoltatori sappiamo come sviluppatori rischiamo di intestardirci mo ci vuole perché non è solo lavoro è anche passione per molti di noi la maggior parte di noi allora è quando le rodelle non girano e tu invece di staccare continui a cercare di farle girare e buttarci tanniche e tanniche d'olio e non ci riesci e ti finisce solo male.Ho la fortuna di avere una famiglia intorno che con le buone e con le cattive mi stacca letteralmente al computer e mi costringe a fare Context Switch, altrimenti sarei fottuto.A proposito di Context Switch mi è appena arrivato un messaggio su Whatsapp di mia moglie che mi reclama per cena.Esatto, hai capito il punto.Il discorso è che altrimenti noi saremmo siamo i peggiori nemici di noi stessi come categoria.Rimarremo qua come stereotipo, pizza e coca cola programmato tutto il tempo.Quindi mi è capitato quando sono stato da solo in determinati posti ho programmato 15-16 ore, non è una cosa normale perché non c'era nessuno non mi ha fatto capire che nessuno mi levasse di forza da davanti al computer quindi eh sì pensi sia una cosa familiare per tutti noi è quello che mi ha salvato che momenti di sconamento ci sono stati ti ho descritto le fasi critiche del progetto te lo descritte come successo perché l'abbiamo risolte ma per esempio quella del publishing ci abbiamo messo quasi due mesi a trovare una soluzione con diverse metting su meeting e così via.È ovvio che a un certo punto non ce la fai più, vuoi solo vietarti dalla finestra a meno che non c'è qualcuno che ti che ti tira, mettiamola così.Chiarissimo.Paolo io ti ringrazio per essere venuto a trovarci, come dico sempre perché è importante per noi da oggi Gitbar è un po' anche il tuo circolo dove andare a bere una birra, E' un po', no? Non so se ti ricordi, negli anni '80 andava tanto di moda il circolo del dopolavoro ferroviario, no? Il ferroviere, poi ti incontravi là a parlare di treni.E noi siamo un po' il circolo del dopolavoro del videoterminalista metalmeccanico.Ma molto volentieri, perché è una cosa che avevamo messo gli ascoltatori.Mi trovo in Molise, sapete benissimo e fate finta che non esistiamo.Quanti voi dite che siamo di sviluppatori qua in Molise.Siamo un'isola nel nulla, quindi comunità ne faccio molto uso, molto molto volentieri.In ogni caso ti ringrazio per avermi invitato Mauro, mi sono molto divertito, è stata una bella esperienza che spero di ripetere se è possibile in futuro.Assolutamente sì, molto molto volentieri.Quando hai delle cose importanti, che reputi importanti a condividere i progetti challenging delle cose di questo tipo, pingani perché c'è sempre una birra fresca per te.Molto volentieri, molto volentieri.Io ringraziando nuovamente Paolo a nome mio ma immagino anche a nome di tutta la community vi do appuntamento alla prossima settimana sempre qua.Cosa devo aggiungere? I contatti, info@gitbar.it, @brainrepo e il nostro gruppo telegram ciao ciao gitbar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con brain repo parliamo di linguaggi e tecniche di sviluppo web di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei full stack dev [Musica]
