Node.js è adatto per l'elaborazione in background?


10

Sto lentamente imparando node.jse ho un piccolo progetto che voglio iniziare. Il progetto avrà molti processi in background (download di dati da siti esterni, analisi di file CSV, ecc.).

Una grande "vittoria" per me e il nodo è il fatto che utilizza JavaScript sia per client che per server. Scrivo codice in Java e JavaScript nel mio lavoro quotidiano, ma sono anche abbastanza bravo in Ruby.

Ma, come ho detto, sembra attraente usare una lingua ovunque e JS sembra adattarsi a quel conto.

Tuttavia, non ho avuto molta esperienza nell'uso di JS per l'esecuzione di lavori in background. Ruby sembra eccellere in questo. E non sono contrario a usarlo. Allora, cosa ne pensi di andare al 100% JS per questo? Realizzo progetti molto grandi che richiedono soluzioni personalizzate. Mi chiedo solo se valga la pena. O dovrei semplicemente attenermi a Ruby per quel tipo di faccende?

Opinioni apprezzate.

Grazie


Puoi anche guardare vert.x come alternativa al nodo.
Mike,

Risposte:


13

È particolarmente forte nel gestire una tonnellata di I / O di file e mi aspetto che gestisca bene anche una tonnellata 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 dover immergerti in qualche C che può essere associato ai comandi JS. Puoi anche generare processi Node aggiuntivi, ma sospetto che fare molto potrebbe essere tassativo (presumo - potrebbe essere sbagliato - c'è un'istanza V8 generata per ognuno di questi).

JS è a thread singolo e blocco, 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 togliendo dalle mani tutti i problemi di threading e di accodamento. JS non impedisce che le cose C / C ++ vengano eseguite in modo più multi-thread sotto il cofano, quindi il ruolo di JS è davvero più architettura / messenger. Se stai elaborando immagini, non vorrai gestirle con i comandi JavaScript sincroni perché tutto il resto sulla tua app o server verrà bloccato fino a quando non sarà completato. L'idea è che si richiede l'elaborazione di un'immagine mediante la funzionalità C / C ++ associata, quindi si risponde all'evento 'done' al termine dell'elaborazione dell'immagine.

Ciò richiede che JS in qualsiasi app Node.js sia fortemente guidato da eventi e callback o che probabilmente funzionerà molto male. Quindi non vedrai molte chiamate di metodo in Node che non ricevono una funzione per un uso successivo. Una cosa che diventa molto chiara molto velocemente in Node è che sei dentro per un mondo di brutti se non trovi un modo per gestire la piramide di callback. per esempio

//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 gestire meglio questo. La maggior parte tende a ruotare attorno a meccanismi promettenti e semplicemente a concatenare una serie di funzioni volte a rispondere reciprocamente agli stati di callback in un array che fa le brutte cose della piramide per te sotto il cofano.

Personalmente, mi piace moltissimo vedere JS di alto livello e C / C ++ più vicini al Chrome. È la combinazione perfetta e mi ha ispirato a iniziare a studiare C. E non lasciare che la mancanza del potenziale della biblioteca ti faccia impazzire fino a quando non hai fatto qualche ricerca. Le librerie di nodi vengono prodotte a un ritmo molto rapido e stanno maturando molto rapidamente. Se non stai facendo qualcosa di molto insolito, le probabilità sono buone che qualcuno l'abbia coperto.

La differenza più grande rispetto a Rails è che JS non è mai probabile che sia su rotaie per così dire. Tendiamo a programmare per essere in grado di averlo nel modo in cui lo desideri molto rapidamente, quindi c'è la corda per aggrapparti al fattore e l'architettura è stata piuttosto fai-da-te in JS fino a anni più recenti. Chiamo quella 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 gran parte del core di Node. Se non funziona in 5 minuti o meno su ogni piattaforma popolare, generalmente lo accartocciamo e lo lanciamo. Devo ancora imbattermi in un modulo popolare che mi richiede di fare qualcosa di speciale per farlo funzionare. Il sistema di pacchetti è eccellente.

Ma per rispondere alla tua domanda principale in modo più esplicito / conciso: è buono con i processi in background?

Sì, il nodo fondamentalmente IS è un processo in background con un mezzo per guidare un'app tramite eventi e callback.


1
Ci sono molte informazioni generali qui, ma non hai detto nulla sulla capacità di node.js di gestire le richieste in modo asincrono.
Robert Harvey,

Buon punto. Metterò un po 'più di attenzione lì.
Erik Reppen,

Come ex sviluppatore di Rails e sviluppatore semi esperto di Node.js, non sono assolutamente d'accordo con il confronto del sistema di pacchetti tra il mondo Ruby / Rails e il mondo JS / Node.js fatto da Erik. Qualsiasi sviluppatore Rails esperto (o addirittura non esperto) sa che le "gemme" sono, letteralmente, come gemme. Funzionano senza sforzo. Molti di questi sono ben collaudati, robusti e stabili. Tuttavia, oltre la metà dei moduli NPM è progettata in modo inadeguato, non testata e nemmeno completata. Ad esempio, nessuno può mostrarmi sostituzioni JS di Devise o Paperclip con esattamente la stessa qualità e ricchezza di funzionalità. Non c'è modo.
scaryguy,

Non è stata la mia esperienza su qualcosa di diverso da un Mac. Detto questo, sono meno impressionato dalla compatibilità cross-OS del tuo tipico modulo di nodo di quanto non fossi prima. Non sono sicuro se ho appena incontrato più uova cattive con esperienza o se la comunità è cresciuta fino a includere un sacco di sviluppatori che non prendono la multipiattaforma sul serio come dovrebbero. Ma c'è sicuramente qualche snobismo Linux là fuori.
Erik Reppen,

Questa risposta merita tanti voti positivi
Amin Mohamed Ajani,

2

Un problema da tenere presente è ciò che si verifica quando si elaborano file di grandi dimensioni in un ambiente asincrono : se il flusso di input (un file) è più veloce del flusso di output (il db), non sarà possibile gestire rapidamente gli eventi dei dati di input abbastanza. Ciò sopraffarà parte del sistema (flusso di output o memoria) o causerà la perdita di dati. Per questo motivo, l'elaborazione dei dati in modo asincrono può essere un po 'complicata. Ma come spiega l'articolo a cui mi sono collegato, la possibilità di mettere in pausa il flusso di input rende possibile l'accelerazione in un modo che si adatta alla tua situazione.


1

Node.js eccelle in IO. È molto improbabile che un giorno scoprirai che il processo si è inceppato poiché la maggior parte dei thread si blocca nelle chiamate SQL.

Tuttavia node.js è davvero pessimo nel lavoro con calcolo. Quando sento "un sacco di IO" penso "sì! Vai nodo!", Ma quando sento "analizzare" esito un po '. Non sono sicuro che questo sia per qualsiasi motivo oltre alle persone che non eseguono correttamente il multithreading del nodo, ma finora tutto il lavoro di calcolo del mio prodotto avviene al di fuori del nodo.

Il multithreading in node.js è difficile da configurare correttamente. Tutto è a thread singolo per impostazione predefinita e la maggior parte del codice è scritta supponendo che verrà eseguita solo su un thread. Dovrai certamente usare i domini per evitare che un errore su un thread possa far cadere l'intera applicazione.

Si noti inoltre che il nodo potrebbe essere un po 'più debole in alcune funzionalità aziendali. Ad esempio, le sue librerie di registrazione non sono paragonabili a quelle di Java. Al momento non esiste un buon framework di registrazione che supporti e MDC, il che in pratica significa che si può fare var logPrefix = userId + ": "molto.

Inoltre non ho mai eseguito un repository npm privato, potresti averne bisogno a seconda che il tuo codice sia proprietario.


1

Se i tuoi processi in background possono essere eseguiti in sequenza, può essere abbastanza buono. Nella mia ultima posizione, ho dovuto scrivere una serie di pre-processori, esportazioni e utilità di traduzione per molte fonti di dati. Usare NodeJS è stato un gioco da ragazzi qui.

Se non stai eseguendo molta elaborazione legata al calcolo, semplice manipolazione di stringhe brevi e analisi di numeri interi non è così male, se devi manipolare le immagini, probabilmente non è lo strumento migliore (anche se ci sono wrapper e moduli richiamabili che può funzionare bene).

Consiglio, attenersi ai moduli che utilizzano flussi. Ciò può semplificare l'instradamento dell'elaborazione ai moduli per quel particolare passaggio. Ad esempio, se guardi come viene utilizzato il flusso di eventi in gulp-jade per lo strumento di compilazione gulp , puoi vedere quanto è capace.

Per CSV, puoi usare node-csv , che è abbastanza bravo a stabilire una base per il piping dei record a un flusso di processore.

Per XML di grandi dimensioni, in cui si desidera eseguire un singolo record alla volta, vorrei esaminare node-halfstreamxml che legge il flusso XML utilizzando un processore SAX e genera eventi per ciascun nodo. Lo avvolgo in un flusso di lettura / scrittura in modo da poter aumentare le corrispondenze desiderate. Molti parser di oggetti xml nel nodo tenteranno di leggere / analizzare l'intero xml contemporaneamente, e per esempio 100mb di xml che diventano enormi ... dove il halfstreamxml leggerà come un flusso.

NOTA: ci sono altri processori come xml-stream che useranno expat (libreria C) sotto, che può dare più prestazioni, ma meno portatile senza un ambiente di compilazione.

In generale, è stata una vera gioia usare ...

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.