Cosa c'è di speciale nel "non bloccare" node.js?

Rilasciamo immediatamente il disclaimer di Turing-completezza e diciamo che qualsiasi linguaggio può probabilmente approssimare qualsiasi funzione di runtime di qualsiasi altra lingua. Buono? Buona.

La principale differenza tra l'approccio Node.js e un server threaded Python (o un'implementazione tipica del server HTTP Java) è che Node.js è a thread singolo mentre gli ultimi due sono multithread. Più in particolare, questi ultimi in genere dedicheranno un thread per richiesta. Se, nella gestione di tale richiesta, è necessario eseguire un'operazione lenta come quella di lettura da harddrive o connettersi a un database remoto, il thread verrà sospeso fino a quando non verrà eseguita la procedura lenta e il resto della business logic sarà pronto per procedere. Al contrario, l'approccio Node.js è quello di pianificare i callback che devono essere richiamati una volta eseguita la cosa lenta; Il singolo thread di Node.js non dorme mai, tranne se non ci sono letteralmente richieste da elaborare.

La differenza principale tra Node.js e PHP è che in Node.js, il codice viene eseguito in un contesto persistente che esiste finché il server Node.js è in esecuzione. Ad esempio, se si scrive un valore su una variabile globale in una richiesta e si legge il valore della variabile globale in un'altra richiesta, la lettura vedrà il valore scritto dalla scrittura. Al contrario, in PHP, viene creato un nuovo contesto per ogni richiesta, quindi le scritture globali in una richiesta vengono perse quando termina lo script che gestisce la richiesta.

A differenza di tutti gli altri server che hai menzionato, il nodo è a thread singolo, ma asincrono - come alcuni hanno menzionato qui, pianifica i callback anziché attendere l'esecuzione dell'operazione ed esegue i callback quando l'operazione è completa, tuttavia un certo numero di altre operazioni potrebbe essere stato elaborato in mezzo con lo stesso thread.

Avvertenze:

Anche se è un paese delle meraviglie per la programmazione asincrona in cui non è necessario osservare le variabili utilizzate da più thread, se non si ha familiarità con il modo in cui il Node funziona sarebbe necessario applicare un approccio sincrono regolare, questo può trasformarsi in Un'applicazione MOLTO molto lenta man mano che ogni richiesta si accumulerà fino a quando la prima richiesta finirà la sua azione ...

Un programma Node è al centro di un programma normale, non è nemmeno un server Web a meno che non si scriva il codice appositamente per renderlo tale (anche se è abbastanza facile con la libreria HTTP integrata). Il tuo programma riceverà le richieste HTTP e il tuo codice potrà rispondere come più ti piace, utilizzando tutte le risorse altrimenti disponibili per il programma.

Se JavaScript fosse un'esecuzione lineare vecchia scuola, senza un codice complicato e complicato, sarebbe possibile elaborare una sola richiesta alla volta. Ciò è piuttosto negativo, considerato che la maggior parte del tempo impiegato per gestire una richiesta Web viene solitamente spesa in attesa di I / O.

Il flusso del programma JavaScript è tuttavia basato su eventi, si imposta un gestore come una parte di codice che viene eseguita quando si verifica un evento e quando si è gestito tale evento, il codice JavaScript passa automaticamente all'evento successivo nella coda eventi. Se per esempio hai bisogno di una parte di dati dal database per gestire una richiesta non aspetti solo che il database risponda, imposti un gestore di eventi che si attiva quando il database risponde (spesso sotto forma di una funzione di callback ), e si completa il lavoro quando ciò accade, nel frattempo possono essere gestiti molti altri eventi.

Questo è ciò che significa non bloccare, non fermi l'intero programma perché devi aspettare qualcosa.

La cosa bella è che scrivi ancora il tuo codice in un modo prevalentemente lineare, di solito non devi prestare molta attenzione all'effettivo ordine di esecuzione.