Ciao, e benvenuto nella quarta puntata della ventiquattresima stagione. Nella scorsa puntata abbiamo scoperto il ciclo degli eventi, il cameriere unico che non aspetta mai. Ma questo modo di funzionare, così efficiente, ha un prezzo: richiede un modo di pensare e di scrivere il codice diverso da quello a cui si è abituati, che all'inizio spiazza. È il pensiero asincrono. Oggi capiamo cos'è, perché è necessario per far funzionare il ciclo degli eventi, e perché rappresenta il cambiamento mentale più importante per chi lavora con Node.
Partiamo dal modo normale di pensare al codice, quello a cui siamo abituati, per poi vedere come cambia. Di solito, immaginiamo un programma come una sequenza di passi che si eseguono uno dopo l'altro, in ordine. Fai la prima cosa, aspetti che finisca, poi fai la seconda, aspetti che finisca, poi la terza. Se un passo richiede tempo, chiedere un dato alla base di dati, semplicemente aspetti lì, fermo, che quel dato arrivi, e solo dopo prosegui. È il modo naturale, intuitivo, di pensare: una cosa alla volta, aspettando ciascuna prima di passare alla successiva. Questo modo si chiama sincrono, e ha una caratteristica: quando aspetti qualcosa, ti blocchi, ti fermi lì.
Ma ecco il problema: questo modo di pensare, con il suo bloccarsi ad aspettare, è incompatibile con il ciclo degli eventi di Node. Ricordi, il cameriere unico non deve mai fermarsi ad aspettare, altrimenti tutto il ristorante si blocca. Se il codice si ferma ad aspettare un dato, il lavoratore unico resta fermo lì, e nessun altro cliente viene servito nel frattempo: il cuore stesso del modello di Node crolla. Quindi, per far funzionare Node, non puoi scrivere codice che si blocca ad aspettare. Devi scrivere codice che, quando incontra un'attesa, non si ferma, ma lascia proseguire il lavoratore verso altro. E questo richiede un modo di pensare diverso.
Ed ecco il pensiero asincrono, che voglio spiegarti bene perché è il cambio mentale chiave. Nel modo asincrono, quando incontri una cosa che richiede attesa, non dici aspetto qui che finisca. Dici invece: avvia questa cosa, e quando sarà finita, ecco cosa fare. Non aspetti il risultato: dici in anticipo cosa fare quando il risultato sarà pronto, e intanto lasci proseguire tutto il resto. È il passaggio da aspetto il risultato a fatti avvisare quando il risultato è pronto. Non ti blocchi ad attendere: prepari le istruzioni per dopo, e vai avanti. La cosa che aspettavi verrà completata più tardi, quando sarà pronta, senza aver bloccato nulla nel frattempo.
Torniamo al ristorante, perché rende l'idea perfettamente. Nel modo sincrono, il cameriere direbbe: prendo l'ordine, lo porto in cucina, e aspetto qui fermo finché il piatto è pronto, poi lo servo. Si blocca. Nel modo asincrono, invece, dice: prendo l'ordine, lo porto in cucina, e lascio detto avvisatemi quando il piatto è pronto, così vado intanto a servire altri tavoli; quando mi avvisate, verrò a prenderlo e a servirlo. Non aspetta: lascia un'istruzione per dopo e prosegue. Questa istruzione, questo ecco cosa fare quando la cosa sarà pronta, è il concetto centrale del pensiero asincrono. Dici cosa fare in futuro, quando qualcosa sarà pronto, invece di aspettare fermo che quel qualcosa arrivi.
Voglio essere onesto sul fatto che questo modo di pensare, all'inizio, è spiazzante, perché lo è davvero. Siamo abituati a pensare in modo sequenziale, una cosa dopo l'altra, aspettando ciascuna. Pensare in modo asincrono, avviare cose e dire cosa fare quando finiranno, senza aspettarle, capovolge questa abitudine. Il flusso del codice non è più una semplice sequenza dall'alto in basso: le cose vengono avviate, e poi completate più tardi, in un ordine che dipende da quando ciascuna diventa pronta. All'inizio, questo può confondere, disorientare, sembrare contorto. Ci vuole un po' per abituarsi a ragionare così. Ma una volta che il modello ti entra in testa, diventa naturale, e capisci perché è necessario: è il prezzo, e insieme la chiave, dell'efficienza del ciclo degli eventi.
Voglio farti apprezzare il legame profondo tra il pensiero asincrono e tutto ciò che rende Node speciale, perché ora si chiude il cerchio. Il ciclo degli eventi, il cameriere che non aspetta mai, funziona solo se il codice è scritto in modo asincrono, in modo da non bloccarsi mai sulle attese. Il pensiero asincrono non è quindi un capriccio o una complicazione gratuita: è ciò che permette al modello di Node di funzionare, ciò che consente a un solo lavoratore di servire migliaia di clienti. È scomodo all'inizio, sì, ma è il fondamento su cui poggia tutta l'efficienza di Node. Il non aspettare mai del cameriere e il pensiero asincrono del codice sono le due facce della stessa medaglia: senza il secondo, il primo non sarebbe possibile.
Per oggi ci fermiamo qui. Il ciclo degli eventi richiede un modo di scrivere il codice diverso, il pensiero asincrono. Nel modo normale, sincrono, quando incontri un'attesa ti blocchi lì, fermo, finché finisce, ma questo bloccarsi è incompatibile con il cameriere unico che non deve mai fermarsi. Nel pensiero asincrono, invece, quando incontri un'attesa non aspetti: avvii la cosa, dici in anticipo cosa fare quando sarà pronta, e prosegui, come il cameriere che lascia detto avvisatemi e va a servire altri tavoli. È spiazzante all'inizio, perché capovolge l'abitudine sequenziale, ma è il fondamento che rende possibile l'efficienza di Node. Nella prossima puntata vediamo come, nel tempo, si è reso questo modo di scrivere più sereno. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.