È particolarmente efficace nel gestire una tonnellata di I / O di file e mi aspetto che gestisca anche un sacco di comunicazioni di rete. Sembra particolarmente popolare per le app basate su socket. La cosa importante da tenere a mente è che se le tue esigenze non sono soddisfatte dalle librerie esistenti (ce ne sono molte) potresti aver bisogno di immergerti in una C che può essere associata ai comandi JS. È anche possibile generare processi Node aggiuntivi, ma sospetto che fare un sacco di quello che potrebbe diventare tassativo (presumo - potrebbe essere sbagliato - c'è un'istanza V8 generata per ognuno di questi).
JS è single-threaded e blocking, il che significa che nient'altro può essere eseguito fino al completamento di una chiamata di funzione. Questa era una caratteristica desiderata di JS, essenzialmente prendendo tutte le preoccupazioni di threading e accodamento dalle tue mani. Il JS non impedisce al materiale C / C ++ di funzionare in un modo più multi-thread sotto il cofano, quindi il ruolo di JS è davvero più architettura / messenger. Se stai elaborando le immagini, non vorrai gestirle con i comandi sincroni di JavaScript, perché tutto il resto della tua app o del tuo server verrà bloccato fino al completamento. L'idea è che tu richieda che un'immagine venga elaborata dalla funzionalità C / C ++ associata e poi risponda all'evento 'done' quando l'immagine è finita in fase di elaborazione.
Ciò richiede che il JS in qualsiasi app Node.js sia pesantemente supportato da eventi e callback o che probabilmente funzionerà molto male. Quindi non vedrai molte chiamate al metodo in Node che non ricevono una funzione per un uso successivo. Una cosa che diventa molto chiara in Node è che ti trovi in un mondo di brutti se non trovi un modo per gestire la piramide del callback. per es.
//event CBs are more DOM-style than Node style and this isn't built-in Node file I/O
//keeping it simple and quick since I'll just get Node stuff wrong from memory
file.get('someFile.txt', function(e){
e.fileObj.find('some snippet', function(e){
someFinalCallBackHandler( e.snippetLocations );
} );
} );
Fortunatamente ci sono molti strumenti ed esempi là fuori per gestirlo meglio. La maggior parte tende a ruotare intorno a meccanismi di promessa e semplicemente a concatenare una serie di funzioni pensate per rispondere ai reciproci stati di callback in un array che fa la brutta piramide per te sotto il cofano.
Personalmente, mi fa impazzire l'amore che otteniamo JS ad alto livello e C / C ++ più vicino al cromo. È l'ultima combo e mi ha ispirato a iniziare a imparare C. E non lasciare che la mancanza di potenziale della biblioteca ti faccia impazzire finché non hai fatto qualche ricerca. Le librerie dei nodi vengono prodotte a un ritmo molto rapido e stanno maturando molto rapidamente. Se non stai facendo nulla di molto insolito, le probabilità sono buone, qualcuno lo ha coperto.
La più grande differenza rispetto a Rails è che JS non è mai probabile che si trovi su binari. Tendiamo a codificarci per poterlo avere, ma lo vuoi molto rapidamente, quindi c'è la corda per impiccarti con il fattore e l'architettura è stata abbastanza fai-da-te in JS fino agli anni più recenti. Lo chiamo libertà, ma mi rendo conto che non è visto come ideale per molti sviluppatori.
Inoltre, non avrai mai un problema "gemma" in Node.js perché hai provato a installare su qualcosa di diverso da un Mac. Gli sviluppatori Web sul lato client disprezzano i problemi di dipendenza ed è da lì che proviene un sacco di core di Node. Se non funziona fuori dalla scatola in 5 minuti o meno su ogni piattaforma popolare, generalmente la accartocciamo e la lanciamo. Devo ancora imbattersi in un modulo popolare che richiede che io faccia qualcosa di speciale per farlo funzionare. Il sistema dei pacchetti è eccellente.
Ma per rispondere alla tua domanda principale più esplicitamente / sinteticamente: Funziona bene con i processi in background?
Sì, il nodo è fondamentalmente un processo in background con un mezzo per guidare un'applicazione tramite eventi e callback.