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

Ich bin neu in solchen Sachen, aber in letzter Zeit habe ich viel darüber gehört, wie gut Node.js ist. Wenn man bedenkt, wie sehr ich es liebe, mit jQuery und JavaScript im Allgemeinen zu arbeiten, frage ich mich, wie ich entscheiden soll, wann Node.js verwendet werden soll. Die Webanwendung, an die ich denke, ist so etwas wie Bitly - nimmt einige Inhalte, archiviert sie.

Von all den Hausaufgaben, die ich in den letzten Tagen gemacht habe, habe ich die folgenden Informationen erhalten. Node.js

• ist ein Befehlszeilentool, das als normaler Webserver ausgeführt werden kann und mit dem JavaScript-Programme ausgeführt werden können
• nutzt die großartige V8-JavaScript-Engine
• ist sehr gut, wenn Sie mehrere Dinge gleichzeitig tun müssen
• ist ereignisbasiert, so dass all die wunderbaren Ajax- ähnlichen Dinge auf der Serverseite erledigt werden können
• Lassen Sie uns Code zwischen dem Browser und dem Backend teilen
• Lassen Sie uns mit MySQL sprechen

Einige der Quellen, auf die ich gestoßen bin, sind:

• Eintauchen in Node.js - Einführung und Installation
• NodeJS verstehen
• Knoten durch Beispiel ( Archive.is )
• Erstellen wir eine Web-App: NodePad

In Anbetracht der Tatsache, dass Node.js auf Amazon EC2- Instanzen fast sofort ausgeführt werden kann, versuche ich zu verstehen, welche Art von Problemen Node.js erfordern, im Gegensatz zu den mächtigen Königen wie PHP , Python und Ruby . Ich verstehe, dass es wirklich von der Fachkenntnis einer Sprache abhängt, aber meine Frage fällt eher in die allgemeine Kategorie: Wann sollte ein bestimmtes Framework verwendet werden und für welche Art von Problemen ist es besonders geeignet?

Sie haben großartige Arbeit geleistet, um zusammenzufassen, was an Node.js großartig ist. Meiner Meinung nach eignet sich Node.js besonders für Anwendungen, bei denen Sie eine dauerhafte Verbindung vom Browser zurück zum Server aufrechterhalten möchten. Mithilfe einer als "Long-Polling" bezeichneten Technik können Sie eine Anwendung schreiben, die Aktualisierungen in Echtzeit an den Benutzer sendet. Eine lange Abfrage vieler Webgiganten wie Ruby on Rails oder Django würde den Server immens belasten, da jeder aktive Client einen Serverprozess verschlingt. Diese Situation ist ein Tarpit- Angriff. Wenn Sie so etwas wie Node.js verwenden, muss der Server nicht für jede offene Verbindung separate Threads verwalten.

Dies bedeutet, dass Sie in Node.js eine browserbasierte Chat-Anwendung erstellen können , die fast keine Systemressourcen benötigt, um sehr viele Clients zu bedienen. Jedes Mal, wenn Sie diese Art von Langzeitabfragen durchführen möchten, ist Node.js eine großartige Option.

Es ist erwähnenswert, dass Ruby und Python beide Tools haben, um solche Dinge zu tun ( Eventmachine bzw. Twisted ), aber dass Node.js dies außergewöhnlich gut und von Grund auf macht. JavaScript eignet sich hervorragend für ein Callback-basiertes Parallelitätsmodell und zeichnet sich hier aus. Außerdem ist es ziemlich geschickt, mit JSON, das sowohl für den Client als auch für den Server nativ ist, serialisieren und deserialisieren zu können.

Ich freue mich darauf, hier weitere Antworten zu lesen. Dies ist eine fantastische Frage.

Es ist erwähnenswert, dass Node.js auch für Situationen geeignet ist, in denen Sie viel Code über die Client / Server-Lücke hinweg wiederverwenden. Das Meteor-Framework macht dies wirklich einfach, und viele Leute schlagen vor, dass dies die Zukunft der Webentwicklung sein könnte. Ich kann aus Erfahrung sagen, dass es eine Menge Spaß macht, Code in Meteor zu schreiben, und ein großer Teil davon verbringt weniger Zeit damit, darüber nachzudenken, wie Sie Ihre Daten umstrukturieren werden, damit der Code, der im Browser ausgeführt wird, problemlos funktioniert manipuliere es und gib es zurück.

Hier ist ein Artikel über Pyramide und Langzeitumfragen, der sich mit ein wenig Hilfe von gevent als sehr einfach einzurichten herausstellt: TicTacToe und Langumfrage mit Pyramide .

Ich glaube, Node.js eignet sich am besten für Echtzeitanwendungen: Online-Spiele, Tools für die Zusammenarbeit, Chatrooms oder alles, wo ein Benutzer (oder Roboter? Oder Sensor?) Mit der Anwendung sofort von anderen Benutzern gesehen werden muss. ohne Seitenaktualisierung.

Ich sollte auch erwähnen, dass Socket.IO in Kombination mit Node.js Ihre Echtzeit-Latenz noch weiter reduziert, als dies bei langen Abfragen möglich ist. Socket.IO greift im schlimmsten Fall auf lange Abfragen zurück und verwendet stattdessen Web-Sockets oder sogar Flash, wenn diese verfügbar sind.

Ich sollte aber auch erwähnen, dass fast jede Situation, in der der Code aufgrund von Threads blockiert werden kann, mit Node.js besser angegangen werden kann. Oder in jeder Situation, in der die Anwendung ereignisgesteuert sein muss.

Außerdem sagte Ryan Dahl in einem Vortrag, dass ich einmal anwesend war, dass die Node.js-Benchmarks in Bezug auf reguläre alte HTTP-Anfragen eng mit Nginx konkurrieren. Wenn wir also mit Node.js erstellen, können wir unsere normalen Ressourcen recht effektiv bereitstellen, und wenn wir das ereignisgesteuerte Material benötigen, ist es bereit, damit umzugehen.

Außerdem ist die ganze Zeit nur JavaScript. Lingua Franca auf dem ganzen Stapel.

Gründe für die Verwendung von NodeJS:

• Es wird Javascript ausgeführt, sodass Sie auf Server und Client dieselbe Sprache verwenden und sogar Code zwischen ihnen austauschen können (z. B. zur Formularüberprüfung oder zum Rendern von Ansichten an beiden Enden).

• Das ereignisgesteuerte Single-Threaded -System ist schnell, selbst wenn viele Anforderungen gleichzeitig verarbeitet werden, und im Vergleich zu herkömmlichen Java- oder ROR-Frameworks mitmehreren Threads auch einfach.

• Der ständig wachsende Pool von Paketen, auf die über NPM zugegriffen werden kann , einschließlich clientseitiger und serverseitiger Bibliotheken / Module sowie Befehlszeilentools für die Webentwicklung. Die meisten davon werden bequem auf Github gehostet, wo Sie manchmal ein Problem melden und es innerhalb weniger Stunden beheben können! Es ist schön, alles unter einem Dach zu haben, mit standardisierter Problemberichterstattung und einfachem Gabeln.

• Es ist zur Standardumgebung geworden, in der es ausgeführt werden kann Javascript-bezogene Tools und andere webbezogene Tools ausgeführt werden können , einschließlich Task-Runner, Minifiers, Verschönerer, Linters, Präprozessoren, Bundler und Analyseprozessoren.

• Es scheint gut geeignet für Prototyping, agile Entwicklung und schnelle Produktiteration .

Gründe dafür , NodeJS nicht zu verwenden:

• Es wird Javascript ausgeführt, für das keine Typprüfung zur Kompilierungszeit durchgeführt wird. Bei großen, komplexen sicherheitskritischen Systemen oder Projekten, einschließlich der Zusammenarbeit zwischen verschiedenen Organisationen, kann eine Sprache, die vertragliche Schnittstellen fördert und eine statische Typprüfung ermöglicht , Ihnen einige Debugging-Zeit sparen (und lange Sicht Explosionen ) . (Obwohl die JVM nicht funktioniert null, verwenden Sie bitte Haskell für Ihre Kernreaktoren.)

• Hinzu kommt, dass viele der Pakete in NPM etwas roh sind und sich noch in der rasanten Entwicklung befinden. Einige Bibliotheken für ältere Frameworks haben ein Jahrzehnt lang Tests und Bugfixes durchlaufen und sind sehr stabil mittlerweile . Npmjs.org hat keinen Mechanismus zum Bewerten von Paketen , was zu einer Zunahme von Paketen geführt hat , die mehr oder weniger dasselbe tun, von denen ein großer Prozentsatz nicht mehr verwaltet wird.

• Verschachtelte Rückrufhölle. (Natürlich gibt es 20 verschiedene Lösungen ...)

• Der ständig wachsende Paketpool kann dazu führen, dass ein NodeJS-Projekt sich radikal vom nächsten unterscheidet. Aufgrund der Vielzahl der verfügbaren Optionen (z. B. Express / Sails.js / Meteor / Derby ) gibt es eine große Vielfalt an Implementierungen . Dies kann es für einen neuen Entwickler manchmal schwieriger machen, in ein Node-Projekt einzusteigen. Vergleichen Sie dies mit einem Rails- Entwickler, der sich einem bestehenden Projekt anschließt: Er sollte sich schnell mit der App vertraut machen können, da alle Rails-Apps aufgefordert werden, a zu verwenden ähnliche Struktur zu verwenden .

• Der Umgang mit Dateien kann etwas schmerzhaft sein. Dinge, die in anderen Sprachen trivial sind, wie das Lesen einer Zeile aus einer Textdatei, sind seltsam genug, um mit Node.js zu tun, dass es eine StackOverflow-Frage mit mehr als 80 Upvotes gibt. Es gibt keine einfache Möglichkeit, jeweils einen Datensatz aus einer CSV-Datei zu lesen . Usw.

Ich liebe NodeJS, es ist schnell und wild und macht Spaß, aber ich mache mir Sorgen, dass es wenig Interesse an nachweisbarer Korrektheit hat. Hoffen wir, dass wir irgendwann das Beste aus beiden Welten zusammenführen können. Ich bin gespannt, was Node in Zukunft ersetzen wird ... :)

Um es kurz zu machen:

Node.js eignet sich gut für Anwendungen mit vielen gleichzeitigen Verbindungen, und jede Anforderung benötigt nur sehr wenige CPU-Zyklen, da die Ereignisschleife (mit allen anderen Clients) während der Ausführung einer Funktion blockiert wird.

Ein guter Artikel über die Ereignisschleife in Node.js ist Mixus Tech-Blog: Die Ereignisschleife von node.js verstehen .

Ich habe ein Beispiel aus der Praxis, in dem ich Node.js verwendet habe. Die Firma, in der ich arbeite, hat einen Kunden, der eine einfache statische HTML-Website haben möchte. Diese Website dient zum Verkauf eines Artikels über PayPal und der Kunde wollte auch einen Zähler, der die Menge der verkauften Artikel anzeigt. Der Kunde erwartet eine große Anzahl von Besuchern dieser Website. Ich habe beschlossen, den Zähler mit Node.js und Express.js zu erstellen Framework zu .

Die Anwendung Node.js war einfach. Rufen Sie den Betrag der verkauften Artikel aus einer Redis- Datenbank ab, erhöhen Sie den Zähler beim Verkauf des Artikels und stellen Sie den Benutzern den Zählerwert über die API zur Verfügung .

Einige Gründe, warum ich mich in diesem Fall für Node.js entschieden habe

1. Es ist sehr leicht und schnell. In drei Wochen wurden über 200000 Besuche auf dieser Website verzeichnet, und nur minimale Serverressourcen konnten dies alles bewältigen.
2. Der Zähler ist wirklich einfach in Echtzeit zu erstellen.
3. Node.js war einfach zu konfigurieren.
4. Es stehen viele Module kostenlos zur Verfügung. Zum Beispiel habe ich ein Node.js-Modul für PayPal gefunden.

In diesem Fall war Node.js eine großartige Wahl.

Die wichtigsten Gründe, um Ihr nächstes Projekt mit Node zu starten ...

• Alle coolsten Typen sind begeistert ... also muss es es Spaß machen.
• Sie können sich am Kühler aufhalten und viele Node-Abenteuer erleben, mit denen Sie angeben können.
• Sie sind ein Penny Pincher, wenn es um Cloud-Hosting-Kosten geht.
• Wurde dort mit Rails gemacht
• Sie hassen IIS-Bereitstellungen
• Ihr alter IT-Job wird ziemlich langweilig und Sie wünschen sich, Sie wären in einem glänzenden neuen Start-up.

Was zu erwarten ist ...

• Mit Express fühlen Sie sich sicher und geschützt, ohne die gesamte Server-Bloatware, die Sie nie benötigt haben.
• Läuft wie eine Rakete und skaliert gut.
• Du träumst es. Sie haben es installiert. Das Knotenpaket repo npmjs.org ist das weltweit größte Ökosystem von Open Source-Bibliotheken.
• Ihr Gehirn wird im Land der verschachtelten Rückrufe Zeit verlieren ...
• ... bis Sie lernen, Ihre Versprechen zu halten .
• Fortsetzung und Reisepass sind Ihre neuen API-Freunde.
• Das Debuggen von meistens asynchronem Code wird umm ... interessant .
• Zeit für alle Noders, Typescript zu beherrschen .

Wer benutzt es?

• PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
• Hier ist, warum sie zu Node gewechselt sind .

Es gibt nichts Schöneres als Silver Bullet. Alles ist mit Kosten verbunden. Es ist, als ob Sie fettiges Essen essen, Sie werden Ihre Gesundheit gefährden und gesundes Essen enthält keine Gewürze wie fettiges Essen. Es ist eine individuelle Entscheidung, ob sie Gesundheit oder Gewürze wie in ihrem Essen wollen. Genauso wie Node.js in einem bestimmten Szenario verwendet wird. Wenn Ihre App nicht in dieses Szenario passt, sollten Sie sie für Ihre App-Entwicklung nicht berücksichtigen. Ich denke nur an dasselbe:

Wann wird Node.JS verwendet?

1. Wenn Ihr serverseitiger Code nur sehr wenige CPU-Zyklen erfordert. In einer anderen Welt arbeiten Sie nicht blockierend und haben keinen schweren Algorithmus / Job, der viele CPU-Zyklen verbraucht.
2. Wenn Sie aus dem Javascript-Hintergrund stammen und Single Threaded-Code genau wie clientseitiges JS schreiben können.

Wann sollte Node.JS NICHT verwendet werden?

1. Ihre Serveranforderung hängt von einem Algorithmus / Job ab, der viel CPU verbraucht.

Überlegungen zur Skalierbarkeit mit Node.JS

1. Node.JS selbst verwendet nicht den gesamten Kern des zugrunde liegenden Systems und ist standardmäßig Single-Threaded. Sie müssen selbst Logik schreiben, um Multi-Core-Prozessoren zu verwenden und Multi-Threaded zu machen.

Node.JS Alternativen

Es gibt andere Optionen anstelle von Node.JS. Vert.x scheint jedoch ziemlich vielversprechend zu sein und bietet viele zusätzliche Funktionen wie Polygot und bessere Überlegungen zur Skalierbarkeit.

Eine weitere großartige Sache, die meiner Meinung nach niemand über Node.js erwähnt hat, ist die erstaunliche Community, das Paketverwaltungssystem (npm) und die Anzahl der vorhandenen Module, die Sie einschließen können, indem Sie sie einfach in Ihre package.json-Datei aufnehmen.

Mein Beitrag: nodejs eignet sich hervorragend für die Erstellung von Echtzeitsystemen wie Analytics, Chat-Apps, APIs, Ad-Servern usw. Zur Hölle, ich habe meine erste Chat-App mit nodejs und socket.io unter 2 Stunden erstellt, und das auch während der Prüfungswoche!

Bearbeiten

Es ist einige Jahre her, seit ich angefangen habe, nodejs zu verwenden, und ich habe damit viele verschiedene Dinge gemacht, einschließlich statischer Dateiserver, einfacher Analysen, Chat-Apps und vielem mehr. Dies ist meine Einstellung, wann nodejs verwendet werden soll

Wann zu verwenden

Bei der Erstellung eines Systems, bei dem Parallelität und Geschwindigkeit im Vordergrund stehen.

• Sockets nur Server wie Chat-Apps, IRC-Apps usw.
• Soziale Netzwerke, bei denen Echtzeitressourcen wie Geolokalisierung, Videostream, Audiostream usw. im Vordergrund stehen.
• Der schnelle Umgang mit kleinen Datenblöcken wie bei einer Analytics-Webanwendung.
• Als Belichtung eines REST nur API.

Wann nicht verwenden

Es ist ein sehr vielseitiger Webserver, sodass Sie ihn überall verwenden können, aber wahrscheinlich nicht an diesen Orten.

• Einfache Blogs und statische Seiten.
• Genau wie ein statischer Dateiserver.

Denken Sie daran, dass ich nur pingelig bin. Für statische Dateiserver ist Apache vor allem deshalb besser, weil es weit verbreitet ist. Die NodeJS-Community ist im Laufe der Jahre größer und reifer geworden, und man kann mit Sicherheit sagen, dass NodeJS fast überall verwendet werden können, wenn Sie Ihre eigene Hosting-Wahl haben.

Es kann wo verwendet werden

• Anwendungen, die stark ereignisgesteuert und stark an E / A gebunden sind
• Anwendungen, die eine große Anzahl von Verbindungen zu anderen Systemen verarbeiten
• Echtzeitanwendungen (Node.js wurde von Grund auf für Echtzeit entwickelt und ist einfach zu bedienen.)
• Anwendungen, die Unmengen von Informationen jonglieren, die zu und von anderen Quellen gestreamt werden
• Hoher Verkehr, skalierbare Anwendungen
• Mobile Apps, die mit der Plattform-API und -Datenbank kommunizieren müssen, ohne viel Datenanalyse durchführen zu müssen
• Erstellen Sie vernetzte Anwendungen
• Anwendungen, die sehr oft mit dem Backend sprechen müssen

Im Bereich Mobile haben sich Unternehmen zur Hauptsendezeit bei ihren mobilen Lösungen auf Node.js verlassen. Überprüfen Sie, warum?

LinkedIn ist ein bekannter Benutzer. Ihr gesamter mobiler Stack basiert auf Node.js. Sie gingen von 15 Servern mit 15 Instanzen auf jedem physischen Computer auf nur 4 Instanzen über - das kann den doppelten Datenverkehr verarbeiten!

eBay hat ql.io gestartet, eine Web-Abfragesprache für HTTP-APIs, die Node.js als Laufzeitstapel verwendet. Sie konnten eine reguläre Ubuntu-Workstation in Entwicklerqualität so einstellen, dass mehr als 120.000 aktive Verbindungen pro node.js-Prozess verarbeitet werden, wobei jede Verbindung etwa 2 KB Speicher benötigt!

Walmart hat seine mobile App für die Verwendung von Node.js überarbeitet und die JavaScript-Verarbeitung auf den Server übertragen.

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

Knoten am besten für die gleichzeitige Bearbeitung von Anfragen -

Beginnen wir also mit einer Geschichte. In den letzten 2 Jahren arbeite ich an JavaScript und entwickle das Web-Frontend und es macht mir Spaß. Backend-Leute stellen uns einige APIs zur Verfügung, die in Java, Python (es ist uns egal) geschrieben sind, und wir schreiben einfach einen AJAX-Aufruf, holen unsere Daten und raten Sie mal! wir sind fertig. Aber in Wirklichkeit ist es nicht so einfach. Wenn die Daten, die wir erhalten, nicht korrekt sind oder ein Serverfehler vorliegt, stecken wir fest und müssen unsere Back-End-Leute per E-Mail oder Chat kontaktieren (manchmal auch auf WhatsApp :).) Dies ist nicht cool. Was wäre, wenn wir unsere APIs in JavaScript schreiben und diese APIs von unserem Frontend aus aufrufen würden? Ja, das ist ziemlich cool, denn wenn wir auf ein Problem in der API stoßen, können wir es untersuchen. Erraten Sie, was ! Sie können dies jetzt tun, wie? - Der Knoten ist für Sie da.

Ok stimmte zu, dass Sie Ihre API in JavaScript schreiben können, aber was ist, wenn ich mit dem obigen Problem einverstanden bin? Haben Sie einen anderen Grund, Node for Rest API zu verwenden?

Hier beginnt also die Magie. Ja, ich habe andere Gründe, Knoten für unsere APIs zu verwenden.

Kehren wir zu unserem traditionellen Rest-API-System zurück, das entweder auf Blockierungsvorgängen oder auf Threading basiert. Angenommen, es treten zwei gleichzeitige Anforderungen auf (r1 und r2), für die jeweils eine Datenbankoperation erforderlich ist. Also im traditionellen System, was passieren wird:

1. Wartezeit: Unser Server beginnt mit der Bearbeitung der r1Anfrage und wartet auf die Antwort auf die Anfrage. Nach Abschluss des r1Vorgangs beginnt der Server mit der Bereitstellung r2und führt dies auf die gleiche Weise aus. Warten ist also keine gute Idee, weil wir nicht so viel Zeit haben.

2. Einfädelweg: Unser Server erstellt zwei Threads für beide Anforderungen r1und r2erfüllt ihren Zweck nach dem Abfragen der Datenbank. Dies ist sehr schnell. Es ist jedoch speicherintensiv, da Sie sehen können, dass wir zwei Threads gestartet haben. Das Problem steigt auch, wenn beide Anforderungen dieselben Daten abfragen dann müssen Sie sich mit Deadlock-Problemen befassen. Es ist also besser als zu warten, aber es gibt immer noch Probleme.

Nun ist hier, wie Knoten es tun wird:

3. Nodeway: Wenn dieselbe gleichzeitige Anforderung im Knoten eingeht, registriert er ein Ereignis mit seinem Rückruf und fährt fort. Er wartet nicht auf die Antwort der Abfrage auf eine bestimmte Anforderungr1 Anforderung die Ereignisschleife des Knotens (ja, es gibt eine Ereignisschleife in einem Knoten, der diesem Zweck dient.) Registrieren Sie ein Ereignis mit seiner Rückruffunktion und fahren Sie fort, um die r2Anforderung zu bedienen, und registrieren Sie sein Ereignis auf ähnliche Weise mit seinem Rückruf. Immer wenn eine Abfrage beendet ist, löst sie das entsprechende Ereignis aus und führt den Rückruf vollständig aus, ohne unterbrochen zu werden.

Also kein Warten, kein Threading, kein Speicherverbrauch - ja, dies ist der Knotenpunkt für die Bereitstellung der Rest-API.

Mein weiterer Grund , Node.js für ein neues Projekt zu wählen, ist:

Sie können eine reine Cloud-basierte Entwicklung durchführen

Ich habe Cloud9 IDE für eine Weile verwendet und jetzt kann ich mir nicht vorstellen, dass es ohne es alle Entwicklungslebenszyklen abdeckt. Alles was Sie brauchen ist ein Browser und Sie können jederzeit und überall auf jedem Gerät codieren. Sie müssen den Code nicht auf einem Computer einchecken (wie zu Hause) und dann auf einem anderen Computer auschecken (wie am Arbeitsplatz).

Natürlich gibt es vielleicht eine Cloud-basierte IDE für andere Sprachen oder Plattformen (Cloud 9 IDE fügt auch Unterstützung für andere Sprachen hinzu), aber die Verwendung von Cloud 9 für die Entwicklung von Node.j ist für mich wirklich eine großartige Erfahrung.

Eine weitere Möglichkeit, die der Knoten bietet, ist die Möglichkeit, mehrere v8-Instanes des Knotens mithilfe des untergeordneten Prozesses des Knotens ( childProcess.fork () zu erstellen, für die jeweils 10 MB Speicher gemäß den Dokumenten erforderlich sind), ohne dass dies Auswirkungen auf den Hauptprozess hat, auf dem der Server ausgeführt wird. Das Auslagern eines Hintergrundjobs, der eine enorme Serverlast erfordert, wird zum Kinderspiel, und wir können sie bei Bedarf problemlos beenden.

Ich habe viel mit Knoten gearbeitet und in den meisten Apps, die wir erstellen, sind gleichzeitig Serververbindungen erforderlich, daher ein starker Netzwerkverkehr. Frameworks wie Express.js und die neuen Koajs (die die Callback-Hölle beseitigt haben) haben die Arbeit am Knoten noch einfacher gemacht.

Asbest Longjohns anziehen ...

Gestern mein Titel mit Packt Publications, Reactive Programming mit JavaScript . Es ist nicht wirklich ein Node.js-zentrierter Titel; Die ersten Kapitel sollen die Theorie behandeln, und die späteren codeintensiven Kapitel behandeln die Praxis. Da ich es nicht wirklich für angebracht hielt, den Lesern keinen Webserver zur Verfügung zu stellen, schien Node.js bei weitem die naheliegende Wahl zu sein. Der Fall wurde geschlossen, bevor er überhaupt geöffnet wurde.

Ich hätte einen sehr rosigen Blick auf meine Erfahrungen mit Node.js werfen können. Stattdessen war ich ehrlich über gute und schlechte Punkte, denen ich begegnet bin.

Lassen Sie mich einige Zitate einfügen, die hier relevant sind:

Warnung: Node.js und sein Ökosystem sind heiß genug, um dich schwer zu verbrennen!

Als ich Assistent eines Lehrers in Mathematik war, war einer der nicht offensichtlichen Vorschläge, die mir gesagt wurden, einem Schüler nicht zu sagen, dass etwas „einfach“ sei. Der Grund war im Nachhinein etwas offensichtlich: Wenn Sie den Leuten sagen, dass etwas einfach ist, kann sich jemand, der keine Lösung sieht, (noch mehr) dumm fühlen, weil er nicht nur nicht versteht, wie er das Problem lösen kann, sondern auch das Problem Sie sind zu dumm, um zu verstehen, dass es einfach ist!

Es gibt Fallstricke, die nicht nur Leute aus Python / Django nerven, die die Quelle sofort neu laden, wenn Sie etwas ändern. Bei Node.js ist das Standardverhalten, dass bei einer Änderung die alte Version bis zum Ende der Zeit oder bis zum manuellen Stoppen und Neustarten des Servers aktiv bleibt. Dieses unangemessene Verhalten nervt Pythonistas nicht nur. Es irritiert auch native Node.js-Benutzer, die verschiedene Problemumgehungen bereitstellen. Die StackOverflow-Frage „Automatisches Neuladen von Dateien in Node.js“ hat zum Zeitpunkt dieses Schreibens über 200 Upvotes und 19 Antworten. Eine Bearbeitung leitet den Benutzer zu einem Nanny-Skript, Node-Supervisor, mit der Homepage unter http://tinyurl.com/reactjs-node-supervisor. Dieses Problem bietet neuen Benutzern die Möglichkeit, sich dumm zu fühlen, weil sie dachten, sie hätten das Problem behoben, aber das alte, fehlerhafte Verhalten bleibt völlig unverändert. Und es ist leicht zu vergessen, den Server zu bouncen; Ich habe das schon mehrmals gemacht. Und die Botschaft, die ich geben möchte, lautet: „Nein, du bist nicht dumm, weil dieses Verhalten von Node.js dir den Rücken gebissen hat. Es ist nur so, dass die Designer von Node.js keinen Grund sahen, hier angemessenes Verhalten zu zeigen. Versuchen Sie, damit umzugehen, vielleicht nehmen Sie ein wenig Hilfe vom Node-Supervisor oder einer anderen Lösung, aber gehen Sie bitte nicht weg und fühlen Sie sich dumm. Du bist nicht derjenige mit dem Problem; Das Problem liegt im Standardverhalten von Node.js. “

Dieser Abschnitt wurde nach einigen Debatten belassen, gerade weil ich nicht den Eindruck erwecken möchte, dass es einfach ist. Ich schneide mir wiederholt die Hände, während ich die Dinge zum Laufen bringe, und ich möchte Schwierigkeiten nicht beseitigen und Sie darauf einstellen, zu glauben, dass es einfach ist, Node.js und sein Ökosystem gut zu funktionieren, und wenn es auch für Sie nicht einfach ist Sie wissen nicht, was Sie tun. Wenn Sie mit Node.js nicht auf unangenehme Schwierigkeiten stoßen, ist das wunderbar. Wenn Sie dies tun, würde ich hoffen, dass Sie nicht weggehen und das Gefühl haben: "Ich bin dumm - mit mir muss etwas nicht stimmen." Sie sind nicht dumm, wenn Sie böse Überraschungen im Umgang mit Node.js erleben. Du bist es nicht! Es ist Node.js und sein Ökosystem!

Der Anhang, den ich nach dem steigenden Crescendo in den letzten Kapiteln und dem Abschluss nicht wirklich wollte, spricht über das, was ich im Ökosystem finden konnte, und bot eine Problemumgehung für den schwachsinnigen Literalismus:

Eine andere Datenbank, die perfekt zu passen schien und möglicherweise noch einlösbar ist, ist eine serverseitige Implementierung des HTML5-Schlüsselwertspeichers. Dieser Ansatz hat den entscheidenden Vorteil einer API, die die meisten guten Front-End-Entwickler gut genug verstehen. Im Übrigen ist es auch eine API, die die meisten nicht so guten Front-End-Entwickler gut genug verstehen. Während mit dem Paket node-localstorage kein Zugriff auf die Wörterbuchsyntax angeboten wird (Sie möchten localStorage.setItem (Schlüssel, Wert) oder localStorage.getItem (Schlüssel) verwenden, nicht localStorage [Schlüssel]), wird die vollständige localStorage-Semantik implementiert , einschließlich eines Standardkontingents von 5 MB - WARUM ?Müssen serverseitige JavaScript-Entwickler vor sich selbst geschützt werden?

Für clientseitige Datenbankfunktionen ist ein Kontingent von 5 MB pro Website eine großzügige und nützliche Menge an Freiraum, damit Entwickler damit arbeiten können. Sie könnten eine viel niedrigere Quote festlegen und Entwicklern dennoch eine unermessliche Verbesserung gegenüber dem Hinken zusammen mit der Cookie-Verwaltung bieten. Ein Limit von 5 MB eignet sich nicht sehr schnell für die clientseitige Verarbeitung von Big Data, aber es gibt eine wirklich recht großzügige Erlaubnis, mit der einfallsreiche Entwickler viel tun können. Auf der anderen Seite ist 5 MB kein besonders großer Teil der meisten kürzlich gekauften Festplatten. Wenn Sie und eine Website sich nicht darüber einig sind, wie viel Speicherplatz angemessen genutzt wird, oder wenn eine Website einfach nur bescheuert ist, kostet dies nicht wirklich Sie viel und Sie sind nicht in der Gefahr einer überfüllten Festplatte, es sei denn, Ihre Festplatte war bereits zu voll.

Es kann jedoch vorsichtig darauf hingewiesen werden, dass Sie, wenn Sie derjenige sind, der Code für Ihren Server schreibt, keinen zusätzlichen Schutz benötigen, um Ihre Datenbank auf eine tolerierbare Größe von 5 MB zu bringen. Die meisten Entwickler benötigen und wollen keine Tools, die als Kindermädchen fungieren und sie vor dem Speichern von mehr als 5 MB serverseitiger Daten schützen. Und das 5-MB-Kontingent, das auf der Clientseite ein goldener Balanceakt ist, ist auf einem Node.js-Server ziemlich albern. (Bei einer Datenbank für mehrere Benutzer, wie in diesem Anhang beschrieben, wird möglicherweise etwas schmerzhaft darauf hingewiesen, dass dies nicht 5 MB pro Benutzerkonto sind, es sei denn, Sie erstellen für jedes Benutzerkonto eine separate Datenbank auf der Festplatte. Dies sind 5 MB, die von beiden Benutzern gemeinsam genutzt werden alle Benutzerkonten zusammen. Das könnte bekommen schmerzhaft werdenWenn Sie viral werden!) In der Dokumentation heißt es, dass das Kontingent anpassbar ist. Vor einer Woche wurde jedoch eine E-Mail an den Entwickler gesendet, in der er gefragt wurde, wie das Kontingent geändert werden soll, ebenso wie die Frage von StackOverflow. Die einzige Antwort, die ich finden konnte, ist in der Github CoffeeScript-Quelle, wo sie als optionales zweites ganzzahliges Argument für einen Konstruktor aufgeführt ist. Das ist also einfach genug, und Sie können ein Kontingent angeben, das einer Festplatten- oder Partitionsgröße entspricht. Abgesehen von der Portierung einer Funktion, die keinen Sinn ergibt, hat der Autor des Tools eine Standardkonvention zur Interpretation von 0 als „unbegrenzt“ für eine Variable oder Funktion, bei der eine Ganzzahl eine maximale Grenze für eine bestimmte Ressourcennutzung angeben soll, nicht vollständig befolgt. Das Beste, was Sie mit dieser Fehlfunktion tun können, ist wahrscheinlich anzugeben, dass das Kontingent Unendlich ist:

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

Zwei Kommentare der Reihe nach austauschen:

Die Menschen haben sich unnötigerweise ständig mit JavaScript als Ganzes in den Fuß geschossen, und ein Teil von JavaScript, das zu einer respektablen Sprache gemacht wurde, war ein Douglas Crockford, der im Wesentlichen sagte: „JavaScript als Sprache hat einige wirklich gute und einige wirklich schlechte Teile. Hier sind die guten Teile. Vergiss einfach, dass noch etwas da ist. “ Vielleicht wird das heiße Node.js-Ökosystem seinen eigenen „Douglas Crockford“ entwickeln, der sagt: „Das Node.js-Ökosystem ist ein kodierender Wilder Westen, aber es gibt einige echte Juwelen zu finden. Hier ist eine Roadmap. Hier sind die Bereiche, die um fast jeden Preis zu vermeiden sind. Hier sind die Gebiete mit einigen der reichsten Gehaltsabrechnungen, die in JEDER Sprache oder Umgebung zu finden sind. “

Vielleicht kann jemand anderes diese Worte als Herausforderung nehmen und Crockfords Führung folgen und „die guten Teile“ und / oder „die besseren Teile“ für Node.js und sein Ökosystem aufschreiben. Ich würde eine Kopie kaufen!

Angesichts des Enthusiasmus und der Arbeitszeit bei allen Projekten kann es in einem oder zwei oder drei Jahren gerechtfertigt sein, alle Bemerkungen über ein unreifes Ökosystem, die zum Zeitpunkt dieses Schreibens gemacht wurden, scharf zu mildern. In fünf Jahren könnte es wirklich Sinn machen zu sagen: „Das Node.js-Ökosystem von 2015 hatte mehrere Minenfelder. Das Node.js-Ökosystem für 2020 hat mehrere Paradiese. “

Wenn Ihre Anwendung hauptsächlich Web-APIs oder andere Io-Kanäle an eine Benutzeroberfläche bindet oder nimmt, ist node.js möglicherweise eine gute Wahl für Sie, insbesondere wenn Sie die größtmögliche Skalierbarkeit erzielen möchten oder wenn Ihre Hauptsprache im Leben ist ist Javascript (oder eine Art Javascript-Transpiler). Wenn Sie Microservices erstellen, ist node.js ebenfalls in Ordnung. Node.js eignet sich auch für jedes kleine oder einfache Projekt.

Das Hauptverkaufsargument ist, dass Front-Ender eher die Verantwortung für Back-End-Produkte übernehmen als für die typische Kluft. Ein weiteres gerechtfertigtes Verkaufsargument ist, wenn Ihre Belegschaft zunächst auf Javascript ausgerichtet ist.

Ab einem bestimmten Punkt können Sie Ihren Code jedoch nicht ohne schreckliche Hacks skalieren, um Modularität, Lesbarkeit und Flusskontrolle zu erzwingen. Einige Leute mögen diese Hacks, insbesondere wenn sie aus einem ereignisgesteuerten Javascript-Hintergrund stammen, scheinen sie vertraut oder verzeihlich zu sein.

Insbesondere wenn Ihre Anwendung synchrone Abläufe ausführen muss, beginnen Sie, über halbgebackene Lösungen zu bluten, die Sie in Bezug auf Ihren Entwicklungsprozess erheblich verlangsamen. Wenn Ihre Anwendung rechenintensive Teile enthält, gehen Sie vorsichtig vor (nur) node.js. Vielleicht lindern http://koajs.com/ oder andere Neuheiten diese ursprünglich heiklen Aspekte, verglichen mit dem Zeitpunkt, als ich ursprünglich node.js verwendet oder dies geschrieben habe.

Ich kann einige Punkte mitteilen, wo und warum Knoten js verwendet werden sollen.

1. Für Echtzeitanwendungen wie Chat und bessere gemeinsame Bearbeitung verwenden wir NodeJS, da es sich um eine Ereignisbasis handelt, bei der Ereignisse und Daten vom Server an Clients gesendet werden.
2. Einfach und leicht zu verstehen, da es sich um eine Javascript-Basis handelt, auf der die meisten Menschen eine Idee haben.
3. Die meisten aktuellen Webanwendungen gehen in Richtung eckiges js & Backbone. Mit Node ist es einfach, mit clientseitigem Code zu interagieren, da beide json-Daten verwenden.
4. Viele Plugins verfügbar.

Nachteile: -

1. Node unterstützt die meisten Datenbanken, aber das Beste ist Mongodb, das komplexe Joins und andere nicht unterstützt.
2. Kompilierungsfehler ... Entwickler sollten alle Ausnahmen auf andere Weise behandeln, wenn eine Fehleranpassungsanwendung nicht mehr funktioniert, wo sie erneut manuell oder mithilfe eines Automatisierungstools gestartet werden muss.

Fazit: - Nodejs eignen sich am besten für einfache und Echtzeitanwendungen. Wenn Sie über eine sehr große Geschäftslogik und komplexe Funktionen verfügen, sollten Sie Nodejs besser nicht verwenden. Wenn Sie eine Anwendung zusammen mit dem Chat und allen Funktionen für die Zusammenarbeit erstellen möchten, kann der Knoten in bestimmten Teilen verwendet werden und sollte mit Ihrer Komforttechnologie übereinstimmen.

1. Der Knoten eignet sich hervorragend für schnelle Prototypen, aber ich würde ihn nie wieder für komplexe Aufgaben verwenden. Ich habe 20 Jahre damit verbracht, eine Beziehung zu einem Compiler aufzubauen, und ich vermisse sie auf jeden Fall.

2. Der Knoten ist besonders schmerzhaft, wenn Sie Code pflegen, den Sie eine Weile nicht besucht haben. Typinfo und Fehlererkennung bei der Kompilierung sind GUT. Warum das alles rauswerfen? Für was? Und verdammt, wenn etwas nach Süden geht, sind die Stapelspuren oft völlig nutzlos.