Come decidere quando utilizzare Node.js?

Sono nuovo di questo genere di cose, ma ultimamente ho sentito molto su quanto sia 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 fatto 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 il grande motore JavaScript V8
  • è molto buono quando devi fare parecchie cose allo stesso tempo
  • è basato sugli eventi, quindi tutto il meraviglioso materiale Ajax può essere fatto dal lato server
  • ci consente di condividere il codice tra il browser e il back-end
  • ci permette di parlare con MySQL

Alcune delle fonti che ho incontrato sono:

  • Immergersi in Node.js – Introduzione e installazione
  • Capire NodeJS
  • Nodo per esempio ( Archive.is )
  • Facciamo un’app Web: NodePad

Considerando che Node.js può essere eseguito quasi fuori dagli schemi delle istanze EC2 di Amazon , sto cercando di capire quale tipo di problemi richiede Node.js in opposizione a qualsiasi dei potenti re là fuori come PHP , Python e Ruby . Capisco che in realtà dipende dall’esperienza che si ha su una lingua, ma la mia domanda ricade maggiormente nella categoria generale di: Quando utilizzare un particolare quadro e quale tipo di problemi è particolarmente adatto?

Hai fatto un ottimo lavoro nel riassumere ciò che è fantastico su 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” , è ansible scrivere un’applicazione che invia aggiornamenti all’utente in tempo reale. Fare sondaggi lunghi su molti dei giganti del web, come Ruby on Rails o Django , creerebbe un carico immenso sul server, perché ogni client attivo mangia un processo del server. Questa situazione equivale ad un attacco tarpit . Quando si utilizza qualcosa come Node.js, il server non ha bisogno di mantenere thread separati per ogni connessione aperta.

Ciò significa che puoi creare un’applicazione di chat basata su browser in Node.js che non richiede quasi risorse di sistema per servire moltissimi clienti. Ogni volta che vuoi eseguire 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 (rispettivamente eventmachine e twisted ), ma che Node.js lo fa eccezionalmente bene, e da zero . JavaScript è eccezionalmente situato in un modello di concorrenza basato sul callback ed eccelle qui. Inoltre, essere in grado di serializzare e deserializzare con JSON nativo sia sul client che sul server è piuttosto elegante.

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

Vale la pena sottolineare che Node.js è ottimo anche per situazioni in cui riutilizzerai molto codice attraverso il gap client / server. Il framework Meteor lo rende davvero facile, 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 è dedicare 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 essere molto facile da configurare con un piccolo aiuto da gevent: TicTacToe e Long Polling con Pyramid .

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

Vorrei anche menzionare che Socket.IO in combinazione con Node.js ridurrà la latenza in tempo reale anche oltre rispetto a quanto è ansible con il polling lungo. Socket.IO tornerà al polling lungo come scenario peggiore, e invece utilizzerà socket Web o Flash anche se disponibili.

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

Inoltre, Ryan Dahl ha detto in una conferenza che una volta ho assistito al fatto che il Node.js benchmark Nginx strettamente rivale per regolari richieste HTTP vecchie. 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 a gestirle.

Inoltre è tutto JavaScript sempre. Lingua Franca sull’intero stack.

Motivi per utilizzare NodeJS:

  • Esegue Javascript, quindi puoi usare la stessa lingua su server e client, e persino condividere un po ‘di codice tra di loro (ad esempio per la convalida del modulo o per il rendering di viste alle estremità).

  • Il sistema event-driven 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 , incluse librerie / moduli client e server-side, oltre a strumenti da riga di comando per lo sviluppo web. Molti 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 report di rilascio standardizzati e forking facile.

  • È diventato l’ambiente standard defacto in cui è ansible eseguire strumenti correlati a JavaScript e altri strumenti correlati al Web , tra cui task runner, minificatori, abbellitori, linters, preprocessor, bundler e processori di analisi.

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

Motivi per non utilizzare NodeJS:

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

  • Aggiunto a questo, molti dei pacchetti in NPM sono un po ‘ grezzi , e ancora in rapido sviluppo. Alcune librerie per i framework precedenti hanno subito un decennio di test e bugfixing 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, da cui una grande percentuale non viene più mantenuta.

  • Callback annidato (Naturalmente ci sono 20 diverse soluzioni per questo …)

  • Il numero sempre crescente di pacchetti può far apparire radicalmente diverso il progetto NodeJS dal prossimo. 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. A differenza di uno sviluppatore Rails che si unisce a un progetto esistente, dovrebbe essere in grado di familiarizzare con l’app abbastanza rapidamente, perché tutte le app Rails sono incoraggiate a utilizzare una struttura simile .

  • Trattare con i file può essere un po ‘un dolore. Le cose che sono banali in altri linguaggi, come leggere una riga da un file di testo, sono abbastanza strane da fare con Node.js che c’è una domanda StackOverflow su quella con 80+ upvotes. Non esiste un modo semplice per leggere un record alla volta da un file CSV . Eccetera.

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

Per farla breve:

Node.js è adatto per applicazioni che hanno molte connessioni simultanee e ogni richiesta richiede solo pochissimi cicli di CPU, perché il ciclo degli eventi (con tutti gli altri client) è bloccato durante l’esecuzione di una funzione.

Un buon articolo sul ciclo degli eventi in Node.js è il blog tecnologico di Mixu: Comprensione del ciclo degli eventi node.js.

Ho un esempio del mondo reale in cui ho usato Node.js. L’azienda in cui lavoro ha un cliente che desidera avere un semplice sito Web HTML statico. Questo sito web è per la vendita di un articolo tramite PayPal e il cliente desiderava anche avere un contatore che mostra la quantità di articoli venduti. Il cliente si aspetta un numero enorme di visitatori di questo sito. 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’object è venduto e offre 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. Ci sono state oltre 200000 visite su questo sito in tre settimane e le risorse minime del server sono state in grado di gestire tutto.
  2. Il contatore è davvero facile da fare per essere in tempo reale.
  3. Node.js è stato 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.

I motivi più importanti per iniziare il tuo prossimo progetto usando il nodo …

  • Ci sono tutti i tipi più simpatici … quindi deve essere divertente.
  • Puoi rilassarti al fresco e avere tantissime avventure di Nodo di cui vantarti.
  • Sei un centesimo spaccone quando si tratta di costi di cloud hosting.
  • Ci sono stato fatto con Rails
  • Tu odi le implementazioni di IIS
  • Il tuo vecchio lavoro IT sta diventando noioso e ti piacerebbe che tu fossi in una nuova brillante Start Up.

Cosa aspettarsi …

  • Ti sentirai sicuro e protetto con Express senza tutti i bloatware server di cui non hai mai avuto bisogno.
  • Funziona come un razzo e scala bene.
  • Lo sogni. L’hai installato. Il pacchetto di nodes repo npmjs.org è il più grande ecosistema di librerie open source al mondo.
  • Il tuo cervello avrà il tempo deformato nella terra delle callback annidate …
  • … finché non impari a mantenere le tue promesse .
  • Sequelize e Passport sono i tuoi nuovi amici API.
  • Il debug del codice per lo più asincrono diventerà umm … interessante .
  • Tempo per tutti i Noders per padroneggiare Typescript .

Chi lo usa?

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

Non c’è niente come Silver Bullet. Tutto viene fornito con alcuni costi associati ad esso. È come se mangi cibo oleoso, comprometterai la tua salute e il cibo sano non viene 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 si adatta a questo scenario, non dovresti prenderla in considerazione per lo sviluppo della tua app. Sto solo mettendo il mio pensiero sullo stesso:

Quando usare Node.JS

  1. Se il tuo codice di accesso al server richiede pochissimi cicli di CPU. In altri paesi si sta eseguendo un’operazione non di blocco e non si dispone di algoritmo / lavoro pesante che consuma molti cicli della CPU.
  2. Se vieni da Javascript back ground e sei a tuo agio nello scrivere il codice Single Threaded come il lato client JS.

Quando NON usare Node.JS

  1. La richiesta del server dipende dall’algoritmo / Job che consuma molta CPU.

Considerazioni sulla scalabilità con Node.JS

  1. Node.JS non utilizza tutto il core del sistema sottostante ed è single threaded per impostazione predefinita, è necessario scrivere la logica da soli per utilizzare il processore multi core e renderlo multi-threaded.

Node.JS Alternative

Ci sono altre opzioni da utilizzare al posto di Node.JS tuttavia Vert.x sembra essere piuttosto promettente e ha molte funzionalità aggiuntive come poligot e considerazioni di scalabilità migliori.

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

Il mio pezzo: nodejs è ottimo per realizzare sistemi in tempo reale come analytics, chat-app, apis, server pubblicitari, ecc. Diavolo, ho fatto 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 utilizzare nodejs e l’ho usato per creare molte cose diverse tra cui file server statici, analisi semplice, applicazioni di chat e molto altro. Questa è la mia opinione su quando utilizzare nodejs

Quando usare

Quando si realizza un sistema che pone l’accento sulla concorrenza e sulla velocità.

  • Socket solo server come app di chat, applicazioni irc, ecc.
  • Social network che mettono l’accento sulle risorse in tempo reale come la geolocalizzazione, il stream video, il stream 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 utilizzarlo dove vuoi ma probabilmente non in questi posti.

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

Tieni presente che sto solo facendo il pelo nell’uovo. Per i file server statici, apache è migliore soprattutto perché è ampiamente disponibile. La community di nodejs è diventata più grande e più matura nel corso degli anni ed è sicuro che nodejs può essere utilizzato praticamente ovunque se si dispone della propria scelta di hosting.

Può essere usato dove

  • Applicazioni che sono altamente guidate dagli eventi e fortemente vincolate all’I / O
  • Applicazioni che gestiscono un numero elevato di connessioni ad altri sistemi
  • Applicazioni in tempo reale (Node.js è stato progettato da zero per il tempo reale e per essere facile da usare.)
  • Applicazioni che destreggiano su scadenze di streaming di informazioni da e verso altre fonti
  • Traffico elevato, applicazioni scalabili
  • App 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 hanno bisogno di parlare molto spesso con il back-end

Sul fronte mobile, le aziende prime time si affidano a Node.js per le loro soluzioni mobili. Scopri perché?

LinkedIn è un utente di primo piano. Il loro intero stack mobile è costruito su Node.js. Sono passati dall’esecuzione di 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à sviluppatore per gestire oltre 120.000 connessioni attive per nodo.js, con ogni connessione che consuma circa 2kB di memoria!

Walmart ha riprogettato la sua app mobile per utilizzare Node.js e ha trasferito l’elaborazione JavaScript sul server.

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

Nodo migliore per la gestione simultanea delle richieste –

Quindi, iniziamo con una storia. Negli ultimi 2 anni sto lavorando su JavaScript e sviluppo web front end e mi sto divertendo. I ragazzi di back end ci forniscono alcune API scritte in Java, python (non ci interessa) e scriviamo semplicemente una chiamata AJAX, otteniamo i nostri dati e indovinate un po ‘! abbiamo chiuso. Ma in realtà non è così facile, se i dati che riceviamo non sono corretti o c’è qualche errore del server, allora ci siamo bloccati e dobbiamo contattare i nostri back end per posta o chat (a volte anche su whatsApp :)). non è bello E se scrivessimo le nostre API in JavaScript e chiamassimo quelle API dal nostro front-end? Sì, è fantastico, perché se affrontiamo qualsiasi problema in API possiamo esaminarlo. Indovina un po ! puoi farlo ora, come? – Il nodo è lì per te.

Ok ha convenuto che puoi scrivere la tua API in JavaScript, ma cosa succede se sto bene con il problema di cui sopra. Avete altri motivi per utilizzare il nodo per l’API di rest?

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

Torniamo al nostro sistema API di resto tradizionale basato su operazioni di blocco o threading. Supponiamo che si verifichino due richieste simultanee (r1 e r2), ognuna delle quali richiede il funzionamento del database. Quindi nel sistema tradizionale cosa succederà:

1. Waiting Way: il nostro server inizia a servire la richiesta r1 e attende la risposta alla query. dopo il completamento di r1 , il server inizia a servire r2 e lo fa nello stesso modo. Quindi aspettare non è una buona idea perché non abbiamo molto tempo.

2. Threading Way: il nostro server creerà due thread per entrambe le richieste r1 e r2 e servirà allo scopo dopo aver interrogato il database in modo che sia veloce. Ma consuma memoria perché è ansible vedere che abbiamo avviato due thread, anche il problema aumenta quando entrambe le richieste eseguono query stessi dati quindi devi affrontare problemi tipo deadlock. Quindi è meglio che aspettare, ma ci sono ancora problemi.

Ora qui, come il nodo lo farà:

3. Nodeway: quando la stessa richiesta simultanea arriva nel nodo allora registrerà un evento con il suo callback e proseguirà non attenderà la risposta alla query per una particolare richiesta. r1 quando viene richiesta r1 allora il ciclo degli eventi del nodo (sì c’è un evento loop in nodo che serve a questo scopo.) registrare un evento con la sua funzione di callback e andare avanti per servire la richiesta r2 e registrare analogamente il suo evento con il suo callback. Ogni volta che una query termina, triggers il relativo evento ed esegue la richiamata fino al completamento senza essere interrotta.

Quindi niente attesa, niente threading, nessun consumo di memoria – sì, questo è il nodeway per servire l’API di rest.

Il mio motivo in più 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 posso immaginare senza di esso, copre tutti i cicli di sviluppo. Tutto ciò di cui hai bisogno è un browser e puoi codificare sempre e dovunque su qualsiasi dispositivo. Non è necessario effettuare il check-in del codice in un computer (come a casa), quindi effettuare il checkout in un altro computer (come nel luogo di lavoro).

Naturalmente, forse IDE basato su cloud per altre lingue o piattaforms (l’IDE di Cloud 9 sta aggiungendo supporti anche per altre lingue), ma l’utilizzo di Cloud 9 per lo sviluppo di Node.js è davvero una grande esperienza per me.

Un’ultima cosa che fornisce il nodo è la possibilità di creare più instane di nodes v8 usando il processo figlio del nodo ( childProcess.fork () ciascuno che richiede una memoria da 10mb come per i documenti) al volo, senza influenzare il 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 utilizzato molto il nodo e nella maggior parte delle app che creiamo, richiediamo connessioni server allo stesso tempo, quindi un traffico di rete pesante. Framework come Express.js e il nuovo Koajs (che ha rimosso l’inferno di callback) hanno reso ancora più facile lavorare sul nodo.

Indossare ami da lungo tempo …

Ieri il mio titolo con Pubblicazioni Packt, Programmazione retriggers con JavaScript . Non è in realtà un titolo centrato su Node.js; i primi capitoli hanno lo scopo di comprendere la teoria, e in seguito i capitoli dedicati al codice coprono la pratica. Poiché non pensavo davvero che sarebbe stato opportuno non fornire ai lettori un server web, Node.js sembrava 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 sui punti buoni e sui punti negativi che ho incontrato.

Consentitemi di includere alcune citazioni rilevanti qui:

Attenzione: Node.js e il suo ecosistema sono hot -hot abbastanza da bruciarti!

Quando ero insegnante in matematica, uno dei suggerimenti non ovvi che mi è stato detto non era quello di dire a uno studente che qualcosa era “facile”. La ragione era piuttosto ovvia in retrospettiva: se dici alla gente qualcosa è facile, qualcuno che non vede una soluzione può finire per sentirsi (ancora più) stupidi, perché non solo non riescono a capire come risolvere il problema, ma il problema sono troppo stupidi per capirlo è facile!

Ci sono trucchi che non solo infastidiscono le persone che provengono da Python / Django, che ricarica immediatamente la sorgente se cambi qualcosa. Con Node.js, il comportamento predefinito è che se si effettua una modifica, la vecchia versione continua ad essere triggers fino alla fine del tempo o fino a quando non si arresta e si riavvia manualmente il server. Questo comportamento inappropriato non infastidisce solo Pythonistas; inoltre irrita gli utenti nativi di Node.js che forniscono varie soluzioni alternative. La domanda StackOverflow “Ricarica automatica dei file in Node.js” ha, al momento della stesura di questo documento, oltre 200 revisioni e 19 risposte; una modifica indirizza l’utente a uno script di babysitter, node-supervisor, con homepage su http://tinyurl.com/reactjs-node-supervisor . Questo problema offre ai nuovi utenti una big opportunità di sentirsi stupidi perché pensano di aver risolto il problema, ma il vecchio comportamento da bug è 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 morde le spalle; è solo che i progettisti di Node.js non hanno visto alcun motivo per fornire un comportamento appropriato qui. Cerca di farcela, magari con un piccolo aiuto da parte del supervisore di nodo o di un’altra soluzione, ma per favore non andare via sentendo che sei stupido. Non sei quello con il problema; il problema è nel comportamento predefinito di Node.js. ”

Questa sezione, dopo qualche discussione, è stata lasciata, proprio perché non voglio dare l’impressione di “È facile”. Mi taglio le mani ripetutamente mentre faccio funzionare, e non voglio smussare le difficoltà e impostarti per credere che ottenere Node.js e il suo ecosistema funzioni bene è una questione semplice e se non è semplice anche per te, non sai cosa stai facendo. Se non si incontrano difficoltà odiose con Node.js, è meraviglioso. Se lo fai, mi auguro che non te ne vada a sentire “Sono stupido – deve esserci qualcosa di sbagliato in me.” Non sei stupido se provi brutte sorprese 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 la conclusione, parla di ciò che sono stato in grado di trovare nell’ecosistema, e ha fornito una soluzione per il letteralismo moralista:

Un altro database che sembrava perfetto e potrebbe ancora essere riscattabile è un’implementazione lato server dell’archivio valori-chiave HTML5. Questo approccio ha il vantaggio cardinale di un’API che i migliori sviluppatori front-end comprendono abbastanza bene. Del resto, è anche un’API che gli sviluppatori front-end più non-così-buoni capiscono abbastanza bene. Ma con il pacchetto node-localstorage, mentre l’accesso alla syntax del dizionario non viene offerto (si desidera utilizzare localStorage.setItem (chiave, valore) o localStorage.getItem (chiave), non localStorage [chiave]), la semantica fullStorage completa viene implementata , incluso un limite predefinito di 5MB – PERCHÉ? Gli sviluppatori JavaScript lato server devono essere protetti da se stessi?

Per le funzionalità del database lato client, una quota di 5 MB per sito Web è davvero una quantità generosa e utile di spazio per consentire agli sviluppatori di lavorare con esso. È ansible impostare una quota molto più bassa e offrire agli sviluppatori un miglioramento incommensurabile rispetto alla gestione dei cookie. Un limite di 5 MB non si presta molto rapidamente all’elaborazione lato client dei Big Data, ma c’è una tolleranza davvero generosa che gli sviluppatori pieni di risorse possono usare per fare molto. D’altra parte, 5MB non è una porzione particolarmente ampia della maggior parte dei dischi acquistati in qualsiasi momento di recente, il che significa che se tu e un sito web non sei d’accordo su cosa è l’uso ragionevole dello spazio su disco, o qualche sito è semplicemente hoggish, non costa davvero molto e non si corre il rischio di un disco rigido sommerso, a meno che il disco rigido non sia già pieno. Forse staremmo meglio se il saldo fosse un po ‘meno o un po’ di più, ma nel complesso è una soluzione decente per affrontare la tensione intrinseca per un contesto lato cliente.

However, it might gently be pointed out that when you are the one writing code for your server, you don’t need any additional protection from making your database more than a tolerable 5MB in size. Most developers will neither need nor want tools acting as a nanny and protecting them from storing more than 5MB of server-side data. And the 5MB quota that is a golden balancing act on the client-side is rather a bit silly on a Node.js server. (And, for a database for multiple users such as is covered in this Appendix, it might be pointed out, slightly painfully, that that’s not 5MB per user account unless you create a separate database on disk for each user account; that’s 5MB shared between all user accounts together. That could get painful if you go viral!) The documentation states that the quota is customizable, but an email a week ago to the developer asking how to change the quota is unanswered, as was the StackOverflow question asking the same. The only answer I have been able to find is in the Github CoffeeScript source, where it is listed as an optional second integer argument to a constructor. So that’s easy enough, and you could specify a quota equal to a disk or partition size. But besides porting a feature that does not make sense, the tool’s author has failed completely to follow a very standard convention of interpreting 0 as meaning “unlimited” for a variable or function where an integer is to specify a maximum limit for some resource use. The best thing to do with this misfeature is probably to specify that the quota is Infinity:

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

Swapping two comments in order:

People needlessly shot themselves in the foot constantly using JavaScript as a whole, and part of JavaScript being made respectable language was a Douglas Crockford saying in essence, “JavaScript as a language has some really good parts and some really bad parts. Here are the good parts. Just forget that anything else is there.” Perhaps the hot Node.js ecosystem will grow its own “Douglas Crockford,” who will say, “The Node.js ecosystem is a coding Wild West, but there are some real gems to be found. Here’s a roadmap. Here are the areas to avoid at almost any cost. Here are the areas with some of the richest paydirt to be found in ANY language or environment.”

Perhaps someone else can take those words as a challenge, and follow Crockford’s lead and write up “the good parts” and / or “the better parts” for Node.js and its ecosystem. I’d buy a copy!

And given the degree of enthusiasm and sheer work-hours on all projects, it may be warranted in a year, or two, or three, to sharply temper any remarks about an immature ecosystem made at the time of this writing. It really may make sense in five years to say, “The 2015 Node.js ecosystem had several minefields. The 2020 Node.js ecosystem has multiple paradises.”

If your application mainly tethers web apis, or other io channels, give or take a user interface, node.js may be a fair pick for you, especially if you want to squeeze out the most scalability, or, if your main language in life is javascript (or javascript transpilers of sorts). If you build microservices, node.js is also okay. Node.js is also suitable for any project that is small or simple.

Its main selling point is it allows front-enders take responsibility for back-end stuff rather than the typical divide. Another justifiable selling point is if your workforce is javascript oriented to begin with.

Beyond a certain point however, you cannot scale your code without terrible hacks for forcing modularity, readability and flow control. Some people like those hacks though, especially coming from an event-driven javascript background, they seem familiar or forgivable.

In particular, when your application needs to perform synchronous flows, you start bleeding over half-baked solutions that slow you down considerably in terms of your development process. If you have computation intensive parts in your application, tread with caution picking (only) node.js. Maybe http://koajs.com/ or other novelties alleviate those originally thorny aspects, compared to when I originally used node.js or wrote this.

I can share few points where&why to use node js.

  1. For realtime applications like chat,collaborative editing better we go with nodejs as it is event base where fire event and data to clients from server.
  2. Simple and easy to understand as it is javascript base where most of people have idea.
  3. Most of current web applications going towards angular js&backbone, with node it is easy to interact with client side code as both will use json data.
  4. Lot of plugins available.

Drawbacks:-

  1. Node will support most of databases but best is mongodb which won’t support complex joins and others.
  2. Compilation Errors…developer should handle each and every exceptions other wise if any error accord application will stop working where again we need to go and start it manually or using any automation tool.

Conclusion:- Nodejs best to use for simple and real time applications..if you have very big business logic and complex functionality better should not use nodejs. If you want to build an application along with chat and any collaborative functionality.. node can be used in specific parts and remain should go with your convenience technology.

  1. Node is great for quick prototypes but I’d never use it again for anything complex. I spent 20 years developing a relationship with a compiler and I sure miss it.

  2. Node is especially painful for maintaining code that you haven’t visited for awhile. Type info and compile time error detection are GOOD THINGS. Why throw all that out? For what? And dang, when something does go south the stack traces quite often completely useless.