Domanda

Io non ottenere ciò che Node.js è tutto.Forse è perché io sono principalmente un web based di business application developer.Che cosa è e che cosa è l'uso di esso?

La mia comprensione è che:

  1. Il modello di programmazione è guidata dagli eventi, in particolare il modo in cui gestisce I/O.
  2. Utilizza JavaScript e il parser è V8.
  3. Può essere facilmente utilizzato per creare server concorrente applicazioni.

Sono le mie conoscenze in modo corretto?Se sì, quali sono i vantaggi di evented di I/O, è solo un di più per la concorrenza roba?Inoltre, è la direzione di Node.js per diventare un quadro, come, JavaScript based (V8 base) modello di programmazione?

È stato utile?

Soluzione

Credo che i vantaggi sono:

  1. Lo sviluppo Web in un linguaggio dinamico (JavaScript) su una macchina virtuale che è incredibilmente veloce (V8). E 'molto più veloce di Ruby, Python o Perl.

  2. Capacità di gestire migliaia di connessioni simultanee con minimo carico su un singolo processo.

  3. JavaScript è perfetto per l'evento loop con oggetti di prima classe di funzione e chiusure. Le persone sanno già come usarlo in questo modo averne fatto uso nel browser per rispondere a eventi utente iniziati.

  4. Un sacco di persone già conoscono JavaScript, anche le persone che non pretendono di essere programmatori. E 'senza dubbio il linguaggio di programmazione più popolari.

  5. Utilizzando JavaScript su un server web e il browser riduce il disadattamento di impedenza tra i due ambienti di programmazione che possono comunicare tramite strutture di dati JSON che funziona lo stesso su entrambi i lati dell'equazione. Duplicate forma di codice di convalida può essere condiviso tra server e client, ecc.

Altri suggerimenti

Io uso Node.js al lavoro e trovano che sia molto potente.Costretto a scegliere una parola per descrivere Node.js direi che il "interessante" (che non è un fatto puramente positivo aggettivo).La comunità è viva e in crescita.JavaScript, nonostante le sue stranezze può essere un grande linguaggio in codice.E tutti i giorni si possono ripensare il vostro concetto di "best practice" e i modelli di ben strutturato il codice.C'è un enorme dispendio di energie, di idee che scorre in Node.js in questo momento, e che lavorano in essa si espone a questo modo di pensare - mentali di sollevamento pesi.

Node.js in produzione è sicuramente possibile, ma lontano dal "turn-key" distribuzione apparentemente promesso dalla documentazione.Con Node.js v0.6.x, "cluster" è stato integrato nella piattaforma, fornendo un elemento essenziale, ma il mio "production.js" script è ancora ~150 linee di logica per gestire cose come la creazione di directory del registro, riciclaggio morto lavoratori, etc.Per un "grave" servizio di produzione, è anche necessario essere preparati a manetta le connessioni in entrata e fare tutte le cose che Apache non per PHP.Per essere onesti, Ruby on Rails è questo esatto problema.Si è risolto tramite due meccanismi complementari:1) Mettere Ruby on Rails/Node.js dietro dedicato webserver (scritto in C e testato all'inferno e ritorno) come Nginx (o Apache / Lighttd).Il webserver può servire in modo efficiente i contenuti statici, accesso registrazione, la riscrittura degli Url, terminare SSL, far rispettare le regole di accesso e gestire più sotto-servizi.Per le richieste che hanno colpito il nodo effettivo servizio, il server web inoltra la richiesta attraverso.2) Utilizzo di un framework come Unicorn che dovrà gestire i processi di lavoro, a riciclare i loro periodicamente, etc.Devo ancora trovare un Node.js servono quadro che sembra completamente cotto;può esistere, ma non ho trovato ancora e ancora uso ~150 righe nel mio arrotolato a mano "production.js".

La lettura di framework come Express fa sembrare che la pratica standard è quello di servire il tutto attraverso un jack-of-all-trades Node.js servizio ..."app.utilizzare(express.statico(__dirname + '/pubblico'))".Per abbassare il carico di servizi e di sviluppo, che è probabilmente bene.Ma non appena si tenta di mettere il tempo grande carico di lavoro del vostro servizio e farlo funzionare 24/7, scoprirete presto le motivazioni che spingono i grandi siti di aver ben cotto, temprato C-codice Nginx di fronte al loro sito e la gestione di tutti i contenuti statici richieste (...fino a quando si imposta un CDN, come Amazon CloudFront)).Per un po ' umoristico e sfacciatamente negativi prendere su questo, vedere questo ragazzo.

Node.js è anche la ricerca di ulteriori e più non utilizza il servizio.Anche se si utilizza qualcosa di diverso per servire contenuti web, si potrebbe ancora utilizzare Node.js come uno strumento di compilazione, utilizzando npm i moduli per organizzare il tuo codice, Browserify a punto in un singolo bene, e uglify-js per minimizzare per la distribuzione.Per affrontare il web, JavaScript è un perfetto adattamento di impedenza e, di frequente, che rende il percorso più semplice di attacco.Per esempio, se si desidera strisciare attraverso un sacco di JSON risposta payload, si dovrebbe usare il mio underscore-CLI modulo, l'utilità cintura di dati strutturati.

Pro / Contro:

  • Pro:Per un server ragazzo, la scrittura di codice JavaScript sul back-end è stato un "gateway drug" per l'apprendimento moderni modelli di interfaccia utente.Non ho più il terrore di scrivere il codice del cliente.
  • Pro:Tende a favorire un corretto controllo di errore (err viene restituito da quasi tutte richiamate, fastidioso al programmatore di gestire;inoltre, async.js e altre librerie di gestire il "fail se una qualsiasi di queste attività secondarie non riesce" paradigma molto meglio rispetto alle tipiche codice sincrono)
  • Pro:Alcune interessanti e normalmente è difficile compiti diventano banali, come lo stato di attività in volo, la comunicazione tra i lavoratori, o la condivisione dello stato della cache
  • Pro:Comunità enorme e tonnellate di grandi librerie basate su una solida package manager (npm)
  • Con:JavaScript non ha la libreria standard.Si ottiene così utilizzato per la funzionalità di importazione che è strano quando si utilizza il formato JSON.analizzare o qualche altro costruire nel metodo che non richiede l'aggiunta di un npm modulo.Questo significa che ci sono cinque versioni di tutto.Anche i moduli inclusi nel Node.js "core" sono cinque le varianti devono essere infelice con l'implementazione di default.Questo porta ad una rapida evoluzione, ma anche un certo livello di confusione.

Rispetto a un semplice one-processo-per-modello di richiesta (LAMPADA):

  • Pro:E scalabile per le migliaia di connessioni attive.Molto veloce e molto efficiente.Per un web flotta, questo potrebbe significare un 10X riduzione del numero di caselle necessarie rispetto a PHP o Ruby
  • Pro:La scrittura di modelli paralleli è facile.Immaginate che avete bisogno di recuperare tre (o N) blob dal Memcached.Fate questo in PHP ...hai solo scrivere il codice recupera il primo blob, poi il secondo, poi il terzo?Wow, che è lento.C'è una speciale PECL modulo di risolvere il problema specifico per Memcached, ma cosa succede se si desidera recuperare un po ' di Memcached di dati in parallelo con la query sul database?In Node.js perché il paradigma è asincrona, avendo una richiesta web fare più cose in parallelo è molto naturale.
  • Con:Codice asincrono è fondamentalmente più complesso di codice sincrono, e up-front, la curva di apprendimento può essere difficile per gli sviluppatori che non hanno una solida comprensione di ciò che l'esecuzione simultanea significa in realtà.Ancora, è molto meno difficile di quanto la scrittura di qualsiasi tipo di codice multithread, con chiusura.
  • Con:Se un compute-intensive richiesta viene eseguito per, ad esempio, 100 ms, che andrà in stallo, l'elaborazione di altre richieste che vengono trattati nella stessa Node.js il processo di ...AKA, cooperativa-multitasking.Questo può essere mitigato con il Web Lavoratori pattern (filatura fuori un sottoprocesso per affrontare il compito costoso).In alternativa, è possibile utilizzare un gran numero di Node.js lavoratori e solo ognuno di gestire una singola richiesta contemporaneamente (ancora abbastanza efficiente, perché non vi è alcun processo di riciclo).
  • Con:L'esecuzione di un sistema di produzione è MOLTO più complicata di una CGI modello come Apache + PHP, Perl, Ruby, etc.Le eccezioni non gestite abbattere l'intero processo, che necessita di logica per riavviare fallito lavoratori (vedi cluster).I moduli con il buggy codice nativo può rigido in crash il processo.Ogni volta che un lavoratore muore, tutte le richieste è stato di movimentazione vengono eliminati, così un buggy API può facilmente degradare il servizio per altri cohosted Api.

Contro la scrittura di un "vero" servizio in Java / C# / C (C?davvero?)

  • Pro:Facendo in asincrono Node.js è più facile che fare thread di sicurezza in qualsiasi altro luogo e, probabilmente, fornisce un maggior beneficio.Node.js è di gran lunga il meno doloroso possibile e asincrona paradigma che io abbia mai lavorato.Con buona librerie, è solo leggermente più difficile che scrivere codice sincrono.
  • Pro:Non multithreading / chiusura bug.Vero, investire di fronte a scrivere di più dettagliato codice che esprime un giusto asincrona flusso di lavoro senza le operazioni di blocco.E avete bisogno di scrivere un po ' di test e ottenere la cosa per lavoro (è un linguaggio di scripting e di grassi diteggiatura nomi di variabile è catturato solo con l'unità di prova).MA, una volta che si ottiene il lavoro, la superficie di heisenbugs -- strani problemi che si manifestano solo una volta in un milione di corse -- che la superficie è solo molto molto più basso.Le tasse di scrittura Node.js codice pesantemente caricato frontalmente in fase di codifica.Quindi si tende a finire in stabile di codice.
  • Pro:JavaScript è molto più leggero per esprimere la funzionalità.È difficile dimostrare questo con le parole, ma JSON, la tipizzazione dinamica, lambda notazione, ereditarietà prototipale, leggero moduli, qualunque cosa ...si tende a prendere meno codice per esprimere le stesse idee.
  • Con:Forse davvero, davvero, come la codifica di servizi in Java?

Per un altro punto di vista su JavaScript e Node.js, check-out Da Java per Node.js, un post sul blog di un Java developer impressioni ed esperienze di apprendimento Node.js.


I moduli Quando si considera il nodo, tenere a mente che la vostra scelta di librerie JavaScript sarà DEFINIRE la vostra esperienza.La maggior parte delle persone di utilizzare almeno due, un modello asincrono helper (Passo, Futures, Async), e un JavaScript zucchero modulo (Underscore.js).

Helper / JavaScript Zucchero:

  • Underscore.js - utilizzare questo.Basta farlo.Rende il codice bello e leggibile con roba come _.èstringa () e _.isArray().Io non sono davvero sicuro di come si potrebbe scrivere il codice di sicurezza che in caso contrario.Inoltre, per una maggiore riga di comando-fu, controllare la mia Underscore-CLI.

Modello Asincrono Moduli:

  • Passo - un modo molto elegante per esprimere combinazioni di serie e in parallelo le azioni.La mia personale raccomandazione.Vedere il mio post in quale Passaggio codice simile.
  • Futures - molto più flessibile (è davvero una buona cosa?) modo per esprimere l'ordinamento attraverso i requisiti.Può esprimere cose come "start a, b, c in parallelo.Quando A e B finitura, start AB.Quando A, e C finire, start AC." Tale flessibilità richiede una maggiore cura per evitare gli errori del vostro flusso di lavoro (come mai chiama il callback o chiamando più volte).Vedere Raynos post sull'utilizzo di futures (questo è il post che mi ha fatto "get" futures).
  • Async - più tradizionale libreria con un metodo per ogni modello.Ho iniziato con questo prima della mia conversione religiosa di e successiva fase di realizzazione che tutti i modelli in Async potrebbe essere espressa nel Passo, con un singolo più leggibile paradigma.
  • TameJS - Scritto da OKCupid, è un precompilatore che aggiunge una nuova lingua primative "in attesa" per l'eleganza della scrittura seriale e flussi di lavoro paralleli.Il modello sembra incredibile, ma non necessita di pre-compilazione.Sto ancora facendo la mia mente su questo.
  • StreamlineJS - concorrente TameJS.Sto appoggiato verso Domare, ma si può rendere la vostra propria mente.

O di leggere tutte le asincrona librerie, vedere questo pannello-intervista con gli autori.

Framework Per Il Web:

  • Express Grande Ruby on Rails-esk quadro per l'organizzazione di siti web.Utilizza GIADA come XML/HTML template engine, il che rende la costruzione di HTML molto meno doloroso, quasi elegante anche.
  • jQuery Pur non essendo tecnicamente un nodo modulo, jQuery sta rapidamente diventando uno standard de-facto per il lato client di interfaccia utente.jQuery fornisce CSS-come selettori 'query' per insiemi di elementi del DOM, che può quindi essere azionato on (impostazione gestori di proprietà, stili, ecc).Lungo la stessa linea, Twitter Bootstrap Framework CSS, Backbone.js per un MVC modello, e Browserify.js per punto tutti i tuoi file JavaScript in un file singolo.Questi moduli sono tutti diventando standard de-facto modo si dovrebbe almeno controllare se non avete sentito parlare di loro.

Test:

  • JSHint - Deve utilizzare;Non ho usato questo in un primo momento, che ora sembra incomprensibile.JSLint aggiunge un po ' di base di verifiche che si ottiene con un linguaggio compilato come Java.Le parentesi non corrispondenti, variabili non dichiarate, typeos di diverse forme e dimensioni.È anche possibile attivare varie forme di quello che io chiamo "anale" modalità in cui si verifica lo stile di spazi e quant'altro, che è OK, se è la vostra tazza di tè, ma il valore reale viene da ottenere un feedback immediato sull'esatto numero di riga in cui si è dimenticato di una chiusura ")" ...senza dover eseguire il codice e colpire la riga incriminata."JSHint" è più configurabile variante di Douglas Crockford's JSLint.
  • Moka concorrente di Voti che sto iniziando a preferire.Entrambi i quadri gestire le nozioni di base abbastanza bene, ma i modelli complessi tendono ad essere più facile esprimere in Moka.
  • Voti Voti è davvero molto elegante.E viene stampato un bel report (--spec) mostrando che i casi di test passato / fallito.Trascorrere 30 minuti di apprendimento, e non è possibile creare test di base per i moduli con il minimo sforzo.
  • Zombie - Headless test per HTML e JavaScript utilizzando JSDom come un virtuale "browser".Molto roba potente.Combinare con Replay per ottenere un fulmine veloce deterministico test in codice del browser.
  • Un commento sul modo di "pensare" il test:
    • Il test non è opzionale.Con un linguaggio dinamico come il JavaScript, ci sono molto pochi statico controlli.Per esempio, passando due parametri di un metodo che prevede 4 non rompere fino a quando il codice viene eseguito.Piuttosto bassa, bar per la creazione di bug in JavaScript.Test di base sono essenziali per rendere la verifica gap con i linguaggi compilati.
    • Dimenticate la convalida, basta mettere il codice in esecuzione.Per ogni metodo, il mio primo convalida caso è "nulla si rompe", e che è il caso che spara più spesso.Dimostrando che il codice viene eseguito, senza buttare catture 80% dei bug e fare tanto per migliorare il vostro codice di fiducia che ti trovi andando avanti e aggiungere le sfumature di convalida dei casi è saltato.
    • Iniziare in piccolo e rompere l'inerzia della barriera.Siamo tutti pigri, e premuto per tempo, ed è facile vedere il test come "lavoro extra".Quindi, iniziare in piccolo.Scrittura test case 0 - caricare il vostro modulo e di rapporto di successo.Se si forza a voi stessi di fare proprio questo, quindi inerziale barriera di test è rotto.Che <30 min per fare la tua prima volta, tra cui la lettura della documentazione.Ora, scrittura test case 1 - chiamare uno dei vostri metodi e verificare "nulla si rompe", che è, che non si ottiene un errore.Test case 1 dovrebbe prendere meno di un minuto.Con l'inerzia andato, diventa facile incrementale di espandere la copertura del test.
    • Ora fai evolvere il tuo test con il tuo codice.Non ottenere intimidito da ciò che il "corretto" end-to-end di test sarebbe simile con finto server e tutti che.Codice di avvio semplice e si evolve per gestire i nuovi casi;i test devono essere troppo.Come aggiungere nuovi casi e nuove complessità al codice, aggiungere i casi di test per esercitare il nuovo codice.Come trovare i bug, aggiungere le verifiche e / o di nuovi casi per coprire la cattiva codice.Quando si esegue il debug e la perdita di fiducia in un pezzo di codice, tornare indietro e aggiungere le prove per dimostrare che si sta facendo quello che pensi tu.Acquisire stringhe di dati di esempio (altri servizi di chiamata, siti web, raschiare, a prescindere) e nutrirli con il codice di analisi.Un paio di casi qui, una migliore convalida lì, e alla fine si avrà altamente affidabili codice.

Inoltre, controllare il elenco ufficiale consigliate Node.js i moduli.Tuttavia, GitHub Nodo Moduli Wiki è molto più completo e una buona risorsa.


Per capire Nodo, è utile prendere in considerazione alcuni dei principali scelte progettuali:

Node.js è EVENTO IN BASE e ASINCRONA / NON-BLOCKING.Eventi come l'arrivo di una connessione HTTP fuoco spento una funzione JavaScript che fa un po ' di lavoro e il kick-off di altre attività asincrone come la connessione a un database o tirando il contenuto da un altro server.Una volta che queste attività sono stati cacciati fuori, la funzione di evento finiture e Node.js torna a dormire.Non appena succede qualcos'altro, come la connessione al database in corso o è il server esterno di rispondere con i contenuti, le funzioni di callback fuoco, e più il codice JavaScript viene eseguito, potenzialmente calci fuori ancora di più attività asincrone (come una query nel database).In questo modo, Node.js sarà lieto di interleave attività per più flussi di lavoro paralleli, l'esecuzione di qualsiasi attività sbloccato in qualsiasi punto nel tempo.Questo è il motivo per cui Node.js fa un ottimo lavoro nella gestione di migliaia di connessioni simultanee.

Perché non usare uno di processo/thread per ogni connessione, come tutti gli altri? In Node.js con una nuova connessione è solo una piccola allocazione heap.Girando un nuovo processo richiede molta più memoria, un megabyte su alcune piattaforme.Ma il costo reale è l'overhead associato con il contesto di commutazione.Quando si dispone di 10^6 thread del kernel, il kernel ha a che fare un sacco di lavoro di capire chi deve fare il prossimo.Un sacco di lavoro è andato nella costruzione di un scheduler O(1) per Linux, ma alla fine, è solo un modo più efficiente di avere un evento singolo processo guidato di 10^6 processi che competono per il tempo di CPU.Inoltre, in condizioni di sovraccarico, il multi-modello di processo funziona molto male, morendo di fame, critica l'amministrazione e la gestione di servizi, in particolare SSHD (nel senso che non si può nemmeno accedere alla casella di capire come avvitato è davvero).

Node.js è SINGOLO THREAD e BLOCCO LIBERO.Node.js, come una deliberata scelta di design dispone di un unico thread per processo.A causa di questo, è fondamentalmente impossibile per più thread per accedere ai dati contemporaneamente.Così, serrature sono necessari.I thread sono difficili.Davvero davvero difficile.Se non ci crediamo, non hai fatto abbastanza filettato di programmazione.Ottenere il blocco di destra è difficile e i risultati bug che sono davvero difficili da rintracciare.Eliminando i blocchi e multi-threading rende una delle peggiori classi di bug solo andare via.Questo potrebbe essere il singolo più grande vantaggio di nodo.

Ma come faccio a sfruttare il mio 16 core box?

In due modi:

  1. Per grande e pesante calcolare compiti come la codifica delle immagini, Node.js può sparare processi secondari o inviare messaggi ad ulteriori processi di lavoro.In questo disegno, sarebbe un thread di gestione del flusso di eventi e di N processi facendo pesante calcolare compiti e masticare il 15 per Cpu.
  2. Per la scalatura velocità di trasmissione in una webservice, si dovrebbe eseguire più Node.js i server su un box, uno per core, utilizzando cluster (Con Node.js v0.6.x, l'ufficiale di "cluster" modulo qui legata sostituisce il learnboost versione che ha diverse API).Questi locali Node.js i server possono quindi competere su un socket, di accettare nuove connessioni, il bilanciamento del carico tra di loro.Una volta che la connessione viene accettata, diventa strettamente legata a uno solo di questi processi condivisi.In teoria, questo suona male, ma in pratica funziona molto bene e permette di evitare il mal di testa di scrivere un codice thread-safe.Inoltre, questo significa che Node.js ottiene un'ottima CPU cache di affinità, in modo più efficace utilizzando la larghezza di banda di memoria.

Node.js permette di fare alcune cose davvero potente senza rompere un sudore. Si supponga di avere un Node.js programma che esegue una serie di compiti, in ascolto su una TCP porta per i comandi, codifica di alcune immagini, qualunque sia.Con cinque righe di codice, è possibile aggiungere in un HTTP di gestione web portale che mostra lo stato corrente delle attività in corso.Questo è FACILE da fare:

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end(myJavascriptObject.getSomeStatusInfo());
}).listen(1337, "127.0.0.1");

Ora si può colpire un URL e controllare lo stato del processo in esecuzione.Aggiungere un paio di pulsanti, e si dispone di un "portale di gestione".Se si dispone di un esecuzione di Perl / Python / Ruby script, basta "gettare un portale di gestione" non è esattamente semplice.

Ma non è JavaScript lento / cattivo / male / spawn-di-il-diavolo? JavaScript ha delle strane stranezze, ma con "parti buone" c'è un linguaggio molto potente, e in ogni caso, JavaScript è IL linguaggio del client (browser).JavaScript è qui per rimanere;altre lingue sono di targeting come IL, e il talento di classe mondiale è in competizione per produrre i più avanzati motori JavaScript.A causa di JavaScript ruolo nel browser, una quantità enorme di sforzo di ingegneria è stata generata a rendere JavaScript velocissimo. V8 è l'ultima e più grande motore javascript, almeno per questo mese.Soffia via l'altro linguaggi di scripting in termini di efficienza E di stabilità (guardando a voi, Rubino).Ed è solo andando a stare meglio con enorme team di lavoro sul problema, Microsoft, Google e Mozilla, che competono per costruire il miglior motore JavaScript (non È più un JavaScript "interprete", come tutti i moderni motori di tonnellate di JIT compilare sotto il cofano con l'interpretazione solo come ripiego per eseguire una volta che il codice).Sì, noi tutti ci auguriamo si potrebbe risolvere alcuni dei più strano linguaggio JavaScript scelte, ma in realtà non è così male.E la lingua è così maledettamente flessibile che non siete veramente il codice JavaScript, la codifica Passo o jQuery-più di qualsiasi altra lingua, in JavaScript, le librerie di definire l'esperienza.Per la creazione di applicazioni web, è praticamente necessario conoscere JavaScript in ogni caso, quindi la codifica con il server ha una sorta di insieme di abilità sinergia.Mi ha fatto non temono la scrittura di codice client.

Inoltre, se DAVVERO odio JavaScript, è possibile utilizzare zucchero sintattico " come CoffeeScript.O qualsiasi altra cosa che crea il codice JavaScript, come Google Web Toolkit (GWT).

Parlando di JavaScript, che cosa è una "chiusura"? Praticamente un modo carino per dire che si mantengono a livello lessicale ambito variabili per chiamare catene.;) Come questo:

var myData = "foo";
database.connect( 'user:pass', function myCallback( result ) {
    database.query("SELECT * from Foo where id = " + myData);
} );
// Note that doSomethingElse() executes _BEFORE_ "database.query" which is inside a callback
doSomethingElse();

Vedere come è possibile utilizzare solo "personali" senza fare nulla di imbarazzante come li esportavano in un oggetto?E, a differenza di Java, il "personali" variabile non deve essere di sola lettura.Questo potente linguaggio caratteristica rende asincrono-programmazione molto meno dettagliata e meno doloroso.

Scrittura di codice asincrono sta andando sempre essere più complesso che scrivere un semplice single-threaded script, ma con Node.js non è molto più duro e ottenere un sacco di vantaggi, oltre che per l'efficienza e la scalabilità di migliaia di connessioni simultanee...

V8 è un'implementazione di JavaScript. Esso consente di eseguire applicazioni JavaScript standalone (tra le altre cose).

Node.js è semplicemente una libreria scritta per V8 che fa evented I / O. Questo concetto è un po 'più complicato da spiegare, e sono sicuro che qualcuno risponderà con una spiegazione migliore di me ... Il succo è che, piuttosto che fare un po' di ingresso o uscita e in attesa che accada, basta Don 't aspettare che finisca. Così, per esempio, chiedere per l'ultima volta a cura di un file:

// Pseudo code
stat( 'somefile' )

Questo potrebbe prendere un paio di millesimi di secondo, o potrebbe prendere secondi. Con I / O basta sparare la richiesta e invece di aspettare che vi circonda allegare un callback che viene eseguita quando la richiesta termina:

// Pseudo code
stat( 'somefile', function( result ) {
  // Use the result here
} );
// ...more code here

In questo modo è un po 'come codice JavaScript nel browser (ad esempio, con Ajax funzionalità stile ).

Per ulteriori informazioni, si dovrebbe verificare l'articolo Node.js è veramente emozionante , che è stata la mia introduzione alla biblioteca / piattaforma di ... ho trovato abbastanza buono.

Node.js è uno strumento a riga di comando open source costruito per il lato server codice JavaScript. È possibile scaricare una tarball , compilare e installare la fonte. Esso consente di eseguire programmi JavaScript.

Il codice JavaScript viene eseguito dal V8 , un motore JavaScript sviluppato da Google che viene utilizzato in Chrome browser. Esso utilizza un'API JavaScript per accedere al sistema di rete e dei file.

E 'famoso per le sue prestazioni e la capacità di eseguire operazioni in parallelo.

  

node.js Capire è il migliore spiegazione di node.js ho trovato finora.

Di seguito sono riportati alcuni buoni articoli sul tema.

  

Le chiusure sono un modo per eseguire codice nel contesto è stato creato in.

Che cosa questo significa per concurency è che si può definire variabili, quindi avviare una I / O la funzione , e inviarlo una funzione anonima per la sua richiamata.

Quando l'attività è stata completata, la funzione di callback eseguirà nel contesto con le variabili, questa è la chiusura.

La ragione per cui le chiusure sono così buone per scrivere applicazioni con non-blocking I / O è che è molto facile da gestire nel contesto di esecuzione di funzioni in modo asincrono.

Due buoni esempi sono per quanto riguarda il modo di gestire i modelli e utilizzare i miglioramenti progressivi con esso. Hai solo bisogno di un paio di pezzi leggeri di codice JavaScript per farlo funzionare perfettamente.

Vi consiglio vivamente di guardare e leggere questi articoli:

Pick up qualsiasi lingua e cercare di ricordare come si dovrebbe gestire i modelli di file HTML e quello che si doveva fare per aggiornare un singolo CSS nome di classe nella tua DOM struttura (per esempio, un utente cliccato su una voce di menu e si desidera che ha segnato come "selezionato" e aggiornare il contenuto della pagina).

Con Node.js esso è semplice come farlo in lato client codice JavaScript. Ottieni il tuo nodo DOM e applicare la classe CSS a questo. Ottenere il vostro nodo DOM e innerHTML suo sito web (avrete bisogno di un po 'di codice JavaScript aggiuntivo per fare questo. Leggi l'articolo per saperne di più).

Un altro buon esempio, è che si può rendere la vostra pagina web compatibile sia con JavaScript attivata o disattivata con lo stesso pezzo di codice. Immaginate di avere una selezione data effettuato in JavaScript che permetterebbe agli utenti di prendere qualsiasi data con un calendario. È possibile scrivere (o utilizzare) lo stesso pezzo di codice JavaScript per farlo funzionare con il tuo JavaScript attivata o disattivata.

C'è un ottimo fast food posto analogia che meglio spiega il modello event-driven di Node.js, vedere l'articolo completo, Node.js, uffici e ristoranti fast food del medico - comprensione programmazione event-driven

Ecco un riassunto:

  

Se il fast food congiunta ha seguito un modello tradizionale basato sui thread, devi ordinare il vostro cibo e attendere in linea fino a quando l'avete ricevuto. La persona dietro di te non sarebbe in grado di ordinare fino a quando l'ordine è stato fatto. In un modello event-driven, si ordina il cibo e poi uscire dalla linea di aspettare. Tutti gli altri sono poi liberi di ordinare.

Node.js è event-driven, ma la maggior parte dei server web sono thread-based.York spiega come funziona Node.js:

  • Si utilizza il browser Web per effettuare una richiesta di "/about.html" su un web server Node.js.

  • Il server Node.js accetta la richiesta e richiama una funzione per recuperare tale file dal disco.

  • Mentre i Node.js server è in attesa per il file da recuperare, si servizi la richiesta successiva web.

  • Quando il file viene recuperato, v'è una funzione di callback che è inserito nella coda server Node.js.

  • Il server esegue Node.js quella funzione che in questo caso sarebbe il rendering della pagina "/about.html" e inviarlo di nuovo al vostro browser web ".

Bene, Capisco che

  
      
  • L'obiettivo di nodo è quello di fornire un modo semplice   costruire programmi di rete scalabili.
  •   
  • Il nodo è simile nel design al e influenzato da sistemi come macchina Evento di Ruby o ritorto di Python.
  •   
  • Evented I / O per JavaScript V8.
  •   

Per me questo significa che sei stato corretto in tutte e tre le ipotesi. La biblioteca sembra certo promettente!

Inoltre, non dimenticare di dire che V8 di Google è molto veloce. In realtà converte il codice JavaScript in codice macchina con le prestazioni abbinate di binario compilato. Quindi, insieme a tutte le altre grandi cose, è follemente veloce.

D: Il modello di programmazione è event driven, in particolare il modo in cui gestisce href="http://en.wikipedia.org/wiki/Input/output" I / O .

Una corretta. Esso utilizza call-back, in modo che qualsiasi richiesta di accedere al file system causerebbe una richiesta da inviare al file system e quindi Node.js sarebbe avviare l'elaborazione della sua prossima richiesta. Sarebbe preoccuparsi solo la richiesta di I / O, una volta che ottiene una risposta indietro dal file system, momento in cui verrà eseguito il codice di callback. Tuttavia, è possibile effettuare richieste di I / O sincrone (cioè, bloccando le richieste). Spetta allo sviluppatore di scegliere tra asincrone (callback) o sincrona (in attesa).

D: Esso utilizza Javascript e il parser è V8

.

Si

D:. Può essere facilmente utilizzato per creare applicazioni server concorrenti

Sì, anche se avresti bisogno di mano il codice di un bel po 'di JavaScript. Esso potrebbe essere migliore di guardare un quadro, come ad esempio http://www.easynodejs.com/ - che viene fornito con documentazione completa on-line e un'applicazione di esempio.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top