Ciao, e benvenuto nella seconda puntata della ventiquattresima stagione. Nella scorsa puntata abbiamo visto Node liberare JavaScript dal browser e portarlo sui server. Ma per costruire un buon server serviva risolvere un problema difficile, lo stesso che ha guidato tante scelte di Node: come si fa a servire tantissime richieste contemporaneamente, in modo efficiente? Oggi inquadriamo bene questo problema, perché capirlo è la chiave per apprezzare la soluzione geniale e insolita che Node ha adottato, e di cui parleremo nella prossima puntata. Oggi, il problema dei tanti clienti.
Partiamo dal ricordare cosa fa un server, dalle stagioni precedenti. Un server è un computer che sta lì, in attesa, e risponde alle richieste che gli arrivano dalla rete. Un utente chiede una pagina, un dato, un'operazione, e il server la elabora e risponde. Fin qui, semplice. Ma il punto cruciale è che un server vero non parla con un utente alla volta: ne serve tantissimi contemporaneamente. Migliaia di persone, nello stesso momento, mandano richieste allo stesso server, e lui deve gestirle tutte insieme, in fretta, senza far aspettare nessuno troppo a lungo. Servire tanti clienti contemporaneamente è l'essenza stessa del lavoro di un server, ed è tutt'altro che banale.
Vediamo il modo tradizionale di affrontare questo, perché è ciò da cui Node si è discostato. L'approccio classico era: per ogni cliente che arriva, assegna un lavoratore dedicato che se ne occupa. Immagina un ristorante in cui, per ogni tavolo che si siede, arriva un cameriere personale dedicato solo a quel tavolo, che lo segue dall'inizio alla fine. Con pochi tavoli funziona benissimo. Ma con migliaia di tavoli, ti servono migliaia di camerieri, e qui nascono i guai: ogni lavoratore costa risorse alla macchina, occupa memoria, e averne migliaia diventa pesantissimo, fino a mettere in ginocchio il server. Il modello un lavoratore per cliente non regge bene su grandissimi numeri, perché i lavoratori sono costosi.
Ma c'è un'osservazione ancora più profonda e interessante, che è il vero seme della soluzione di Node, e voglio che la afferri bene. Se osservi cosa fa davvero un server mentre gestisce una richiesta, scopri una cosa sorprendente: passa la maggior parte del tempo ad aspettare. Aspetta che la base di dati risponda a una domanda. Aspetta che il disco fornisca un file. Aspetta che la rete consegni dei dati. Queste attese, il chiedere qualcosa a un disco, a una base di dati, a un'altra macchina, e attendere la risposta, occupano gran parte del tempo di una richiesta. E durante quelle attese, il lavoratore assegnato a quel cliente non fa nulla: sta lì, fermo, a girarsi i pollici, aspettando. È tempo sprecato.
Voglio farti apprezzare quanto sia grande questo spreco, con il ristorante, perché è il cuore di tutto. Immagina un cameriere assegnato a un tavolo. Prende l'ordine, lo porta in cucina, e poi cosa fa? Sta lì, fermo davanti alla cucina, ad aspettare che il piatto sia pronto, senza fare nient'altro, per tutto il tempo della preparazione. È assurdo: un cameriere capace che resta immobile ad aspettare, mentre altri tavoli avrebbero bisogno di lui. Nel modello un lavoratore per cliente, la maggior parte dei lavoratori, in ogni momento, è così: ferma ad aspettare qualcosa, sprecando la propria capacità di lavorare. Questo spreco enorme, tanti lavoratori costosi che passano il tempo fermi ad aspettare, è il problema che Node ha voluto risolvere.
Ed ecco la domanda che apre la porta alla soluzione, che voglio lasciarti come ponte verso la prossima puntata. Se il problema è che i lavoratori passano il tempo fermi ad aspettare, sprecando risorse, allora forse la soluzione non è avere tanti lavoratori, ognuno che aspetta il suo. Forse la soluzione è cambiare completamente il modo di gestire l'attesa. E se, invece di far aspettare i lavoratori, trovassimo un modo per non aspettare mai, per non stare mai fermi? Se un solo lavoratore, invece di bloccarsi ad aspettare, potesse, durante l'attesa, occuparsi di altri clienti? È esattamente questa la domanda a cui Node risponde, e la risposta è tanto semplice quanto rivoluzionaria.
Voglio darti anche la distinzione che sta al cuore di tutto, perché ci tornerà utile. Il lavoro di un server si può dividere in due tipi. C'è il lavoro di attesa: chiedere dati a un disco, a una base di dati, alla rete, e aspettare la risposta. E c'è il lavoro di calcolo: far lavorare davvero il processore su un problema. La maggior parte del lavoro di un server tipico, che serve pagine e dati, è lavoro di attesa: passa il tempo a chiedere cose ad altri e ad aspettare le risposte, non a calcolare intensamente. E questa prevalenza dell'attesa è precisamente ciò che rende vincente la soluzione di Node. Tienilo a mente: attesa contro calcolo.
Per oggi ci fermiamo qui. Un server deve servire tantissimi clienti contemporaneamente, e il modo tradizionale, un lavoratore dedicato per ogni cliente, non regge su grandi numeri, perché i lavoratori sono costosi. Ma l'osservazione cruciale è un'altra: un server passa la maggior parte del tempo ad aspettare, il disco, la base di dati, la rete, e durante quelle attese i lavoratori restano fermi, sprecando risorse, come camerieri immobili davanti alla cucina. Da qui la domanda che apre la soluzione di Node: e se, invece di far aspettare tanti lavoratori, ne avessimo uno solo che non aspetta mai? Nella prossima puntata scopriamo questa risposta geniale: il ciclo degli eventi. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.