Wie kann man entscheiden, wann Node.js verwendet werden soll?

Glaube ich Node.js am besten geeignet für real-time-Anwendungen: online-Spiele, collaboration-tools, chat-Räume, oder etwas, wo das, was ein Benutzer (oder Roboter? oder sensor?) mit der Anwendung gesehen werden muss, die von anderen Benutzern sofort, ohne Seite aktualisieren.

Sollte ich auch erwähnen, dass Socket.IO in Kombination mit Node.js reduzieren Sie Ihre Echtzeit-Latenz sogar noch weiter als das, was möglich ist mit long polling. Socket.IO wird wieder long-polling als worst-case-Szenario, und statt die Nutzung von web sockets oder sogar Flash, wenn Sie verfügbar sind.

Aber ich sollte auch erwähnen, dass gerade über irgendeine situation, wo könnte der code-block durch threads besser angegangen werden kann mit Node.js. Oder jeder situation, wo Sie müssen die Anwendung event-driven.

Auch Ryan Dahl sagte in einem Vortrag, den ich einmal besuchte, dass die Node.js benchmarks eng Rivalen Nginx für regelmäßige alten HTTP-Anfragen. Also, wenn wir bauen mit Node.js wir dienen unseren normalen Ressourcen sehr effektiv, und wenn brauchen wir die event-driven Dinge verwende, ist er bereit, es zu handhaben.

Plus ist es, alle JavaScript-die ganze Zeit. Lingua Franca auf den ganzen Stapel.

InformationsquelleAutor der Antwort fisherwebdev

Um es kurz zu machen:

Node.js ist gut geeignet für Anwendungen, die eine Menge von gleichzeitigen verbindungen, und jede Anfrage muss nur sehr wenige CPU-Zyklen, weil die Ereignis-Schleife (mit allen anderen clients ist blockiert während der Ausführung einer Funktion.

Einen guten Artikel über die Ereignis-Schleife in Node.js ist Mixu ' s tech-blog: das Verständnis der node.js Ereignis-Schleife.

InformationsquelleAutor der Antwort stewe

Die wichtigsten Gründe, um Ihr Nächstes Projekt mit Knoten ...

• Alle die coolsten dudes sind ... so ist es muss lustig werden.
• Sie können Treffpunkt am Kühler und haben viele Knoten Abenteuern zu prahlen.
• Du bist eine penny-pincher, wenn es um cloud-hosting-Kosten.
• Dort getan, mit Schienen
• Sie hassen IIS Implementierungen
• Ihre alten IT-job wird immer eher langweilig und Sie wünschte, Sie waren in einer glänzenden neuen Start-Up.

... Was erwartet

• Sie werden sich sicher fühlen und sicher auszudrücken, ohne die server-bloatware, die Sie nie benötigt werden.
• Läuft wie eine Rakete und skaliert gut.
• Sie es träumen. Sie es installiert haben. Die Knoten-Paket-repo - npmjs.org ist das größte ökosystem von open-source-Bibliotheken der Welt.
• Dein Gehirn bekommt Zeit verzogen sich in das land der verschachtelten callbacks ...
• ... bis Sie lernen, halten Sie Ihre Verspricht.
• Sequelize und Pass sind Ihre neuen API-Freunde.
• Debugging meist async-code erhalten umm ... interessante .
• Zeit für alle Noders zu meistern Typoskript.

Wem nutzt es?

• PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
• Hier ist, warum Sie geschaltet Knoten.

InformationsquelleAutor der Antwort Tony O'Hagan

Eine weitere tolle Sache, dass ich denke niemand hat erwähnt, über Node.js ist die tolle Gemeinschaft, das Paket-management-system (npm) und die Menge der Module, die vorhanden sind, können Sie, indem Sie einfach Sie in Ihr Paket.json-Datei.

InformationsquelleAutor der Antwort BoxerBucks

Kann es verwendet werden, wo

• Anwendungen, die stark ereignisgesteuert & stark I/O gebunden
• Anwendungen, Umgang mit einer großen Anzahl von verbindungen zu anderen Systemen
• Real-time-Anwendungen (Node.js wurde von Grund auf entwickelt für die Echtzeit-und zu leicht
  zu verwenden.)
• Anwendungen, jonglieren Unmengen von Informationen-streaming zu und von anderen Quellen
• Hohen traffic, Skalierbare Anwendungen
• Mobile-apps sprechen-Plattform-API & Datenbank, ohne zu tun, eine Menge von Daten
  analytics
• Bauen, die aus vernetzten Anwendungen
• Anwendungen, die Notwendigkeit zu sprechen, um die back-end sehr oft

Auf Mobilen front -, prime-time-Unternehmen verlassen sich auf Node.js für mobile Lösungen. Überprüfen Sie heraus, warum?

LinkedIn ist ein prominenter Nutzer. Ihre gesamte mobile Stacks auf Node.js. Sie ging aus der Ausführung 15 Servern mit 15 Instanzen auf einer einzelnen physischen Maschine, auf nur 4 Instanzen – und kann mit Doppel-Verkehr!

eBay gestartet ql.io, eine web-Abfrage-Sprache für HTTP-APIs, die verwendet Node.js da die Laufzeit-stack. Sie waren in der Lage zu Stimmen, eine regelmäßige Entwickler-Qualität Ubuntu-workstation mit mehr als 120.000 aktiven verbindungen pro node.js Prozess, mit dem jede Verbindung verbraucht etwa 2kB Speicher!!!

Walmart überarbeitet seine mobile app zu verwenden Node.js und schob seine JavaScript-Verarbeitung auf dem server.

Lesen Sie mehr unter: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/

InformationsquelleAutor der Antwort Vinayak Bevinakatti

Meine ein Grund mehr zu wählen Node.js für ein neues Projekt:

In der Lage sein zu tun, Reine cloud-basierte Entwicklung

Habe ich verwendet Cloud9 IDE für eine Weile und jetzt kann ich mir nicht vorstellen, ohne es deckt alle Entwicklungszyklen. Alles, was Sie brauchen, ist ein browser und Sie können den code jederzeit und überall auf allen Geräten. Sie nicht brauchen, um check-in-code in einem Computer(wie zu Hause), dann Kasse an einen anderen computer an(wie am Arbeitsplatz).

Natürlich, es gibt vielleicht cloud-basierte IDE, die für andere Sprachen oder Plattformen (Cloud 9 IDE ist das hinzufügen von Unterstützung für andere Sprachen auch), aber unter Verwendung von Cloud 9 zu tun Node.js Entwicklung ist wirklich eine tolle Erfahrung für mich.

InformationsquelleAutor der Antwort Sean Zhao

Anziehen Asbest longjohns...

Gestern meinen Titel mit Packt Publikationen, Reaktive Programmierung mit JavaScript. Es ist nicht wirklich ein Knoten.js-centric Titel; die ersten Kapitel dienen der Deckung der Theorie und später-code-schweres Kapitel umfassen die Praxis. Weil ich nicht wirklich denke, dass es angemessen wäre, zu Versagen, den Lesern ein webserver, Node.js schien von weit die offensichtliche Wahl. Der Fall wurde geschlossen, bevor es war sogar geöffnet.

Ich hätte eine sehr rosige Sicht auf meine Erfahrung mit Node.js. Stattdessen war ich ehrlich über gute Punkte und schlechte Punkte, die ich traf.

Lassen Sie mich ein paar Zitate, die hier relevant sind:

Warnung: Node.js und Ihr ökosystem sind hot--heiß genug, um Sie brennen schlecht!

Wenn ich war ein Lehrer-Assistent in der Mathematik, einer der das nicht-offensichtliche Vorschläge, die ich war sagte, war nicht zu einem Schüler sagen, dass etwas "einfach". Der Grund war ziemlich offensichtlich im Nachhinein: wenn Sie sagen, die Menschen etwas ist einfach jemand, der nicht sehen, eine Lösung kann am Ende das Gefühl (sogar noch mehr) dumm, weil nicht nur, dass Sie nicht bekommen, wie das problem zu lösen, aber das problem Sie sind zu dumm, um zu verstehen, ist einfach!

Gibt es Fallstricke, die nicht nur ärgern Besucher von Python /Django, der sofort lädt der Quelle, wenn du etwas ändern. Mit Node.js das Standardverhalten ist, dass, wenn Sie eine änderung vornehmen, wird die alte version ist weiterhin aktiv, bis das Ende der Zeit oder bis Sie manuell beenden und starten Sie den server neu. Dieses unangemessene Verhalten nicht nur ärgern Pythonistas; es auch irritiert native Node.js Benutzer, die bieten verschiedene workarounds. StackOverflow-Frage "Auto-nachladen von Dateien in Node.js" hat, die zum Zeitpunkt des Schreibens dieses Artikels, über 200 upvotes und 19 Antworten, von denen eine zu Bearbeiten weist den Benutzer auf eine nanny script, node-supervisor, mit homepage http://tinyurl.com/reactjs-node-supervisor. Dieses problem bietet neuen Benutzern mit viel Gelegenheit, sich dumm fühlen, weil Sie dachten, Sie hätten das problem behoben, aber das alte, fehlerhafte Verhalten ist völlig unverändert. Und es ist leicht zu vergessen, um bounce den server; ich habe es getan, mehrere Male. Und die Botschaft, die ich geben möchte, ist, “Nein, du bist nicht dumm, weil dieses Verhalten von Node.js etwas Ihren Rücken; es ist nur, dass die Entwickler von Node.js sah keinen Grund, um sich angemessen Verhalten hier. Nicht versuchen, mit ihm fertig zu werden, vielleicht unter ein wenig Hilfe von node-supervisor oder eine andere Lösung, aber bitte nicht zu Fuß entfernt Gefühl, dass du blöd bist. Du bist nicht der mit dem problem; das problem ist in Node.js's Standard-Verhalten."

Diesem Abschnitt, nach einiger Diskussion, war auf der linken Seite, gerade, weil ich nicht wollen, um einen Eindruck von "Es ist ganz einfach." Ich Schneide meine Hände immer wieder, während sich die Dinge zu arbeiten, und ich will nicht glatt über Schwierigkeiten und setzen Sie sich zu glauben, dass immer Node.js und Ihr ökosystem, um gut zu funktionieren, ist eine unkomplizierte Angelegenheit und wenn es nicht einfach für Sie zu, Sie wissen nicht, was Sie tun. Wenn Sie laufen Sie nicht in Schwierigkeiten bei der Verwendung von widerlich Node.js,, das ist wunderbar. Wenn Sie tun, hoffe ich, dass Sie nicht zu Fuß entfernt Gefühl, "ich bin dumm—es muss etwas falsch mit mir." Du bist nicht dumm, wenn Sie erleben böse überraschungen im Umgang mit Node.js. Es ist nicht Sie! Es ist Node.js und Ihr ökosystem!

Anhang, die ich nicht wirklich wollen, nach der steigenden crescendo in den letzten Kapiteln und dem Fazit, spricht über das, was ich finden konnte, in das ökosystem, und sofern eine Abhilfe für schwachsinnig wörtlichkeit:

Einer anderen Datenbank, die schien wie eine perfekte Passform und kann noch eingelöst werden, ist eine server-seitige Implementierung der HTML5-Schlüssel-Wert-Speicher. Dieser Ansatz hat den Kardinal Vorteil einer API, dass die meisten front-end Entwickler verstehen, gut genug. Für diese Angelegenheit, es ist auch eine API, die die meisten nicht-so-gute front-end-Entwickler verstehen gut genug. Aber mit der node-localstorage-Paket, während das Lexikon-syntax-Zugang wird nicht angeboten (Sie verwenden möchten, "localStorage".setItem(key, value) - oder localStorage.getItem(key), nicht localStorage[key]), die volle localStorage-Semantik implementiert werden, einschließlich einer Standard-5MB quota—WARUM? Tun server-side JavaScript-Entwickler müssen vor sich selbst geschützt?

Für die client-seitige Datenbank-Funktionen, eine 5 MB quota pro website ist sehr großzügig und nützlich Menge Platz zum atmen zu lassen, arbeiten die Entwickler mit. Konnten Sie eine viel niedrigere Quote und immer noch bieten die Entwickler eine unermessliche Verbesserung gegenüber humpelnd mit cookie-management. Ein 5MB limit eignet sich nicht sehr schnell auf die Big-Data-client-seitige Verarbeitung, aber es ist ein wirklich sehr großzügiges Taschengeld, dass findige Entwickler können eine Menge tun. Aber auf der anderen Seite, 5MB ist nicht ein besonders großer Teil der meisten Festplatten gekauft Letzte Zeit, was bedeutet, dass, wenn Sie eine website nicht über das, was zumutbar ist die Nutzung von Speicherplatz, oder eine site ist einfach hoggish, es ist nicht wirklich, Kosten viel und Sie sind nicht in Gefahr, überschwemmt eine Festplatte, wenn Ihre Festplatte war bereits zu voll. Vielleicht wären wir besser dran, wenn die balance waren ein bisschen weniger oder ein wenig mehr, aber insgesamt ist es eine anständige Lösung vor, die die intrinsische Spannung für einen client-side-Kontext.

Es könnte aber auch sanft darauf hingewiesen werden, dass, wenn Sie sind das schreiben von code für Ihre server, Sie brauchen keine zusätzlichen Schutz bei der Herstellung Ihrer Datenbank mehr als eine tolerierbare 5MB groß. Die meisten Entwickler, die Sie weder brauchen, noch wollen-tools fungieren als eine Kinderpflegerin und schützt Sie vor speichern von mehr als 5 MB des server-Seite Daten. Und die 5 MB quota ist eine goldene Balanceakt auf der client-Seite ist eher ein bisschen albern, auf eine Node.js server. (Und, für eine Datenbank für mehrere Benutzer, wie Sie unter diesen Anhang, es könnte darauf hingewiesen werden, leicht schmerzlich, dass nicht 5 MB pro Benutzer-account, es sei denn, Sie erstellen eine separate Datenbank auf der Festplatte für jeden Benutzer Accounts; 5 MB shared zwischen allen Benutzer-Konten zusammen. Das könnte schmerzhaft wenn Sie viral!) Die Dokumentation besagt, dass das Kontingent ist individuell, aber eine E-Mail vor einer Woche an die Entwickler zu Fragen, wie zu ändern, die Quote ist unbeantwortet, wie die StackOverflow-Frage zu Fragen, die gleichen. Die einzige Antwort, die ich finden konnte, haben in der Github CoffeeScript Quelle, wo es aufgeführt ist, als ein zweites optionales integer-argument für einen Konstruktor. Also das ist einfach genug, und Sie geben eine Quote gleich eine Festplatte oder partition Größe. Aber neben der Portierung einer Funktion, die keinen Sinn machen, das Werkzeug der Autor hat völlig gescheitert zu Folgen, ein sehr standard-Konvention zu interpretieren 0 als Bedeutung "unbegrenzt" für eine variable oder eine Funktion, wo eine ganze Zahl ist, geben Sie eine maximale Grenze für eine Ressource verwenden. Das beste, was zu tun mit diesem misfeature ist wahrscheinlich, um anzugeben, dass die Quote Infinity:

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

Swapping zwei Kommentare in der Reihenfolge:

Menschen grundlos erschossen selbst in den Fuß ständig mit JavaScript als ganzes, und ein Teil von JavaScript gemacht, anständige Sprache war eine Douglas Crockford sagt im wesentlichen, “JavaScript als Sprache hat einige wirklich gute Teile und auch einige wirklich schlechte Teile. Hier sind die guten Teile. Nur vergessen Sie, dass alles, was es sonst noch gibt." Vielleicht ist der hot Node.js ökosystem wachsen seine eigenen "Douglas Crockford," wer wird sagen, "Die Node.js ökosystem ist eine Codierung Wilden Westen, aber es gibt einige echte Perlen finden. Hier ist ein Fahrplan. Hier sind die Bereiche, die Sie vermeiden, um fast jeden Preis. Hier sind die Bereiche, die mit einigen der reichsten paydirt gefunden werden, in einer BELIEBIGEN Sprache oder der Umwelt."

Vielleicht kann jemand anders nehmen Sie diese Worte als eine Herausforderung, und Folgen Sie Crockford ' s führen und schreiben, bis "die guten Teile" und /oder "besseren Teile" für Node.js und Ihr ökosystem. Ich würde eine Kopie kaufen!

Gegeben und der Grad der Begeisterung und schiere Arbeit-Stunden, die auf alle Projekte, die es gerechtfertigt sein, in einem Jahr, oder zwei, oder drei, stark zu mildern, irgendwelche Bemerkungen über einem unreifen ökosystem zum Zeitpunkt des Schreibens dieses Artikels. Ist es wirklich sinnvoll, in fünf Jahren zu sagen, “für Das Jahr 2015 Node.js ökosystem hatte mehrere Minenfelder. Die 2020-Node.js ökosystem hat mehrere Paradiese."

InformationsquelleAutor der Antwort JonathanHayward

Kann ich teilen einige Punkte, in denen&Gründe für die Verwendung von node js.

1. Für realtime Anwendungen wie chat,kollaborative Bearbeitung besser wir gehen mit nodejs, wie es ist event-base, wo Feuer-event und Daten an clients vom server.
2. Einfach und leicht zu verstehen, wie es ist javascript Basis, wo die meisten Menschen haben die Idee.
3. Die meisten aktuellen web-Anwendungen in Richtung angular js&Rückgrat, mit Knoten ist es einfach, um die Interaktion mit client-seitigen code wie beide verwenden json-Daten.
4. Menge von plugins zur Verfügung.

Nachteile:-

1. Knoten unterstützen die meisten Datenbanken, aber am besten ist, mongodb, die keine Unterstützung für komplexe joins und andere.
2. Kompilierungsfehler... - Entwickler sollte in der Lage jede und jeden Ausnahmen andere Weise, wenn ein Fehler accord Anwendung wird nicht mehr funktionieren, wo wir wieder gehen müssen und starten Sie es manuell oder mit automation tool.

Fazit:-
Nodejs am besten für einfache und Echtzeit-Anwendungen. wenn Sie haben sehr große business-Logik und komplexe Funktionalität, die besser nicht verwenden sollten nodejs.
Wenn Sie möchten, um eine Anwendung zu erstellen, zusammen mit chat und jede gemeinsame Funktionalität.. Knotens kann in bestimmten teilen und bleiben sollte, gehen Sie mit Ihrem Komfort-Technologie.

InformationsquelleAutor der Antwort BEJGAM SHIVA PRASAD