it-swarm.com.de

Wie entscheide ich, wann ich Node.js verwende?

Ich bin neu in dieser Art von Sachen, aber in letzter Zeit habe ich viel darüber gehört, wie gut Node.js ist. Wenn man bedenkt, wie sehr ich die Arbeit mit jQuery und JavaScript im Allgemeinen liebe, frage ich mich, wie ich entscheiden soll, wann ich Node.js verwende. Die Webanwendung, die ich vorhabe, ist so etwas wie Bitly - nimmt einige Inhalte auf und archiviert sie.

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

  • ist ein Befehlszeilentool, das als regulärer Webserver ausgeführt werden kann und das das Ausführen von JavaScript-Programmen ermöglicht
  • nutzt die großartige V8 JavaScript Engine
  • ist sehr gut, wenn Sie mehrere Dinge gleichzeitig erledigen müssen
  • ist ereignisbasiert, so dass all die wunderbaren Ajax - ähnlichen Dinge auf der Serverseite erledigt werden können
  • lässt 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:

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 es mag PHP , Python und Ruby . Ich verstehe, dass es wirklich von der Sachkenntnis abhängt, die man in einer Sprache hat, aber meine Frage fällt eher in die allgemeine Kategorie: Wann ist ein bestimmtes Framework zu verwenden und für welche Art von Problemen ist es besonders geeignet?

2198
Legend

Sie haben hervorragend zusammengefasst, was an Node.js großartig ist. Meines Erachtens ist Node.js besonders für Anwendungen geeignet, bei denen Sie eine dauerhafte Verbindung vom Browser zurück zum Server aufrechterhalten möchten. Mit einer als "long-polling" bekannten Technik können Sie eine Anwendung schreiben, die Aktualisierungen in Echtzeit an den Benutzer sendet. Ein langes Polling vieler Giganten im Web, wie Ruby on Rails oder Django , würde den Server immens belasten, da jeder aktive Client einen Serverprozess auffrisst. Diese Situation entspricht einem Tarpit Angriff. Wenn Sie so etwas wie Node.js verwenden, muss der Server keine separaten Threads für jede offene Verbindung 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. Node.js ist immer dann eine gute Option, wenn Sie diese Art von langem Polling durchführen möchten.

Es ist erwähnenswert, dass Ruby und Python beide Werkzeuge haben, um solche Dinge zu tun ( eventmachine bzw. twisted ), Aber diese Node.js macht es außergewöhnlich gut und von Grund auf. JavaScript ist in Bezug auf ein Callback-basiertes Concurrency-Modell außergewöhnlich gut positioniert und zeichnet sich hier aus. Das Serialisieren und Deserialisieren mit JSON, das sowohl auf dem Client als auch auf dem Server ausgeführt wird, ist ziemlich raffiniert.

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 vermuten, dass dies die Zukunft der Webentwicklung sein könnte. Ich kann aus Erfahrung sagen, dass das Schreiben von Code in Meteor eine Menge Spaß macht. Ein großer Teil davon besteht darin, weniger Zeit damit zu verbringen, darüber nachzudenken, wie Sie Ihre Daten umstrukturieren, damit der Code, der im Browser ausgeführt wird, problemlos funktioniert manipuliere es und gib es zurück.

Hier ist ein Artikel über Pyramid und Long Polling, der sich mit ein wenig Hilfe von gevent als sehr einfach einzurichten herausstellt: TicTacToe und Long Polling with Pyramid .

1357
Benson

Ich glaube, dass Node.js am besten für Echtzeitanwendungen geeignet ist: Onlinespiele, Tools für die Zusammenarbeit, Chatrooms oder alles, was ein Benutzer (oder Roboter? Oder Sensor?) Mit der Anwendung tun muss, um von anderen Benutzern sofort gesehen zu werden. ohne Seitenaktualisierung.

Ich sollte auch erwähnen, dass Socket.IO in Kombination mit Node.js Ihre Echtzeit-Latenz noch weiter verkürzt 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.

Aber ich sollte auch erwähnen, dass fast jede Situation, in der der Code aufgrund von Threads blockiert werden könnte, 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 daran teilgenommen habe, dass die Node.js-Benchmarks Nginx für reguläre alte HTTP-Anforderungen sehr nahe kommen. Wenn wir also mit Node.js bauen, können wir unsere normalen Ressourcen sehr effektiv bedienen, und wenn wir das ereignisgesteuerte Zeug brauchen, ist es bereit, damit umzugehen.

Plus es ist alles JavaScript die ganze Zeit. Lingua Franca auf dem ganzen Stapel.

409
fisherwebdev

Gründe für die Verwendung von NodeJS:

  • Es wird Javascript ausgeführt, sodass Siedieselbe Spracheauf Server und Client 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 System Single-Threaded ist schnell , auch wenn viele Anfragen gleichzeitig bearbeitet werden, und auch einfach Im Vergleich zu herkömmlichen Multi-Threaded Java oder ROR-Frameworks.

  • Der ständig wachsende Pool vonPaketen , auf den über NPM zugegriffen werden kann, einschließlich clientseitiger und serverseitiger Bibliotheken/Module sowie Befehlszeilentools für Web Entwicklung. 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 Problemmeldung und einfachem Gabeln.

  • Es ist zur Standardumgebung geworden, in derTools mit Javascript-Bezugund andereTools mit Web-Bezugausgeführt werden müssen. Dazu gehören Task Runner, Minifier, Beautifier, Linters, Preprocessors, Bundler und Analytics-Prozessoren.

  • Es scheint ziemlich geeignet für Prototyping, agile Entwicklung undschnelle Produktiteration.

GründenotNodeJS zu verwenden:

  • Es wird Javascript ausgeführt, das keine Typprüfung zur Kompilierungszeit hat. Für große, komplexesicherheitskritischeSysteme oder Projekte, einschließlich der Zusammenarbeit zwischen verschiedenen Organisationen, eine Sprache, dievertragliche Schnittstellenund bietetstatische Typprüfungkann Ihnen auf lange Sicht Zeit beim Debuggen (und Explosionen ) sparen. (Obwohl die JVM mit null feststeckt, verwenden Sie bitte Haskell für Ihre Kernreaktoren.)

  • Hinzu kommt, dass viele der Pakete in NPM ein wenigrawsind und sich noch in einer rasanten Entwicklung befinden. Einige Bibliotheken für ältere Frameworks haben ein Jahrzehnt lang Tests und Bugfixes hinter sich und sind mittlerweile sehrstable. 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 gepflegt wird.

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

  • Der ständig wachsende Pool an Paketen kann dazu führen, dass ein NodeJS-Projektradikal vom nächstenabweicht. Aufgrund der Vielzahl der verfügbaren Optionen gibt es eine große Vielfalt an Implementierungen (z. B. Express/ Sails.js / Meteor / Derby ). Dies kann es für einen neuen Entwickler manchmal schwieriger machen, in ein Node Projekt einzusteigen. Vergleichen Sie dies damit, dass einRailsEntwickler einem vorhandenen Projekt beitritt: Er sollte in der Lage sein, sich schnell mit der App vertraut zu machen, da alle Rails Apps empfohlen werden Verwenden Sie eineähnliche Struktur.

  • Der Umgang mit Akten kann etwas mühsam 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, einen Datensatz gleichzeitig 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 Beweisrichtigkeit hat. Hoffen wir, dass wir irgendwann das Beste aus beiden Welten zusammenführen können. Ich bin gespannt, was Node in Zukunft ersetzen wird ... :)

209
joeytwiddle

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: Grundlegendes zur Ereignisschleife in node.js .

207
stewe

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 mit Paypal und der Kunde wollte auch einen Zähler, der die Anzahl der verkauften Artikel anzeigt. Der Kunde erwartet eine große Anzahl von Besuchern dieser Website. Ich entschied mich, den Zähler mit Node.js und dem Express.js Framework zu erstellen.

Die Anwendung Node.js war einfach. Holen Sie sich den Betrag der verkauften Artikel aus einer Redis -Datenbank, erhöhen Sie den Zähler, wenn der Artikel verkauft wird, und stellen Sie den Zählerwert den Benutzern über 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. Innerhalb von drei Wochen wurden auf dieser Website über 200.000 Besuche verzeichnet, und mit minimalen Serverressourcen konnte dies alles bewältigt werden.
  2. Der Zähler ist wirklich einfach zu machen, um in Echtzeit zu sein.
  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.

127
Joonas

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

  • Alle coolsten Typen sind begeistert ... also muss es Spaß machen .
  • Sie können an der Kühlbox rumhängen und mit vielen Node Abenteuern prahlen.
  • Sie sind ein Penny Pincher, wenn es um Cloud-Hosting-Kosten geht.
  • Wurde dort gemacht, dass mit Rails
  • 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 geborgen, ohne die gesamte Server-Bloatware, die Sie nie gebraucht haben.
  • Läuft wie eine Rakete und skaliert gut.
  • Du träumst es. Du hast es installiert. Das Knotenpaket repo npmjs.org ist das weltweit größte Ökosystem für Open Source-Bibliotheken.
  • Ihr Gehirn wird im Land der verschachtelten Rückrufe Zeit verlieren ...
  • ... bis Sie lernen, Ihre Versprechen zu halten.
  • Sequelize und Passport sind deine neuen API-Freunde.
  • Das Debuggen von größtenteils asynchronem Code wird umm ... interessant .
  • Zeit für alle Noder zu meistern TypeScript .

Wer benutzt es?

  • Paypal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
  • Hier ist der Grund, warum sie zu Node gewechselt .
105
Tony O'Hagan

Es gibt nichts Schöneres als Silver Bullet. Alles ist mit Kosten verbunden. Es ist wie wenn Sie fettiges Essen essen, Sie werden Ihre Gesundheit gefährden und gesundes Essen kommt nicht mit Gewürzen wie fettigem Essen. Es ist die individuelle Wahl, ob sie Gesundheit oder Gewürze wie in ihrem Essen wollen. Genauso, wie Node.js in einem bestimmten Szenario verwendet werden. 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 soll Node.JS verwendet werden?

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

Wann soll Node.JS NICHT verwendet werden?

  1. Ihre Serveranfrage ist abhängig von einem Algorithmus/Job, der viel CPU verbraucht.

Überlegungen zur Skalierbarkeit mit Node.JS

  1. Node.JS selbst nutzt nicht den gesamten Kern des zugrunde liegenden Systems und ist standardmäßig single-threaded. Sie müssen die Logik selbst schreiben, um den Multi-Core-Prozessor zu nutzen und ihn multi-threaded zu machen.

Node.JS Alternatives

Anstelle von Node.JS kann jedoch auch eine andere Option verwendet werden. Vert.x scheint ziemlich vielversprechend zu sein und enthält viele zusätzliche Funktionen wie Polygot und Überlegungen zur besseren Skalierbarkeit.

60
ajay

Eine weitere großartige Sache, die glaube ich niemand über Node.js erwähnt hat, ist die erstaunliche Community, das Paketverwaltungssystem (npm) und die Anzahl der Module, die Sie einbinden können, indem Sie sie einfach in Ihre einbinden package.json Datei.

41
BoxerBucks

Mein Beitrag: nodejs ist großartig, um Echtzeitsysteme wie Analysen, Chat-Apps, APIs, Ad-Server usw. zu erstellen. Zum Teufel, ich habe meine erste Chat-App mit nodejs und socket.io in weniger als 2 Stunden erstellt, und das auch während der Prüfungswoche!

Bearbeiten

Es ist einige Jahre her, seit ich NodeJS benutze, und ich habe damit viele verschiedene Dinge gemacht, darunter statische Dateiserver, einfache Analysen, Chat-Apps und vieles mehr. Dies ist meine Einstellung zur Verwendung von nodejs

Wann zu verwenden

Bei der Herstellung von Systemen, bei denen Nebenläufigkeit und Geschwindigkeit im Vordergrund stehen.

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

Wann nicht verwenden

Es ist ein sehr vielseitiger Webserver, so dass Sie es verwenden können, wo immer Sie wollen, aber wahrscheinlich nicht an diesen Orten.

  • Einfache Blogs und statische Websites.
  • Nur als statischer Dateiserver.

Denken Sie daran, dass ich nur pingelig bin. Bei statischen Dateiservern ist Apache vor allem deshalb besser, weil es allgemein verfügbar ist. Die NodeJS-Community ist im Laufe der Jahre größer und ausgereifter geworden, und man kann mit Sicherheit sagen, dass NodeJS nahezu überall verwendet werden können, wenn Sie Ihr eigenes Hosting auswählen.

37
shash7

Es kann wo verwendet werden

  • Anwendungen, die stark ereignisgesteuert und stark E/A-gebunden sind
  • Anwendungen, die eine große Anzahl von Verbindungen zu anderen Systemen verwalten
  • Echtzeitanwendungen (Node.js wurde von Grund auf auf Echtzeit und einfache Bedienung ausgelegt.)
  • Anwendungen, die mit unzähligen Informationen jonglieren, die von und zu anderen Quellen übertragen werden
  • Hohe Zugriffszahlen, 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 Back-End kommunizieren müssen

Im Bereich Mobile vertrauen Prime-Time-Unternehmen bei ihren mobilen Lösungen auf Node.js. Warum?

LinkedIn ist ein bekannter Benutzer. Ihr gesamter mobiler Stack basiert auf Node.js. Sie liefen von 15 Servern mit 15 Instanzen auf jeder physischen Maschine auf nur 4 Instanzen über - das kann den doppelten Datenverkehr bewältigen!

eBay hat ql.io gestartet, eine Webabfragesprache für HTTP-APIs, die Node.js als Laufzeitstapel verwendet. Sie waren in der Lage, eine Ubuntu-Workstation in Entwicklerqualität so zu optimieren, dass sie mehr als 120.000 aktive Verbindungen pro node.js-Prozess verarbeitet, wobei jede Verbindung etwa 2 KB Arbeitsspeicher beansprucht!

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/

30

Knoten am besten für die gleichzeitige Verarbeitung von Anforderungen -

Beginnen wir also mit einer Geschichte. In den letzten 2 Jahren habe ich an JavaScript gearbeitet und das Web-Frontend entwickelt und es macht mir Spaß. Die Back-End-Leute stellen uns einige APIs zur Verfügung, die in Java, Python (das ist uns egal) geschrieben sind, und wir schreiben einfach einen AJAX -Aufruf, holen unsere Daten und raten was! wir sind fertig. Aber in der Realität 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 geschrieben und diese APIs von unserem Front-End aus aufrufen würden? Ja, das ist ziemlich cool, denn wenn wir auf ein API-Problem stoßen, können wir es untersuchen. Erraten Sie, was ! Sie können das jetzt tun, wie? - Node ist für Sie da.

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

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

Kehren wir zu unserem traditionellen Rest-API-System zurück, das entweder auf Blocking-Operationen oder Threading basiert. Angenommen, zwei gleichzeitige Anforderungen (r1 und r2) erfordern jeweils eine Datenbankoperation. Also im traditionellen System, was passiert:

1. Wartezeit: Unser Server beginnt mit der Bearbeitung der r1 -Anforderung und wartet auf die Antwort auf die Abfrage. Nach Abschluss von r1 beginnt der Server mit der Bereitstellung von r2 und führt dies auf die gleiche Weise aus. Warten ist also keine gute Idee, weil wir nicht so viel Zeit haben.

2. Threading-Methode: Unser Server erstellt zwei Threads für beide Anforderungen r1 und r2 und erfüllt ihren Zweck nach dem Abfragen der Datenbank Sie können sehen, dass wir zwei Threads gestartet haben. Das Problem steigt, wenn beide Anfragen 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 in Node eingeht, registriert es ein Ereignis mit seinem Rückruf und wartet nicht auf die Antwort auf eine bestimmte Anforderung. Also, wenn r1 angefordert wird Kommt dann die Ereignisschleife des Knotens (ja, es gibt eine Ereignisschleife im Knoten, die diesem Zweck dient.) Registrieren Sie ein Ereignis mit seiner Rückruffunktion und fahren Sie mit der Bearbeitung der Anforderung r2 fort, und registrieren Sie auf ähnliche Weise sein Ereignis mit seinem Rückruf. Wenn eine Abfrage beendet wird, 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, das ist kein Weg, um die Rest-API zu bedienen.

20
Anshul

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

In der Lage sein, reine Cloud-basierte Entwicklung durchzuführen

Ich habe Cloud9 IDE für eine Weile benutzt und kann es mir jetzt nicht mehr vorstellen, es deckt alle Entwicklungslebenszyklen ab. Alles, was Sie brauchen, ist ein Browser, und Sie können jederzeit und überall auf allen Geräten 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 möglicherweise cloudbasierte IDE für andere Sprachen oder Plattformen (Cloud 9 IDE unterstützt auch andere Sprachen), aber die Verwendung von Cloud 9 für die Entwicklung von Node.j ist erforderlich wirklich eine tolle Erfahrung für mich.

16
Sean Zhao

Ein weiterer Vorteil von Node ist die Möglichkeit, mehrere v8-Instanzen von Node mithilfe des untergeordneten Prozesses ( childProcess.fork () jeweils 10 MB Arbeitsspeicher gemäß Dokument) zu erstellen, wodurch der Hauptprozess nicht beeinträchtigt wird Laufen den Server. So wird das Auslagern eines Hintergrundjobs, der eine enorme Serverlast erfordert, zum Kinderspiel, und wir können ihn bei Bedarf problemlos beenden.

Ich habe Node viel benutzt und in den meisten Apps, die wir bauen, sind gleichzeitig Serververbindungen erforderlich, was zu einem starken Netzwerkverkehr führt. Frameworks wie Express.js und das neue Koajs (das die Callback-Hölle beseitigt hat) haben die Arbeit am Knoten noch einfacher gemacht.

15

Asbest-Longjohns anziehen ...

Gestern mein Titel bei Packt Publications, Reactive Programming with JavaScript . Es ist nicht wirklich ein Node.js-zentrierter Titel. In den frühen Kapiteln wird die Theorie und in den späteren Kapiteln die Praxis behandelt. Da ich nicht wirklich dachte, dass es angebracht wäre, den Lesern keinen Webserver zur Verfügung zu stellen, schien Node.js bei weitem die naheliegende Wahl. Der Fall wurde geschlossen, bevor er überhaupt geöffnet wurde.

Ich hätte einen sehr rosigen Blick auf meine Erfahrung mit Node.js werfen können. Stattdessen war ich ehrlich in Bezug auf gute und schlechte Punkte, auf die ich gestoßen bin.

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

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

Als ich Assistent eines Lehrers für Mathematik war, wurde mir nicht nahegelegt, einem Schüler zu sagen, dass etwas „einfach“ sei. Der Grund dafür war im Nachhinein offensichtlich: Wenn man Leuten sagt, dass etwas einfach ist, jemand, der Wenn sie eine Lösung nicht sehen, wird sie sich möglicherweise (noch mehr) dumm fühlen, weil sie nicht nur nicht verstehen, wie sie das Problem lösen können, sondern das Problem, für das sie zu dumm sind, ist einfach!

Es gibt Fallstricke, die nicht nur Leute aus Python/Django ärgern, 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 nicht nur Pythonisten. Es irritiert auch native Node.js-Benutzer, die verschiedene Problemumgehungen anbieten. Die StackOverflow-Frage „Automatisches Neuladen von Dateien in Node.js“ hat zum Zeitpunkt des Schreibens über 200 positive Bewertungen und 19 Antworten. Eine Bearbeitung leitet den Benutzer zu einem Nanny-Skript, Node-Supervisor, mit einer Homepage unter http://tinyurl.com/reactjs-node-supervisor . Dieses Problem bietet neuen Benutzern die großartige Gelegenheit, sich dumm zu fühlen, weil sie dachten, das Problem behoben zu haben, aber das alte, fehlerhafte Verhalten ist völlig unverändert. Und es ist leicht zu vergessen, den Server zu bouncen. Das habe ich schon mehrmals gemacht. Und die Nachricht, die ich geben möchte, lautet: "Nein, du bist nicht dumm, weil dir dieses Verhalten von Node.js den Rücken gebissen hat. Die Designer von Node.js sahen lediglich keinen Grund, hier ein angemessenes Verhalten vorzusehen. Versuchen Sie, damit umzugehen, und nehmen Sie vielleicht ein wenig Hilfe vom Knoten-Supervisor oder einer anderen Lösung, aber gehen Sie nicht weg, weil Sie sich dumm fühlen. Sie sind nicht derjenige mit dem Problem. Das Problem liegt im Standardverhalten von Node.j. "

Dieser Abschnitt wurde nach einigen Debatten eingestellt, 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 und Probleme nicht beseitigen Stellen Sie sich vor, Sie glauben, dass es eine einfache Sache ist, Node.js und sein Ökosystem in Betrieb zu nehmen, und wenn es auch für Sie nicht einfach ist, wissen Sie 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 das Gefühl verlieren, "Ich bin dumm - mit mir muss etwas nicht in Ordnung sein." Sie sind nicht dumm, wenn Sie böse Überraschungen mit Node.js erleben. Du bist es nicht! Es ist Node.js und sein Ökosystem!

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

Eine andere Datenbank, die perfekt zu Ihnen passt 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. In diesem Fall handelt es sich auch um eine API, die die meisten weniger guten Front-End-Entwickler gut genug verstehen. Mit dem Knoten-localstorage-Paket wird jedoch die vollständige localStorage-Semantik implementiert, während der Zugriff auf die Wörterbuchsyntax nicht angeboten wird (Sie möchten localStorage.setItem (Schlüssel, Wert) oder localStorage.getItem (Schlüssel) verwenden, nicht localStorage [Schlüssel] , 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 Atempause, mit der Entwickler arbeiten können. Sie könnten ein viel niedrigeres Kontingent festlegen und den Entwicklern dennoch eine unermessliche Verbesserung gegenüber dem Hinken und 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 recht großzügige Menge, die einfallsreiche Entwickler für viele Aufgaben verwenden können. Auf der anderen Seite sind 5 MB für die meisten in letzter Zeit gekauften Festplatten nicht besonders wichtig. Wenn Sie und eine Website sich nicht einig sind, wie viel Speicherplatz sinnvoll genutzt wird, oder eine Website einfach nur unpassend ist, sind die Kosten gering Sie viel und Sie sind nicht in Gefahr einer überfüllten Festplatte, es sei denn, Ihre Festplatte war bereits zu voll. Vielleicht wären wir besser dran, wenn das Gleichgewicht ein bisschen weniger oder ein bisschen mehr wäre, aber insgesamt ist es eine vernünftige Lösung, um die innere Spannung für einen clientseitigen Kontext anzugehen.

Es wird jedoch vorsichtig darauf hingewiesen, dass Sie keinen zusätzlichen Schutz benötigen, wenn Sie den Code für Ihren Server schreiben, damit Ihre Datenbank eine tolerierbare Größe von 5 MB überschreitet. Die meisten Entwickler brauchen und wollen keine Tools, die als Kindermädchen fungieren und sie davor schützen, mehr als 5 MB serverseitiger Daten zu speichern. Und das 5-MB-Kontingent, das auf Client-Seite ein goldener Balanceakt ist, ist auf einem Node.js-Server ziemlich albern. (Bei einer Datenbank für mehrere Benutzer, wie sie in diesem Anhang behandelt wird, 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 dem Datenträger. Das sind 5 MB, die gemeinsam genutzt werden Alle Benutzerkonten zusammen. Das kann schmerzhaft werden , wenn Sie viral werden!) In der Dokumentation wird angegeben, dass das Kontingent anpassbar ist Das Kontingent ist unbeantwortet, ebenso wie die StackOverflow-Frage. Die einzige Antwort, die ich finden konnte, befindet sich in der Github CoffeeScript-Quelle, in der sie als optionales zweites ganzzahliges Argument für einen Konstruktor aufgeführt ist. Das ist also ganz einfach, und Sie können ein Kontingent angeben, das der Größe eines Datenträgers oder einer Partition entspricht. Abgesehen von der Portierung einer Funktion, die keinen Sinn ergibt, hat der Autor des Tools die sehr gängige Konvention, 0 als „unbegrenzt“ für eine Variable oder Funktion zu interpretieren, bei der eine Ganzzahl einen Höchstwert für die Ressourcennutzung angibt, nicht vollständig eingehalten. Das Beste, was Sie mit diesem Fehler machen können, ist wahrscheinlich anzugeben, dass es sich bei dem Kontingent um Infinity handelt:

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

Tauschen Sie zwei Kommentare nacheinander aus:

Die Leute 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 Sprichwort von Douglas Crockford: „JavaScript als Sprache hat einige wirklich gute und einige wirklich schlechte Teile. Hier sind die guten Teile. Vergiss einfach, dass noch etwas anderes da ist. “Vielleicht wird das heiße Node.j-Ökosystem sein eigenes „ Douglas Crockford “anbauen, der sagen wird:„ The Node .js Ökosystem ist ein kodierender Wilder Westen, aber es gibt einige echte Juwelen zu finden. Hier ist eine Roadmap. Hier sind die Bereiche um fast jeden Preis zu vermeiden. Hier sind die Gebiete mit den reichsten Einnahmen, 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 angebracht sein, in einem oder zwei oder drei Jahren die Äußerungen über ein unreifes Ökosystem, die zum Zeitpunkt der Erstellung dieses Dokuments gemacht wurden, scharf zu zügeln. In fünf Jahren könnte es wirklich Sinn machen zu sagen: „Das 2015 Node.js-Ökosystem hatte mehrere Minenfelder. Das 2020 Node.js-Ökosystem hat mehrere Paradiese. “

15

Wenn Ihre Anwendung hauptsächlich Web-APIs oder andere io-Kanäle bindet, eine Benutzeroberfläche bereitstellt oder übernimmt, 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 Javascript-Transpiler). Wenn Sie Microservices erstellen, ist node.js ebenfalls in Ordnung. Node.js eignet sich auch für jedes Projekt, das klein oder einfach ist.

Das Hauptverkaufsargument besteht darin, dass Front-End-Kunden eher Verantwortung für Back-End-Produkte übernehmen als für die typische Kluft. Ein weiteres berechtigtes Verkaufsargument ist, wenn Ihre Belegschaft von Anfang an Javascript-orientiert 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, besonders wenn sie aus einem ereignisgesteuerten Javascript-Hintergrund stammen, sie scheinen vertraut oder verzeihbar.

Insbesondere dann, wenn Ihre Anwendung synchrone Abläufe ausführen muss, werden halbgebackene Lösungen ausgeblutet, die Sie im Hinblick auf Ihren Entwicklungsprozess erheblich verlangsamen. Wenn Ihre Anwendung rechenintensive Teile enthält, gehen Sie vorsichtig vor (nur) node.js. Vielleicht http://koajs.com/ oder andere Neuerungen lindern diese ursprünglich heiklen Aspekte, verglichen mit denen, als ich ursprünglich node.js verwendet oder dies geschrieben habe.

9
matanster