La lampada verrà spenta con un nodo?
Scusate il titolo, ma veniva bene. Node.js è in grado si spegnere la cosiddetta “lamp“, ovvero Linux + Apache + Mysql/Mariadb + Php? Faccio questa digressione perché oramai non si parla altro che di Node e di progetti affini o dipendenti ad esso.
Diciamo che in linea teorica è possibile, infatti Node come sappiamo gira anche su macOS e Windows. Certo che dal punto di vista pratico, ovvero al di fuori dello sviluppo, esporre un server ad Internet che non sia Linux è una pessima idea. Resta il fatto che rispetto a PHP sviluppare in Node è molto più agevole perché il suo ambiente si può portare ovunque. Quindi in un certo senso la “L” è salva.
Passiamo ad Apache. Dal punto di vista pratico Node è in grado di esporre un web server a livello nativo, tuttavia non è in grado di gestire Virtual Host e librerie Proxy dedicate alla gestione dei nomi a dominio. Quindi Apache o Nginx rimangono ancora necessari, anzi la loro presenza a mio avviso aumenta la sicurezza. Infatti dovrebbero essere utilizzati come sistemi proxy, ovvero l’applicativo di Node girerà molto probabilmente su una porta che di solito non è (benché lo possa essere) le solite 80 o 443. Quindi con Apache o Nginx si disaccoppia il webserver dall’applicativo, che attraverso le librerie proxy verrà mostrato e girerà come se fosse sulle porte standard. Di fatto un potenziale attaccante si troverebbe davanti a questo strato in più, per altro non facilmente identificabile. Quindi anche la “A” è salva.
Veniamo al database. MySQL o MariaDB. Node è polivalente e può utilizzarli tranquillamente, le librerie sono note e ben documentate e questi due non sono nemmeno gli unici. Tuttavia l’utilizzo migliore, visto che di fatto parla “la stessa lingua” è quello di MongoDB. Certo se raffrontiamo Mongo con MySQL si può persino dire che Mongo stesso non sia proprio un database, non parliamo poi della sicurezza, MongoDB in passato ha sofferto di situazioni piuttosto pesanti. Però analogamente a tutti gli altri database è buona norma non esporli e quindi il loro utilizzo deve essere ad uso “interno”, sia che si parli dello stesso server che un server terzo. Questo porta le eventuali falle di sicurezza a ridursi in modo molto drastico. E in modo empirico anche la “M” è salva.
Infine veniamo alle note dolenti. Il PHP è la vera vittima di Node. Infatti se Node non ha bisogno di PHP, non si può dire il contrario. Ovvero magari ci possono essere situazioni dove non è necessario Javascript, ma siamo onesti, si parla di situazioni da ricercare con il lumino. PHP infatti si limita a processare le richieste a livello server per esporle alla chiamata ricevuta. Una volta che essa è scaricata dal browser del client ha finito il suo lavoro. Con Node invece la questione si sposta anche sul client, ed è in grado di interagire in modo diretto con la parte server.
Me ne sono accorto con il progetto di mapping e cartografia di questo stesso sito. La parte che si vede in PHP in realtà è un mezzo delirio, perché la commistione tra PHP e Javascript si estende su parecchi livelli, e lo stesso codice è complicato proprio dal fatto di dover parlare due lingue diverse. Da un po’ sto lavorando ad un progettino che utilizza le stesse librerie, ma essendo in Node è tutto scritto in Javascript. Ebbene tutta la parte che mi ha occupato diverso tempo per far funzionare le cose tra i due linguaggi è letteralmente scomparsa nel momento che ho utilizzato Node. In pratica è come se andassi al triplo della velocità.
Non è certo oro tutto quello che luccica, Node.js è Javascript, e Javascript è un linguaggio non rigoroso ma piuttosto libero nelle interpretazioni. Ad esempio PHP chiede in modo tassativo la chiusura delle righe, Js no. Se dichiaro un valore di una variabile lo posso fare con i doppi o con i singoli apici, e posso mischiare entrambe le cose nello stesso file. Non a caso in un articolo recente ho trattato EsLint perché mi sono reso conto che il codice ad un certo punto era un delirio stilistico, benché funzionante.
Questo concetto di libertà si riverbera poi su librerie e framework, per cui Node.js in realtà da solo non basta e a cascata servono molte altre cose, che di fatto oltre a gonfiare il progetto a suon di Megabyte, richiedono comunque potenze di calcolo maggiori. E questo sarebbe il problema minore, visto che le librerie e framework equivalgono a km di API da leggersi e conoscere per poter andare avanti.
Forse è un problema momentaneo che deriva anche dal fatto che questi framework non hanno un vincitore. Se Node tra i suoi pari di fatto ha già vinto la guerra, quella del sottoinsieme più diretto è incerta. Si prenda React, Angular e Vue, ognuno dei tre ha peculiarità che l’altro non ha, e i primi due hanno dietro nomi come Facebook e Google che sono vantaggi e svantaggi a seconda del momento. Quale apprendere? è impossibile dirlo ora, React forse è quello che gode di maggiore notorietà, ma è anche il più complicato.
Quello che è certo è che i progetti in PHP si sono enormemente ridotti già nel 2017. Lo stesso WordPress ha messo un piede su queste tecnologie da un pezzo, Guntenberg ne è la dimostrazione. E in molti ipotizzano un cambio di pelle nei prossimi 5 anni. In definitiva la “lampada” non è ancora spenta, certo che la sua luce è già oggi poco più di un lumino.
immagine di copertina Creative Commons CC0 di ColiN00B