Alessandro Miliucci è uno sviluppatore con una lunga esperienza nella gestione di progetti e nella creazione di architetture, front-end e back-end, in particolare con JavaScript e Node.js. Ha collaborato allo sviluppo della neobank Hype e fondato una startup del settore e-commerce; attualmente lavora nel settore fintech in Fabrick .
Potete trovarlo a un sacco di conferenze in cui non si risparmia mai, sia come speaker sia come attendee. Molto attivo nelle community specialmente Roma js e Mongodb, è autore, finora, di due libri: uno su React per cui lo abbiamo intervistato l’anno scorso, a questo link trovate il video, e Node.js: Guida per creare API e applicazioni in JavaScript.
Savino Carlone e Andrea Maietta hanno fatto il solito casino che ho tentato di filtrare per quanto possibile. Qui un estratto delle domande in ordine cronologico. L’intervista dura circa 45 minuti, come tutte quelle del Devs Book Club. Potete ascoltarla a tutto volume o vederla sul telefono mentre partecipate, impotenti, a una call con il marketing che ignora che voi vi occupate di backend dal 1990.
Domanda
Parlaci di te e di come è nato il libro.
Risposta
Ciao, io sono Alessandro, come credo molti altri qui sviluppo software e lavoro in Fabrik, una società che si occupa di fintech. Prima di questo ho fatto tutta una serie di cose, startup e startup e ancora startup. Questo libro nasce anche grazie a queste esperienze dove Node.js mi ha permesso di fare veramente molte cose, molto semplicemente, molto in grande e anche molto velocemente.
Quindi è nato da un’esperienza diretta e poi da una mia passione per una tecnologia che è così, diciamo, malleabile e molto utile per gli sviluppatori: credo sia disprezzato principalmente da chi non l’ha mai utilizzato, perché una volta che lo si utilizza si capisce che è difficile trovare qualcosa di più pratico e pragmatico per creare quello che si vuole e quando lo si vuole.
Domanda
Puoi spiegarci cos’è Node.js per chi non lo conosce, cosa c’entra con JavaScript?
Risposta
JavaScript è il linguaggio che viene messo a disposizione da Node.js, che però è un runtime, quindi non è lo stesso JavaScript che si usa all’interno del browser. Il linguaggio è lo stesso ma le API a disposizione sono completamente diverse: quindi non ci sono quelle per manipolare la pagina, ma avete delle API per usare HTTP, TCP, il file system; quello che vi aspettate dal back end è già scritto.
In realtà è, diciamo, la coperta che c’è sopra, perché in realtà quello che avete con Node è un engine C++, è JavaScript, è solo il linguaggio che vi permette di usarlo. All’interno c’è un pezzo di Chrome, che è l’interprete di JavaScript unito a un’altra libreria, che serve da strato verso il sistema operativo e tutte queste API che abbiamo detto. Quindi Node dispone delle API all’interno. Questo runtime si chiama V8.
Domanda
Visto che Node ha bisogno di poche risorse, ci sono tutta una serie di sistemi, tipicamente quelli embedded, che hanno poche risorse. Hai mai avuto delle esperienze con ambienti Node su Raspberry Pi o cose del genere? Ti vengono in mente dei casi d’uso per queste cose qui?
Risposta
Sì, si presta secondo me un po’ per tutto ovviamente. Poi il caso lo devi valutare bene, però il fatto che di per sé consumi molto poche risorse lo rende ottimale sia su sistemi dove comunque il consumo di memoria o di risorse CPU è limitato. Per delle applicazioni che magari devono girare dentro un container, quindi un singolo processo dentro un container, diciamo che Node calza perfettamente, rende tutto molto più semplice da questo punto di vista. Quindi sì, lo puoi usare per fare cose piccole e lo puoi usare anche per fare cose grandi. La cosa buona è che le risorse crescono quando serve, non prima.
Completamente diverso da software del passato dove, nel momento in cui lanciavi il web server, veniva creata una montagna di processi che stavano lì ad aspettare richieste. Pur senza far niente, questo server consumava tutta la memoria. No vabbè, molta della memoria e molte delle risorse di calcolo disponibili della macchina vengono utilizzate quando servono e non prima o dopo.
Domanda
Il libro è molto bello, mi è piaciuto tanto seguire gli esempi che hai fatto. È anche una riscoperta di certe cose che uno dà per scontato, no? È stato molto interessante. Una cosa cattiva che mi piace sempre tirare fuori è che tu dici che Node con poche risorse è performante, eccetera, però poi c’è NPM da una parte dove scarichi di tutto di più e la risorsa viene messa a rischio. Mi sa che è l’hard disk sulle macchine su cui girano quelli che fanno i giochi. Da questo punto di vista?
Risposta
“Beh sì, quello lì è qualcosa che, diciamo, una delle parti che sta in teoria cambiando di più dell’ecosistema Node, perché Node è sviluppato dal team di Node.js, mentre NPM è fatto da un altro team, in particolare di GitHub che è di Microsoft. Viene fornito insieme, ma non è sviluppato dallo stesso team e questa cosa proprio adesso sta creando tutta una serie di attriti perché Node e il team ha sviluppato un sistema che si chiama Korpack che crea uno strato tra NPM, che è il gestore delle dipendenze, quindi quello che vi scarica i moduli esterni in libreria, come volete chiamarle, e il gestore delle dipendenze stesso.
Quindi invece di dover per forza utilizzare NPM, con quello strato a voi non interessa quello che c’è sotto, si occupa di tutto questo Korpack, gestendolo in autonomia. Perché oltre a NPM esiste anche Yarn che ha avuto il suo momento d’oro un po’ di anni fa. Poi adesso c’è PNPM che è molto più performante soprattutto per il disco, quindi non crea duplicati di file ma utilizza tutto un meccanismo molto sofisticato di link sul file system.
E quindi è un aspetto, quello lì, che è di grande cambiamento che c’è adesso. Ecco, una delle parti che è più messa in discussione proprio per tutti i problemi di NPM, quindi sicurezza, dimensione dei file, però dal mio punto di vista soprattutto sicurezza.”
Domanda
Mi piacerebbe chiedere qualcosa sul processo di scrittura del libro “Node.js: Guida per creare API e applicazioni in JavaScript“. Quali sono state le cose più difficili ed inaspettate e che consigli daresti a qualcuno che vuole scrivere un libro tecnico?
Risposta
“Ma guarda, secondo me è una cosa faticosa, però divertente scrivere un libro sicuramente ti mette di fronte a delle sfide che non pensavi, perché magari tu puoi conoscere tutta la tecnologia che vuoi, software che vuoi, linguaggi che vuoi, però puoi spiegarlo? E soprattutto farlo arrivare è molto difficile. Credo che tutti avranno avuto le esperienze, magari di andare all’università con i professori geniali, incapaci però di spiegare poi le cose che sapevano.
Quindi quando scrivi il libro il primo problema è capire come comunicare quello che tu hai in testa, le cose che sai. Questa è una cosa molto molto difficile perché devi portarti sempre dall’altra parte, quindi non da chi sa già le cose, ma da chi non le sa. E capire se quelle tue spiegazioni sono sufficienti. Per questo qui però ti aiuta molto avere magari persone che non conoscono quella tecnologia. Che rileggono e ti dicono se hanno capito e cosa ne pensano. Però questa cosa non è sempre possibile. Non è poi sempre così semplice trovare persone che ti aiutano nel fare questa cosa.
L’altra cosa secondo me molto critica è pianificarlo. Io personalmente su questo ho creato una struttura che pensavo di seguire, una serie di capitoli, questo argomento, questo argomento con dei dettagli. Quello che succede inevitabilmente è che mentre scrivi esce fuori qualche cosa, qualche dettaglio, qualche spiegazione che devi mettere in più e che ti sconvolge quello che devi dire.
Diciamo che ho seguito poi quest’onda perché credo sia meglio scrivere in modo che le spiegazioni arrivino bene, piuttosto che cercare per forza di voler dire le cose che vuoi tu, quindi seguire un po’ come viene, a un certo punto mantenere una struttura. Quindi fare questa cosa qui. Però ho fatto questo secondo libro anche perché non mi andava di sprecare tutte le cose che ho imparato scrivendo il primo perché comunque si impara veramente tanto quando fai un’attività del genere. Quindi sì, io direi a tutti di provarci a farlo, anche solo per se stessi…”
