Come decidere quando utilizzare Node.js?


2195

Sono nuovo di questo genere di cose, ma ultimamente ho sentito molto su quanto è buono Node.js è. Considerando quanto mi piace lavorare con jQuery e JavaScript in generale, non posso fare a meno di chiedermi come decidere quando utilizzare Node.js. L'applicazione web che ho in mente è qualcosa come Bitly : prende del contenuto, lo archivia.

Da tutti i compiti che ho svolto negli ultimi giorni, ho ottenuto le seguenti informazioni. Node.js

  • è uno strumento da riga di comando che può essere eseguito come un normale server Web e consente di eseguire programmi JavaScript
  • utilizza l'ottimo motore JavaScript V8
  • è molto utile quando devi fare diverse cose contemporaneamente
  • è basato su eventi, quindi tutte le meravigliose cose simili ad Ajax possono essere fatte sul lato server
  • ci consente di condividere il codice tra il browser e il backend
  • parliamo con MySQL

Alcune delle fonti che ho incontrato sono:

Considerando che Node.js può essere eseguito quasi immediatamente nelle istanze EC2 di Amazon , sto cercando di capire che tipo di problemi richiedono Node.js rispetto a uno dei potenti re là fuori come PHP , Python e Ruby . Capisco che dipende davvero dall'esperienza che uno ha su una lingua, ma la mia domanda rientra maggiormente nella categoria generale di: Quando utilizzare un determinato framework e per quale tipo di problemi è particolarmente adatto?


4
Questa domanda è in discussione su meta ( meta.stackoverflow.com/q/332386/497418 ).
zzzzBov,

Risposte:


1355

Hai fatto un ottimo lavoro nel riassumere ciò che è fantastico di Node.js. La mia sensazione è che Node.js sia particolarmente adatto per le applicazioni in cui si desidera mantenere una connessione persistente dal browser al server. Utilizzando una tecnica nota come "polling lungo" , è possibile scrivere un'applicazione che invia aggiornamenti all'utente in tempo reale. Fare lunghi sondaggi su molti dei giganti del web, come Ruby on Rails o Django , creerebbe un carico immenso sul server, poiché ogni client attivo consuma un processo server. Questa situazione equivale a un attacco tarpit . Quando usi qualcosa come Node.js, il server non ha bisogno di mantenere thread separati per ogni connessione aperta.

Ciò significa che è possibile creare un'applicazione di chat basata su browser in Node.js che non richiede quasi risorse di sistema per servire molti client. Ogni volta che vuoi fare questo tipo di polling lungo, Node.js è un'ottima opzione.

Vale la pena ricordare che Ruby e Python hanno entrambi gli strumenti per fare questo genere di cose ( eventmachine e twisted , rispettivamente), ma che Node.js lo fa eccezionalmente bene e da zero . JavaScript è eccezionalmente ben posizionato in un modello di concorrenza basato su callback ed eccelle qui. Inoltre, essere in grado di serializzare e deserializzare con JSON nativo sia per il client che per il server è piuttosto ingegnoso.

Non vedo l'ora di leggere altre risposte qui, questa è una domanda fantastica.

Vale la pena sottolineare che Node.js è ottimo anche per le situazioni in cui riutilizzerai molto codice nell'intervallo client / server. Il framework Meteor rende tutto molto semplice e molte persone suggeriscono che questo potrebbe essere il futuro dello sviluppo web. Posso dire per esperienza che è molto divertente scrivere codice in Meteor, e gran parte di questo è passare meno tempo a pensare a come ristrutturare i dati, quindi il codice che viene eseguito nel browser può facilmente manipolarlo e passarlo indietro.

Ecco un articolo su Pyramid e Long Polling, che risulta molto semplice da configurare con un piccolo aiuto da parte di Gevent: TicTacToe e Long Polling con Pyramid .


12
Sì, penso che sia molto importante pensare che 'node.js sia particolarmente adatto per le applicazioni che richiedono una connessione persistente dal browser al server. - come programmi di chat o giochi interattivi "Se si sta semplicemente costruendo un'applicazione che non necessita necessariamente della comunicazione utente / server, lo sviluppo con altri framework andrebbe bene e richiederebbe molto meno tempo.
user482594,

1
Grazie per questo ... Ottimo Q e A ;-) Ci penserei anche in termini di padronanza di una grande tecnologia per lo sviluppo sia del front-end che del back-end su alcune diverse;)
Stokedout

12
Perché usare il polling lungo? Che cosa è successo al futuro e ai socket ?
Hitautodestruct,

1
La mia breve risposta è un processo in background. La richiesta e la risposta (compresa l'API di riposo) possono essere ottenute con qualsiasi altra lingua e server. Quindi, per coloro che stanno pensando di convertire i loro progetti web nel nodo. Ripensaci è la stessa cosa! Usa il nodo come processo in background come leggere e-mail con imap, elaborazione di immagini, caricamento di file su cloud o qualsiasi processo lungo o infinito che sia principalmente orientato agli eventi ...
Vikas

409

Credo che Node.js sia più adatto per applicazioni in tempo reale: giochi online, strumenti di collaborazione, chat room o qualsiasi cosa in cui un utente (o robot? O sensore?) Faccia con l'applicazione che deve essere visto immediatamente dagli altri utenti, senza un aggiornamento della pagina.

Devo anche menzionare che Socket.IO in combinazione con Node.js ridurrà la latenza in tempo reale anche oltre ciò che è possibile con il polling lungo. Socket.IO riporterà al polling lungo come scenario peggiore e utilizzerà invece i socket Web o anche Flash se disponibili.

Ma dovrei anche menzionare che qualsiasi situazione in cui il codice potrebbe bloccarsi a causa dei thread può essere affrontata meglio con Node.js. O qualsiasi situazione in cui è necessario che l'applicazione sia guidata dagli eventi.

Inoltre, Ryan Dahl ha dichiarato in una conferenza che una volta ho partecipato al fatto che i benchmark di Node.js sono strettamente in concorrenza con Nginx per le vecchie richieste HTTP. Quindi, se costruiamo con Node.js, possiamo servire le nostre normali risorse in modo abbastanza efficace e quando abbiamo bisogno delle cose guidate dagli eventi, è pronto per gestirle.

Inoltre è sempre JavaScript. Lingua Franca su tutto lo stack.


17
Solo un'osservazione da parte di qualcuno che passa da .Net a Node, Le diverse lingue per le diverse aree del sistema aiutano molto nel cambio di contesto. Quando guardo Javascript, sto lavorando nel client, C # significa l'App Server, SQL = database. Lavorando in Javascript, mi sono ritrovato a confondere i livelli o semplicemente a impiegare più tempo a cambiare contesto. Questo è probabilmente un artefatto di lavorare sullo stack .NET tutto il giorno e Noding di notte, ma fa la differenza.
Michael Blackburn,

9
È interessante notare che la pratica di individui interculturali che cambiano dialetti quando si spostano tra le culture tradizionali e quelle native è chiamata "commutazione di codice".
Michael Blackburn,

1
Proprio l'altro giorno stavo pensando a come potrei fare per assegnare colori diversi ai miei diversi .jsfile in qualche modo. Verde per lato client, blu per lato server. Continuo a "perdersi" me stesso.
AJB,

209

Motivi per utilizzare NodeJS:

  • Esegue Javascript, quindi è possibile utilizzare la stessa lingua su server e client e persino condividere un po 'di codice tra loro (ad esempio per la convalida del modulo o per eseguire il rendering delle visualizzazioni alle due estremità).

  • Il sistema basato su eventi a thread singolo è veloce anche quando si gestiscono molte richieste contemporaneamente e anche semplice, rispetto ai tradizionali framework multi-thread Java o ROR.

  • Il pool sempre crescente di pacchetti accessibili tramite NPM , comprese le librerie / i moduli client e lato server, nonché gli strumenti da riga di comando per lo sviluppo Web. La maggior parte di questi sono comodamente ospitati su github, dove a volte puoi segnalare un problema e trovarlo risolto in poche ore! È bello avere tutto sotto lo stesso tetto, con reportistica standardizzata e facile biforcazione.

  • È diventato l'ambiente standard defacto in cui eseguire strumenti correlati a Javascript e altri strumenti correlati al Web , inclusi runner, minificatori, abbellitori, linter, preprocessori, bundler e processori di analisi.

  • Sembra abbastanza adatto per prototipazione, sviluppo agile e iterazione rapida del prodotto .

Motivi per non usare NodeJS:

  • Esegue Javascript, che non ha alcun controllo del tipo in fase di compilazione. Per sistemi o progetti critici per la sicurezza di grandi dimensioni e complessi , inclusa la collaborazione tra diverse organizzazioni, un linguaggio che incoraggi le interfacce contrattuali e fornisca il controllo statico del tipo può farti risparmiare tempo (ed esplosioni ) di debug nel lungo periodo. (Anche se la JVM è bloccata null, quindi per favore usa Haskell per i tuoi reattori nucleari.)

  • Aggiunto a ciò, molti dei pacchetti in NPM sono un po ' grezzi e ancora in rapido sviluppo. Alcune librerie per vecchi framework hanno subito un decennio di test e correzione di errori, e sono ormai molto stabili . Npmjs.org non ha alcun meccanismo per valutare i pacchetti , il che ha portato a una proliferazione di pacchetti che fanno più o meno la stessa cosa, di cui una grande percentuale non viene più mantenuta.

  • Inferno di callback nidificato. (Naturalmente ci sono 20 diverse soluzioni a questo ...)

  • Il pool sempre crescente di pacchetti può far apparire un progetto NodeJS radicalmente diverso dal successivo. Vi è una grande diversità nelle implementazioni a causa dell'enorme numero di opzioni disponibili (ad esempio Express / Sails.js / Meteor / Derby ). Questo a volte può rendere più difficile per un nuovo sviluppatore entrare in un progetto Node. Contrastalo con uno sviluppatore di Rails che si unisce a un progetto esistente: dovrebbe essere in grado di familiarizzare con l'app abbastanza rapidamente, perché tutte le app di Rails sono incoraggiate a utilizzare una struttura simile .

  • Gestire i file può essere un po 'una seccatura. Cose che sono banali in altre lingue, come leggere una riga da un file di testo, sono abbastanza strane da fare con Node.js che c'è una domanda StackOverflow su questo con oltre 80 voti. Non esiste un modo semplice per leggere un record alla volta da un file CSV . Eccetera.

Adoro NodeJS, è veloce, selvaggio e divertente, ma temo che abbia scarso interesse per la correttezza dimostrabile. Speriamo di poter finalmente fondere il meglio di entrambi i mondi. Sono ansioso di vedere cosa sostituirà Node in futuro ... :)


1
@nane Sì, penso che possano risolvere questo problema, tuttavia devi limitarti a utilizzare solo librerie scritte in linguaggi di tipo tipografico o accettare che non tutte le tue basi di codice siano tipizzate staticamente. Ma un argomento va: dal momento che dovresti scrivere buoni test per il tuo codice indipendentemente dalla lingua, il tuo livello di confidenza dovrebbe essere uguale anche per il codice digitato in modo dinamico. Se accettiamo tale argomento, i vantaggi della tipizzazione forte si riducono nell'aiutare il tempo di sviluppo / debugging, la provabilità e l' ottimizzazione .
joeytwiddle,

1
@kervin, sono d'accordo che alcuni parametri di riferimento sarebbero ottimi, ma sono rimasto deluso da ciò che ho potuto trovare online. Alcuni hanno sostenuto che le prestazioni di .NET sono paragonabili a quelle di Node, ma che è fondamentale ciò che si sta effettivamente facendo. Il nodo potrebbe essere ottimo nel recapitare piccoli messaggi con molte connessioni simultanee, ma non così grande per i calcoli matematici pesanti. Un buon confronto delle prestazioni dovrebbe testare una varietà di situazioni.
joeytwiddle,

2
@joeytwiddle cose come Typescript non aiuterebbero Node.js quando si tratta di gestire programmi complessi più grandi e il controllo statico dei caratteri?
CodeMonkey,

2
@joeytwiddle per quello che vale, puoi usare stillmaintained.com per determinare se un pacchetto npm è ancora mantenuto (dato che la maggior parte è su github). Inoltre, npm searche npm showti mostrerà la data dell'ultima versione di un pacchetto.
Dan Pantry,

3
Confrontando le rotaie con il nodo, confondi una piattaforma con un framework. Rails è un framework per Ruby proprio come Sails e meteor sono framework per Javascript.
BonsaiOak,


127

Ho un esempio del mondo reale in cui ho usato Node.js. La società in cui lavoro ha un cliente che voleva avere un semplice sito Web HTML statico. Questo sito Web è destinato alla vendita di un articolo tramite PayPal e il cliente voleva anche avere un contatore che mostra la quantità di articoli venduti. Il cliente prevede di avere un'enorme quantità di visitatori su questo sito Web. Ho deciso di creare il contatore utilizzando Node.js e il framework Express.js .

L'applicazione Node.js era semplice. Ottieni l'importo degli articoli venduti da un database Redis , aumenta il contatore quando l'articolo viene venduto e offri il valore del contatore agli utenti tramite l' API .

Alcuni motivi per cui ho scelto di utilizzare Node.js in questo caso

  1. È molto leggero e veloce. Sono state oltre 200000 le visite su questo sito Web in tre settimane e le risorse minime del server sono state in grado di gestire tutto.
  2. Il contatore è davvero facile da realizzare per essere in tempo reale.
  3. Node.js era facile da configurare.
  4. Ci sono molti moduli disponibili gratuitamente. Ad esempio, ho trovato un modulo Node.js per PayPal.

In questo caso, Node.js è stata una scelta fantastica.


7
Come ospiti qualcosa del genere? Allora devi configurare nodejs sul server di produzione? In Linux?
Miguel Stevens,

1
Ci sono alcuni PaaS come nodejitsu e Heroku. Oppure puoi davvero impostare nodejs su un box Linux, ad esempio da Amazon Ec2. vedi: lauradhamilton.com/…
harry young

13
200.000 visite entro 1.814.400 secondi. Per niente rilevante. Perfino bash potrebbe servire così tante richieste, sul server più lento. Scratch Server. VM più lenta.
Tiberiu-Ionuț Stan,

105

I motivi più importanti per iniziare il tuo prossimo progetto usando Node ...

  • Ci sono tutti i ragazzi più fighi ... quindi deve essere divertente.
  • Puoi passare il tempo davanti al dispositivo di raffreddamento e avere molte avventure di Node di cui vantarsi.
  • Sei un penny pincher quando si tratta di costi di cloud hosting.
  • Ci sono stato fatto con Rails
  • Odio le distribuzioni di IIS
  • Il tuo vecchio lavoro IT sta diventando piuttosto noioso e vorresti essere in una nuova brillante Start Up.

Cosa aspettarsi ...

  • Ti sentirai al sicuro con Express senza tutto il bloatware del server che non hai mai avuto bisogno.
  • Funziona come un razzo e si adatta bene.
  • Lo sogni. L'hai installato. Il pacchetto di nodi repo npmjs.org è il più grande ecosistema di librerie open source al mondo.
  • Il tuo cervello si deformerà il tempo nella terra dei richiami nidificati ...
  • ... finché non impari a mantenere le tue promesse .
  • Sequelize e Passport sono i tuoi nuovi amici API.
  • Il debugging per lo più di codice asincrono diventerà umm ... interessante .
  • Tempo per tutti i Noders di padroneggiare Typescript .

Chi lo usa?

  • PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
  • Ecco perché sono passati a Node .

18
Sì, avrei potuto rispondere a questa domanda in modo tradizionale. Penso di essere qualificato per farlo, ma la maggior parte è già stata detta e ho pensato che un divertimento spensierato avrebbe spezzato la monotonia. Fornisco regolarmente risposte tecniche su altre domande.
Tony O'Hagan,

1
i callback nidificati possono essere evitati usando i generatori ES6 per il codice asincrono
refactor

1
@CleanCrispCode: Sì davvero! ES6 ha adottato lo stile C # async/ awaitquindi ora possiamo implementare un codice Nodo asincrono molto più pulito che supporta anche il tradizionale try/ catch. Nel 2016/17 i programmatori JS stanno passando a ES6.
Tony O'Hagan,

1
diecimila volte questo "Ti sentirai al sicuro con Express senza tutto il bloatware del server che non hai mai avuto bisogno"
Simone Poggi,

60

Non c'è niente come Silver Bullet. Tutto ha un costo associato. È come se mangiassi cibi oleosi, comprometterai la tua salute e il cibo sano non verrà fornito con spezie come il cibo oleoso. È una scelta individuale se vogliono la salute o le spezie come nel loro cibo. Allo stesso modo Node.js considera di essere utilizzato in uno scenario specifico. Se la tua app non rientra in quello scenario non dovresti considerarla per lo sviluppo della tua app. Sto solo riflettendo sullo stesso:

Quando utilizzare Node.JS

  1. Se il codice lato server richiede pochissimi cicli di CPU. In un altro mondo si sta eseguendo un'operazione non bloccante e non si ha un algoritmo / lavoro pesante che consuma molti cicli della CPU.
  2. Se provieni da Javascript e ti senti a tuo agio nello scrivere un codice a thread singolo proprio come JS lato client.

Quando NON usare Node.JS

  1. La richiesta del server dipende da un pesante algoritmo / processo che consuma CPU.

Considerazione sulla scalabilità con Node.JS

  1. Node.JS stesso non utilizza tutti i core del sistema sottostante ed è a thread singolo per impostazione predefinita, devi scrivere la tua logica per utilizzare il processore multi core e renderlo multi-thread.

Node.JS Alternative

Esistono altre opzioni da utilizzare al posto di Node.JS, tuttavia Vert.x sembra essere abbastanza promettente e ha molte funzionalità aggiuntive come Polygot e considerazioni sulla scalabilità migliori.


24
Non sono sicuro che "Se la tua richiesta lato server includa operazioni di blocco come File IO o Socket IO" sia elencata in "Quando NON usare". Se la mia comprensione è giusta, uno dei punti di forza di node.js è che ha potenti mezzi asincroni per gestire l'IO senza bloccare. Quindi Node.js può essere visto come "una cura" per bloccare IO.
Ondrej Peterka,

3
@OndraPeterka: hai ragione sul fatto che Node.js è in grado di bloccare l'I / O del server, tuttavia se il gestore della richiesta sul server stesso sta effettuando una chiamata di blocco verso qualche altro servizio Web / Operazione file, Node.js non sarebbe di aiuto qui. Non blocca l'IO solo per le richieste in entrata al server ma non per le richieste in uscita dal gestore delle richieste dell'app.
Ajay Tiwari,

4
@ajay di nodejs.org dicono "I / O non bloccanti", si prega di controllare il "Quando NON" 2 e 3.
Omar Al-Ithawi,

5
con la versione corrente, il nodo supporta effettivamente il supporto multi-core usando il cluster. Questo aumenta davvero le prestazioni dell'app Node almeno due volte. Tuttavia, penso che le prestazioni dovrebbero essere più del doppio quando stabiliscono la lib del cluster.
Nam Nguyen,

4
Puoi usare node.js per un calcolo pesante. Usa fork. Vedi stackoverflow.com/questions/9546225/… . Il nodo gestisce molto più core con il clustermodulo. nodejs.org/api/cluster.html
Jess

41

Un'altra cosa grandiosa che penso che nessuno abbia menzionato su Node.js è la fantastica community, il sistema di gestione dei pacchetti (npm) e la quantità di moduli esistenti che puoi includere semplicemente includendoli nel tuo file package.json.


6
E questi pacchetti sono tutti relativamente nuovi, quindi hanno il senno di poi e tendono a conformarsi ai recenti standard web.
joeytwiddle,

3
Con tutto il rispetto, molti pacchetti su npm sono terribili, perché npm non ha un meccanismo per valutare i pacchetti . Col senno di poi CPAN qualcuno?
Dan Dascalescu,

peccato che nessuna delle librerie dei websocket sia in grado di soddisfare le specifiche della rfc 6455. I fan di node.js sono sordi, stupidi e ciechi quando viene indicato questo fatto.
r3wt

1
Non so quando hai fatto il commento, ma al momento la libreria ws supporta questa specifica
Jonathan Gray,

37

Il mio pezzo: nodejs è ottimo per creare sistemi in tempo reale come analisi, app di chat, API, server di annunci, ecc. Inferno, ho realizzato la mia prima app di chat usando nodejs e socket.io in meno di 2 ore e anche durante la settimana degli esami!

modificare

Sono passati diversi anni da quando ho iniziato a usare nodejs e l'ho usato per fare molte cose diverse tra cui file server statici, analisi semplici, app di chat e molto altro. Questa è la mia opinione su quando usare nodejs

Quando usare

Quando si crea un sistema che pone l'accento sulla concorrenza e sulla velocità.

  • Socket solo server come app di chat, app irc, ecc.
  • Social network che mettono l'accento su risorse in tempo reale come geolocalizzazione, flusso video, flusso audio, ecc.
  • Gestire piccoli blocchi di dati molto velocemente come una webapp di analisi.
  • Come esporre un REST solo api.

Quando non usare

È un server web molto versatile, quindi puoi usarlo dove vuoi, ma probabilmente non in questi luoghi.

  • Blog semplici e siti statici.
  • Proprio come un file server statico.

Tieni presente che sto solo scherzando. Per i file server statici, apache è meglio principalmente perché è ampiamente disponibile. La comunità nodejs è diventata più grande e più matura nel corso degli anni ed è sicuro di dire che nodejs può essere usato praticamente ovunque, se hai la tua scelta di hosting.


I blog semplici possono comunque beneficiare di Node.js. Per servire file statici, puoi comunque usare Node.js e se il carico aumenta, aggiungi semplicemente il proxy inverso Nginx di fronte ad esso, secondo le migliori pratiche attuali. Il server httpd di Apache è un dinosauro che sta morendo - vedi questo sondaggio Netcraft .
Endrju,

Direi altrimenti - dai un'occhiata a ghost.org , sembra fantastico e si basa su NodeJs - collaborazione, editing di articoli in tempo reale. Inoltre, creare una semplice pagina in NodeJs, ad esempio usando sailsjs.org , è facile, rapido e non devi preoccuparti di imparare nessuno dei linguaggi di programmazione lato server
Bery

30

Può essere usato dove

  • Applicazioni fortemente guidate dagli eventi e fortemente legate all'I / O
  • Applicazioni che gestiscono un gran numero di connessioni ad altri sistemi
  • Applicazioni in tempo reale (Node.js è stato progettato da zero per tempo reale e per essere facile da usare.)
  • Applicazioni che manipolano quantità di informazioni in streaming da e verso altre fonti
  • Alto traffico, applicazioni scalabili
  • App per dispositivi mobili che devono comunicare con l'API e il database della piattaforma, senza dover eseguire molte analisi dei dati
  • Costruisci applicazioni in rete
  • Applicazioni che devono parlare molto spesso con il back-end

Sul fronte mobile, le aziende in prima serata hanno fatto affidamento su Node.js per le loro soluzioni mobili. Scopri perché?

LinkedIn è un utente di spicco. Il loro intero stack mobile è basato su Node.js. Sono passati da 15 server con 15 istanze su ogni macchina fisica, a solo 4 istanze, in grado di gestire il doppio del traffico!

eBay ha lanciato ql.io, un linguaggio di query Web per le API HTTP, che utilizza Node.js come stack di runtime. Sono stati in grado di mettere a punto una normale workstation Ubuntu di qualità per sviluppatori per gestire più di 120.000 connessioni attive per processo node.js, con ciascuna connessione che consuma circa 2kB di memoria!

Walmart riprogettato la sua app mobile per utilizzare Node.js e ha inviato l'elaborazione JavaScript al server.

Maggiori informazioni su: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/


20

Nodo migliore per la gestione di richieste simultanee -

Quindi, cominciamo con una storia. Negli ultimi 2 anni sto lavorando su JavaScript e sviluppando il front-end Web e mi diverto. I ragazzi del back-end ci forniscono alcune API scritte in Java, Python (non ci interessa) e semplicemente scriviamo una chiamata AJAX, riceviamo i nostri dati e indovinate un po '! abbiamo chiuso. Ma in realtà non è così facile, se i dati che stiamo ottenendo non sono corretti o c'è qualche errore del server, allora siamo bloccati e dobbiamo contattare i nostri ragazzi del back-end tramite posta o chat (a volte anche su whatsApp :).) Questo non è bello. E se scrivessimo le nostre API in JavaScript e le chiamassimo dal nostro front-end? Sì, è piuttosto interessante perché se affrontiamo qualche problema nell'API, possiamo esaminarlo. Indovina un po ! puoi farlo ora, come? - Il nodo è lì per te.

Ok ho concordato che puoi scrivere la tua API in JavaScript, ma cosa succede se sto bene con il problema sopra. Hai altri motivi per utilizzare il nodo per l'API di riposo?

quindi ecco che inizia la magia. Sì, ho altri motivi per utilizzare il nodo per le nostre API.

Torniamo al nostro tradizionale sistema API di riposo che si basa sull'operazione di blocco o sul threading. Supponiamo che si verifichino due richieste simultanee (r1 e r2), ognuna di esse richiede il funzionamento del database. Quindi nel sistema tradizionale cosa accadrà:

1. Modo di attesa: il nostro server inizia a servire la r1richiesta e attende la risposta alla query. dopo il completamento di r1, il server inizia a servire r2e lo fa allo stesso modo. Quindi aspettare non è una buona idea perché non abbiamo molto tempo.

2. Modo di threading: il nostro server creerà due thread per entrambe le richieste r1e r2servirà al loro scopo dopo aver interrogato il database in modo così veloce e veloce. Ma consuma memoria perché puoi vedere che abbiamo avviato due thread, inoltre il problema aumenta quando entrambe le richieste richiedono gli stessi dati allora devi affrontare problemi di tipo deadlock. Quindi è meglio che aspettare ma ci sono ancora problemi.

Ora ecco come il nodo lo farà:

3. Nodeway: quando la stessa richiesta simultanea arriva nel nodo, registrerà un evento con il suo callback e andrà avanti non attenderà la risposta alla query per una particolare r1richiesta. Quindi quando la richiesta arriva, allora il ciclo degli eventi del nodo (sì, c'è un ciclo degli eventi nel nodo che serve a questo scopo.) registra un evento con la sua funzione di callback e vai avanti per servire la r2richiesta e allo stesso modo registra il suo evento con il suo callback. Ogni volta che una query termina, attiva l'evento corrispondente ed esegue il callback fino al completamento senza essere interrotto.

Quindi nessuna attesa, nessun threading, nessun consumo di memoria - sì, questo è il nodo per servire l'API di riposo.


1
Ciao Anshul. Puoi elaborare o suggerire alcune risorse su come potrebbe verificarsi un deadlock in modo threading.
jsbisht,

16

Il mio ulteriore motivo per scegliere Node.js per un nuovo progetto è:

Essere in grado di fare puro sviluppo basato su cloud

Ho usato Cloud9 IDE per un po 'e ora non riesco a immaginare senza di esso, copre tutti i cicli di vita dello sviluppo. Tutto ciò di cui hai bisogno è un browser e puoi scrivere codice in qualsiasi momento e ovunque su qualsiasi dispositivo. Non è necessario effettuare il check-in del codice in un computer (come a casa), quindi effettuare il check-out in un altro computer (come sul posto di lavoro).

Ovviamente, esiste forse un IDE basato su cloud per altre lingue o piattaforme (Cloud 9 IDE sta aggiungendo supporti anche per altre lingue), ma usare Cloud 9 per fare lo sviluppo di Node.js è davvero una grande esperienza per me.


1
In realtà Cloud9 IDE e gli altri (codificando quello che uso) supportano quasi tutti i tipi di linguaggio web.
Wanny Miarelli,

7
Sei un tipo serio? questo è il criterio per scegliere una pila? :) felice che funzioni per te!
matanster

15

Un'altra cosa che fornisce il nodo è la possibilità di creare più istani v8 del nodo usando il processo figlio del nodo ( childProcess.fork (), ciascuno dei quali richiede una memoria di 10 MB come da documenti) al volo, quindi non influendo sul processo principale che esegue il server. Quindi scaricare un lavoro in background che richiede un enorme carico del server diventa un gioco da ragazzi e possiamo facilmente ucciderli come e quando necessario.

Ho usato molto il nodo e nella maggior parte delle app che costruiamo, allo stesso tempo richiedono connessioni al server, quindi un intenso traffico di rete. Framework come Express.js e il nuovo Koajs (che ha rimosso l'inferno di callback) hanno reso il lavoro sul nodo ancora più semplice.


15

Indossare longjohns di amianto ...

Ieri il mio titolo con Packt Publications, Reactive Programming con JavaScript . Non è proprio un titolo centrato su Node.js; i primi capitoli hanno lo scopo di coprire la teoria, e in seguito i capitoli ricchi di codice coprono la pratica. Poiché non pensavo davvero che sarebbe stato opportuno non dare ai lettori un server web, Node.js sembrava di gran lunga la scelta più ovvia. Il caso è stato chiuso prima ancora che fosse aperto.

Avrei potuto dare una visione molto rosea della mia esperienza con Node.js. Invece sono stato onesto riguardo ai punti positivi e ai punti negativi che ho riscontrato.

Consentitemi di includere alcune citazioni rilevanti qui:

Attenzione: Node.js e il suo ecosistema sono caldi abbastanza --hot per bruciare male!

Quando ero un insegnante di matematica, uno dei suggerimenti non ovvi che mi era stato detto era di non dire a uno studente che qualcosa era "facile". La ragione era in qualche modo ovvia in retrospettiva: se dici alla gente che qualcosa è facile, qualcuno che non vede una soluzione potrebbe sentirsi (anche più) stupido, perché non solo non riescono a risolvere il problema, ma il problema sono troppo stupidi per capire è facile!

Ci sono gotcha che non solo infastidiscono le persone provenienti da Python / Django, che ricaricano immediatamente la fonte se cambi qualcosa. Con Node.js, il comportamento predefinito è che se si esegue una modifica, la versione precedente continua ad essere attiva fino alla fine dei tempi o fino a quando non si arresta e si riavvia manualmente il server. Questo comportamento inappropriato non infastidisce solo i pitonisti; inoltre irrita gli utenti nativi di Node.js che offrono varie soluzioni alternative. La domanda StackOverflow "Ricarica automatica dei file in Node.js" ha, al momento della stesura di questo documento, oltre 200 voti positivi e 19 risposte; una modifica indirizza l'utente a uno script tata, supervisore di nodi, con homepage a http://tinyurl.com/reactjs-node-supervisor. Questo problema offre ai nuovi utenti una grande opportunità di sentirsi stupidi perché pensavano di aver risolto il problema, ma il vecchio comportamento buggy è completamente invariato. Ed è facile dimenticare di far rimbalzare il server; L'ho fatto più volte. E il messaggio che vorrei dare è: “No, non sei stupido perché questo comportamento di Node.js ti ha morso la schiena; è solo che i progettisti di Node.js non hanno visto alcun motivo per fornire un comportamento appropriato qui. Prova ad affrontarlo, magari prendendo un piccolo aiuto dal supervisore dei nodi o un'altra soluzione, ma per favore non andartene sentendo di essere stupido. Non sei quello con il problema; il problema è nel comportamento predefinito di Node.js. "

Questa sezione, dopo qualche dibattito, è stata lasciata in sospeso, proprio perché non voglio dare l'impressione di "È facile". Mi sono tagliato le mani ripetutamente mentre facevo funzionare le cose, e non voglio smussare le difficoltà e farti credere che far funzionare bene Node.js e il suo ecosistema sia una cosa semplice e se non è semplice anche per te , non sai cosa stai facendo. Se non ti imbatti in difficoltà odiose usando Node.js, è meraviglioso. Se lo fai, spero che non ti allontani sentendo, "Sono stupido, ci deve essere qualcosa di sbagliato in me". Non sei stupido se provi brutte sorprese a che fare con Node.js. Non sei tu! È Node.js e il suo ecosistema!

L'Appendice, che non volevo davvero dopo il crescente crescendo negli ultimi capitoli e le conclusioni, parla di ciò che sono riuscito a trovare nell'ecosistema e ha fornito una soluzione alternativa al letterale idiota:

Un altro database che sembrava perfetto, e che può essere riscattabile, è un'implementazione lato server dell'archivio di valori-chiave HTML5. Questo approccio ha il vantaggio cardine di un'API che la maggior parte degli sviluppatori di front-end capisce abbastanza bene. Del resto, è anche un'API che la maggior parte degli sviluppatori di front-end non così bravi capisce abbastanza bene. Ma con il pacchetto node-localstorage, mentre l'accesso alla sintassi del dizionario non è offerto (si desidera utilizzare localStorage.setItem (chiave, valore) o localStorage.getItem (chiave), non localStorage [chiave]), viene implementata la semantica localStorage completa , inclusa una quota predefinita di 5 MB: PERCHÉ?Gli sviluppatori JavaScript sul lato server devono essere protetti da se stessi?

Per le capacità del database lato client, una quota di 5 MB per sito Web è davvero una quantità generosa e utile di respiro per consentire agli sviluppatori di lavorare con esso. Potresti impostare una quota molto più bassa e offrire comunque agli sviluppatori un miglioramento incommensurabile rispetto alla zoppicazione insieme alla gestione dei cookie. Un limite di 5 MB non si presta molto rapidamente all'elaborazione lato client di Big Data, ma esiste una tolleranza davvero generosa che gli sviluppatori intraprendenti possono usare per fare molto. D'altra parte, 5 MB non è una porzione particolarmente grande della maggior parte dei dischi acquistati di recente in qualsiasi momento, il che significa che se tu e un sito Web non siete d'accordo su ciò che è un uso ragionevole dello spazio su disco, o qualche sito è semplicemente noioso, non costa davvero tu e non corri il rischio di un disco rigido inondato a meno che il tuo disco rigido non sia già troppo pieno.

Tuttavia, è possibile sottolineare che quando si è l'unico codice di scrittura per il proprio server, non è necessaria alcuna protezione aggiuntiva dal rendere il database di dimensioni superiori a 5 MB tollerabili. La maggior parte degli sviluppatori non avrà bisogno né desidererà che gli strumenti agiscano da bambinaia e li proteggano dall'archiviazione di oltre 5 MB di dati lato server. E la quota di 5 MB che è un atto di bilanciamento dorato sul lato client è piuttosto sciocca su un server Node.js. (E, per un database per più utenti come descritto in questa appendice, si potrebbe sottolineare, leggermente dolorosamente, che non sono 5 MB per account utente a meno che non si crei un database separato su disco per ciascun account utente; sono 5 MB condivisi tra tutti gli account utente insieme. Ciò potrebbe ottenere dolorosose diventi virale!) La documentazione afferma che la quota è personalizzabile, ma un'email una settimana fa allo sviluppatore che chiede come modificare la quota non ha ricevuto risposta, così come la domanda StackOverflow che fa la stessa domanda. L'unica risposta che sono riuscito a trovare è nell'origine Github CoffeeScript, dove è elencato come secondo argomento intero facoltativo per un costruttore. Quindi è abbastanza facile e puoi specificare una quota uguale a una dimensione del disco o della partizione. Ma oltre a eseguire il porting di una funzionalità che non ha senso, l'autore dello strumento non è riuscito a seguire completamente una convenzione molto standard di interpretazione di 0 come significato "illimitato" per una variabile o funzione in cui un numero intero deve specificare un limite massimo per l'utilizzo di alcune risorse. La cosa migliore da fare con questa disfunzione è probabilmente specificare che la quota è Infinity:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

Scambiando due commenti in ordine:

Le persone si sono inutilmente sparate ai piedi usando costantemente JavaScript nel suo insieme e parte di JavaScript reso un linguaggio rispettabile era un Douglas Crockford che diceva in sostanza: “JavaScript come linguaggio ha alcune parti davvero buone e alcune parti davvero cattive. Ecco le parti buone. Dimentica che c'è qualcos'altro. " Forse l'ecosistema Node.js caldo farà crescere il proprio "Douglas Crockford", che dirà, "L'ecosistema Node.js è un selvaggio West codificante, ma ci sono alcune vere gemme da trovare. Ecco una tabella di marcia. Ecco le aree da evitare a quasi tutti i costi. Ecco le aree con alcuni dei più ricchi paydirt che si possono trovare in QUALSIASI lingua o ambiente. "

Forse qualcun altro può prendere quelle parole come una sfida e seguire l'esempio di Crockford e scrivere "le parti buone" e / o "le parti migliori" per Node.js e il suo ecosistema. Ne comprerei una copia!

E dato il grado di entusiasmo e le ore di lavoro puro per tutti i progetti, può essere giustificato in un anno, o due, o tre, per temperare bruscamente qualsiasi osservazione su un ecosistema immaturo fatta al momento della stesura di questo scritto. In cinque anni potrebbe essere logico affermare: “L'ecosistema Node.js 2015 aveva diversi campi minati. L'ecosistema Node.js del 2020 ha molteplici paradisi. "


9

Se l'applicazione utilizza principalmente web apis o altri canali io, fornisce o utilizza un'interfaccia utente, node.js può essere una scelta giusta per te, soprattutto se vuoi ottenere la massima scalabilità o, se la tua lingua principale nella vita è javascript (o sorta di transpilers javascript). Se si creano microservizi, anche node.js va bene. Node.js è adatto anche per qualsiasi progetto piccolo o semplice.

Il suo principale punto di forza è che consente ai front-end di assumersi la responsabilità delle cose di back-end piuttosto che della divisione tipica. Un altro punto di vendita giustificabile è se la tua forza lavoro è orientata javascript all'inizio.

Al di là di un certo punto, tuttavia, non è possibile ridimensionare il codice senza terribili hack per forzare la modularità, la leggibilità e il controllo del flusso. Ad alcune persone piacciono quegli hack, soprattutto se provengono da uno sfondo javascript guidato da eventi, sembrano familiari o perdonabili.

In particolare, quando l'applicazione deve eseguire flussi sincroni, si inizia a sanguinare su soluzioni semi-cotte che rallentano notevolmente in termini di processo di sviluppo. Se nella tua applicazione sono presenti parti ad uso intensivo di calcolo, procedere con cautela selezionando (solo) node.js. Forse http://koajs.com/ o altre novità alleviano quegli aspetti originariamente spinosi, rispetto a quando ho usato originariamente node.js o ho scritto questo.


3
Esistono molti approcci esistenti per il ridimensionamento delle applicazioni Node.js e non sembra fornire alcun riferimento in merito alle affermazioni "soluzioni semi-cotte", "hack terribili" e "API terribili". Ti stai espandendo su quelli?
Sven Slootweg

Lo lascio come un esercizio al lettore, ma è sufficiente esaminare le cosiddette soluzioni per il controllo del flusso.
matanster

2
Non è proprio una risposta. Sostieni che le soluzioni esistenti siano "terribili hack", ma non riesci a segnalarne nessuna. Hai considerato che potresti semplicemente non capire o essere a conoscenza dei metodi corretti per il ridimensionamento delle applicazioni Node.js?
Sven Slootweg,

Ho aggiornato un po 'la mia risposta. Forse hai ancora lamentele, ma se pensi che sia sbagliato dovresti commentare con i dettagli ... piuttosto che sottolineare una loro mancanza nella risposta. Sarebbe più produttivo per la comunità imo.
matanster

-2

Posso condividere alcuni punti su dove e perché usare il nodo js.

  1. Per applicazioni in tempo reale come la chat, l'editing collaborativo meglio andiamo con nodejs poiché è la base di eventi in cui si generano eventi e dati ai client dal server.
  2. Semplice e facile da capire in quanto è la base javascript dove la maggior parte delle persone ha idea.
  3. La maggior parte delle attuali applicazioni web vanno verso js e backbone angolari, con il nodo è facile interagire con il codice lato client poiché entrambi useranno i dati json.
  4. Molti plug-in disponibili.

Svantaggi: -

  1. Node supporterà la maggior parte dei database, ma la cosa migliore è mongodb che non supporterà join complessi e altri.
  2. Errori di compilazione ... lo sviluppatore dovrebbe gestire tutte le eccezioni in altro modo se un'applicazione di accordo di errore smetterà di funzionare dove di nuovo dobbiamo andare e avviarla manualmente o utilizzando qualsiasi strumento di automazione.

Conclusione: - Nodejs è meglio usare per applicazioni semplici e in tempo reale .. se hai una logica di business molto grande e una funzionalità complessa meglio non dovrebbe usare nodejs. Se vuoi creare un'applicazione insieme alla chat e a qualsiasi funzionalità di collaborazione .. Il nodo può essere usato in parti specifiche e rimanere dovrebbe andare con la tua tecnologia di convenienza.


-3
  1. Il nodo è ottimo per i prototipi rapidi, ma non lo userei mai più per qualcosa di complesso. Ho trascorso 20 anni a sviluppare una relazione con un compilatore e sicuramente mi manca.

  2. Il nodo è particolarmente doloroso per mantenere il codice che non si visita da un po '. Le informazioni sul tipo e il rilevamento degli errori in fase di compilazione sono BUONE COSE. Perché buttare via tutto questo? Per cosa? E dang, quando qualcosa va a sud la pila traccia abbastanza spesso completamente inutile.


2
Mentre non ottieni il controllo in fase di compilazione, JSDoc ti consente di aggiungere qualsiasi tipo di informazione che desideri in modo che le cose abbiano più senso al tuo ritorno. Le funzioni (piccole) correttamente decomposte sono anche abbastanza facili da individuare a causa del loro ambiente ben definito (la chiusura). Tracce di stack errate possono spesso essere risolte con un po 'di factoring per assicurarsi di non dividere la logica con un callback asincrono in mezzo. Mantenere i callback asincroni all'interno della stessa chiusura rende facile ragionare e mantenere.
Rich Remer,

2
Ho trascorso 30 anni con le lingue compilate, ma dopo averlo usato solo per circa un anno JavaScript è ora la mia lingua preferita. È così produttivo: posso fare molto di più con molto meno codice di Java C # C ++ o C. Ma è una mentalità diversa. La variabile non tipizzata è in realtà un vantaggio in molti casi. JSLINT è essenziale. Quando è necessario eseguire operazioni simultanee, i callback asincroni sono molto più sicuri, più semplici e, in definitiva, più produttivi di qualsiasi linguaggio in cui è necessario utilizzare i thread. E devi conoscere JavaScript comunque perché è la lingua del browser.
James,

Sono d'accordo con le preoccupazioni sollevate e noto che sono stati compiuti alcuni sforzi per affrontarle, anche se non sono state applicate universalmente. Esiste un progetto straordinario chiamato Tern che può fornire la derivazione del tipo dall'analisi statica del codice Javascript e delle librerie. Ha plugin per vari editor. C'è anche Typescript, JSDoc e BetterJS . E poi c'è Go , uno dei tanti linguaggi da compilare a Javascript !
joeytwiddle,
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.