javascript - tutorial - Wie kann ich entscheiden, wann Node.js verwendet wird?




node.js tutorial pdf deutsch (12)

  1. Node eignet sich hervorragend für schnelle Prototypen, aber ich würde ihn nie wieder für etwas Komplexes verwenden. Ich habe 20 Jahre lang eine Beziehung zu einem Compiler aufgebaut und ich vermisse sie sicherlich.

  2. Node ist besonders schmerzhaft, wenn Sie Code beibehalten, den Sie längere Zeit nicht besucht haben. Typinformationen und Fehler bei der Kompilierzeit sind gute Dinge. Warum das alles rausschmeißen? Für was? Und dang, wenn etwas nach Süden geht, sind die Stapelspuren oft völlig nutzlos.

Ich bin neu in dieser Art von Sachen, aber in letzter Zeit habe ich viel darüber gehört, wie gut Node.js ist. In Anbetracht dessen, wie gerne ich generell mit jQuery und JavaScript arbeite, frage ich mich, wie ich entscheiden kann, wann Node.js verwendet wird. Die Webanwendung, die ich mir vorstelle, ist so etwas wie Bitly - nimmt einige Inhalte mit, archiviert sie.

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

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

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

In Anbetracht der Tatsache, dass Node.js in den EC2- Instanzen von Amazon 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 Expertise einer Sprache abhängt, aber meine Frage fällt eher in die allgemeine Kategorie: Wann ist ein bestimmter Rahmen zu verwenden und für welche Art von Problemen ist er besonders geeignet?


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

  • Alle coolsten Typen sind dran ... also muss es Spaß machen.
  • Sie können am Kühler herumhängen und viele Node-Abenteuer haben, mit denen Sie prahlen können.
  • Wenn es um Cloud-Hosting-Kosten geht, sind Sie ein Penny Pincher.
  • Ich habe das schon mit Rails gemacht
  • Sie hassen IIS-Bereitstellungen
  • Ihr alter IT-Job wird ziemlich langweilig und Sie wünschen, Sie wären in einem glänzenden neuen Start-Up.

Was zu erwarten ist ...

  • Mit Express fühlen Sie sich sicher und sicher, ohne die Server-Bloatware, die Sie nie gebraucht hätten.
  • Läuft wie eine Rakete und skaliert gut.
  • Du träumst es. Sie haben es installiert. Das Node Package Repo packages ist das größte Ökosystem von Open Source-Bibliotheken der Welt.
  • Ihr Gehirn wird im Land der verschachtelten Rückrufe Zeitverzerrungen bekommen ...
  • ... bis Sie lernen, Ihre Promises zu halten.
  • Sequelize und Passport sind Ihre neuen API-Freunde.
  • Das Debuggen von meist asynchronem Code wird umm interessant werden .
  • Zeit für alle Knoten, die Typoscript zu beherrschen.

Wer benutzt es?

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

Es gibt nichts wie Silver Bullet. Alles ist mit gewissen Kosten verbunden. Es ist wie wenn Sie fettige Nahrung essen, Sie werden Ihre Gesundheit gefährden und gesunde Nahrung kommt nicht mit Gewürzen wie fettiger Nahrung. Es ist die individuelle Entscheidung, ob sie Gesundheit oder Gewürze wie in ihrem Essen wollen. Gleiche Art und Weise, wie Node.js in bestimmten Szenarien verwendet wird. Wenn Ihre App nicht in dieses Szenario passt, sollten Sie dies bei der App-Entwicklung nicht berücksichtigen. Ich denke nur an dasselbe:

Wann ist Node.JS zu verwenden?

  1. Wenn Ihr serverseitiger Code sehr wenige CPU-Zyklen erfordert. In einer anderen Welt sind Sie nicht blockierend und haben keinen Algorithmus / Job, der viele CPU-Zyklen beansprucht.
  2. Wenn Sie über Javascript verfügen, können Sie Single Threaded-Code genau wie clientseitige JS schreiben.

Wenn NICHT Node.JS verwendet werden

  1. Ihre Serveranfrage ist abhängig von einem hohen CPU-Verbrauch / Job.

Überlegungen zur Skalierbarkeit mit Node.JS

  1. Node.JS selbst verwendet nicht den gesamten Kern des zugrundeliegenden Systems und es ist standardmäßig Single-Threading. Sie müssen eine eigene Logik schreiben, um den Multi-Core-Prozessor zu verwenden und ihn zu einem Multi-Thread zu machen.

Node.JS-Alternativen

Es gibt andere Optionen, die anstelle von Node.JS verwendet werden können. Vert.x scheint jedoch vielversprechend zu sein und bietet viele zusätzliche Funktionen wie Polygot und bessere Skalierbarkeitsaspekte.


Es kann wo verwendet werden

  • Anwendungen, die stark ereignisgesteuert sind und stark an E / A gebunden sind
  • Anwendungen, die eine Vielzahl von Verbindungen zu anderen Systemen verwalten
  • Echtzeitanwendungen (Node.js wurde von Grund auf für Echtzeit entwickelt und ist einfach zu bedienen.)
  • Anwendungen, die mit Informationen strömen, die zu und von anderen Quellen strömen
  • Hoher Verkehr, skalierbare Anwendungen
  • Mobile Apps, die mit 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 kommunizieren müssen

Im Bereich Mobile setzen Prime-Time-Unternehmen für ihre mobilen Lösungen auf Node.js. Überprüfen Sie warum?

LinkedIn ist ein prominenter Benutzer. Ihr gesamter mobiler Stack basiert auf Node.js. Sie hatten 15 Server mit 15 Instanzen auf jeder physischen Maschine und nur 4 Instanzen - damit kann der doppelte Datenverkehr bewältigt werden!

eBay startete ql.io, 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 sie mehr als 120.000 aktive Verbindungen pro node.js-Prozess handhabt, wobei jede Verbindung etwa 2 KByte Speicherplatz beanspruchte!

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/


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 ein Roboter oder ein Sensor) die Anwendung sofort für andere Benutzer sichtbar macht. 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, sofern verfügbar.

Ich sollte aber auch erwähnen, dass in jeder Situation, in der der Code aufgrund von Threads blockiert werden kann, er mit Node.js besser angesprochen werden kann. Oder jede 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 Nginx bei regulären alten HTTP-Anfragen nahe stehen. Wenn wir also mit Node.js bauen, können wir unsere normalen Ressourcen recht effektiv bedienen, und wenn wir ereignisgesteuertes Zeug benötigen, ist es bereit, damit umzugehen.

Plus ist es immer JavaScript. Lingua Franca auf dem ganzen Stapel.


Ich habe ein reales Beispiel, bei dem ich Node.js verwendet habe. Die Firma, in der ich arbeite, bekam einen Kunden, der eine einfache statische HTML-Website haben wollte. Diese Website ist für den Verkauf eines Artikels über PayPal und der Kunde wollte auch einen Zähler haben, der die Anzahl der verkauften Artikel anzeigt. Der Kunde erwartete eine große Anzahl von Besuchern dieser Website. Ich entschied mich dafür, den Zähler mit Node.js und dem Express.js Framework zu Express.js .

Die Anwendung Node.js war einfach. Holen Sie sich den verkauften Artikel aus einer Redis Datenbank, erhöhen Sie den Zähler, wenn ein Artikel verkauft wird, und stellen Sie den Zählerwert über die API für Benutzer API .

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

  1. Es ist sehr leicht und schnell. Es wurden in drei Wochen über 200.000 Besuche auf dieser Website durchgeführt, und es konnten nur minimale Serverressourcen verwendet werden.
  2. Der Zähler ist wirklich leicht in Echtzeit zu machen.
  3. Node.js war einfach zu konfigurieren.
  4. Es stehen viele Module kostenlos zur Verfügung. Ich habe zum Beispiel ein Node.js-Modul für PayPal gefunden.

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


Mein Stück: nodejs eignet sich hervorragend für Echtzeitsysteme wie Analytics, Chat-Apps, Apis, Ad-Server usw. 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 schon einige Jahre her, seit ich mit nodejs angefangen habe, und ich habe damit viele verschiedene Dinge gemacht, darunter statische Dateiserver, einfache Analysen, Chat-Apps und vieles mehr. Dies ist meine Meinung, wenn nodejs verwendet wird

Wann verwenden?

Beim Erstellen eines Systems, bei dem der Schwerpunkt auf Parallelität und Geschwindigkeit liegt.

  • Sockets nur Server wie Chat-Apps, IRC-Apps usw.
  • Soziale Netzwerke mit Schwerpunkt auf Echtzeitressourcen wie Geolocation, Videostream, Audiostream usw.
  • Kleine Datenmengen schnell wie eine analytische Webapp behandeln.
  • Als Freilegen einer REST nur api.

Wann nicht verwenden

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

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

Denken Sie daran, dass ich nur pingelig bin. Bei statischen Dateiservern ist Apache vor allem deshalb besser, weil er allgemein verfügbar ist. Die nodejs-Community ist im Laufe der Jahre immer größer und reifer geworden, und man kann mit Sicherheit sagen, dass nodejs fast überall verwendet werden kann, wenn Sie das Hosting selbst festlegen.


Sie haben eine großartige Arbeit geleistet, um zusammenzufassen, was Node.js so toll macht. Meiner Meinung nach 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 Technik, die als "long-polling" , können Sie eine Anwendung schreiben, die Aktualisierungen an den Benutzer in Echtzeit sendet. Durch langes Abfragen vieler Web-Giganten wie Ruby on Rails oder Django würde der Server enorm belastet, da jeder aktive Client einen Serverprozess belegt. Diese Situation ist ein Angriff der tarpit . Wenn Sie etwas wie Node.js verwenden, muss der Server für jede offene Verbindung keine separaten Threads verwalten.

Dies bedeutet, dass Sie eine browserbasierte Chat-Anwendung in Node.js erstellen können, die fast keine Systemressourcen benötigt, um eine große Anzahl von Clients zu bedienen. Node.js ist immer eine großartige Option, wenn Sie diese Art der langen Abfrage durchführen möchten.

Es ist erwähnenswert, dass sowohl Ruby als auch Python über Werkzeuge verfügen, um diese Art von eventmachine ( eventmachine bzw. twisted ), aber dass Node.js es außergewöhnlich gut tut, und zwar von Grund auf. JavaScript ist ausgesprochen gut für ein Callback-basiertes Parallelitätsmodell geeignet und zeichnet sich hier aus. In der Lage zu sein, mit JSON native sowohl auf dem Client als auch auf dem Server zu serialisieren und zu deserialisieren, ist ziemlich einfach.

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

Es ist darauf hinzuweisen, dass Node.js auch für Situationen geeignet ist, in denen Sie viel Code in der gesamten Client / Server-Lücke wiederverwenden. Das Meteor-Framework macht dies sehr einfach, und viele Leute meinen, dies könnte die Zukunft der Webentwicklung sein. Aus Erfahrung kann ich sagen, dass es sehr viel Spaß macht, Code in Meteor zu schreiben, und ein großer Teil davon ist weniger Zeit zum Nachdenken darüber, wie Sie Ihre Daten umstrukturieren, sodass der im Browser ausgeführte Code problemlos verwendet werden kann manipulieren Sie es und geben Sie es zurück.

Hier ist ein Artikel über Pyramid und Long Polling, der sich mit Hilfe von gevent als sehr einfach einrichten lässt: TicTacToe und Long Polling with Pyramid .


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

Beginnen wir mit einer Geschichte. In den letzten 2 Jahren arbeite ich an JavaScript und entwickle das Web-Frontend und es macht mir Spaß. Back-End-Jungs stellen uns einige in Java geschriebene APIs, Python (wir kümmern uns nicht), und wir schreiben einfach einen AJAX-Aufruf, holen unsere Daten ab und raten Sie uns! wir sind fertig. Aber in Wirklichkeit ist es nicht so einfach. Wenn die Daten, die wir erhalten, nicht korrekt sind oder ein Serverfehler vorliegt, bleiben wir hängen und müssen unsere Back-End-Leute über die E-Mail oder den Chat kontaktieren (manchmal auch auf WhatsApp :).) ist nicht cool Was wäre, wenn wir unsere APIs in JavaScript geschrieben haben und diese APIs von unserem Frontend aus aufrufen würden? Ja, das ist ziemlich cool, denn wenn wir Probleme mit der API haben, können wir uns darum kümmern. Erraten Sie, was ! Sie können das jetzt tun, wie? - Node ist für dich da.

Ok stimmte zu, 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?

also hier beginnt der zauber. 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 Threading basiert. Angenommen, zwei gleichzeitige Anforderungen treten auf (r1 und r2), erfordert jede von ihnen eine Datenbankoperation. Was also im traditionellen System geschieht:

1. Warteweg: Unser Server beginnt mit der Anforderung von r1 und wartet auf die Antwort auf die Anfrage. Nach Abschluss von r1 beginnt der Server mit der r2 und führt dies auf dieselbe 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 deren Zweck, nachdem er die Datenbank abgefragt hat. Kühlen Sie sich also schnell ab. Aber es ist speicherintensiv, da Sie sehen, dass wir zwei Threads gestartet haben. Außerdem steigt das Problem, wenn beide Anfragen abfragen Dieselben Daten müssen Sie dann mit Deadlock-Problemen befassen. Es ist also besser als warten, aber es gibt immer noch Probleme.

Hier ist, wie der Knoten es tun wird:

3. Nodeway: Wenn dieselbe gleichzeitige Anforderung im Knoten eingeht , wird ein Ereignis mit seinem Rückruf registriert und es wird nicht weiter auf eine Antwort auf eine bestimmte Anforderung gewartet. Wenn also die Anforderung r1 kommt, dann ist die Ereignisschleife des Knotens (ja, es gibt ein Ereignis Schleife im Knoten, der diesem Zweck dient.) Registrieren eines Ereignisses mit seiner Rückruffunktion und r2 der r2 Anforderung und Registrieren seines Ereignisses mit seinem Rückruf. Wenn eine Abfrage abgeschlossen ist, löst sie das entsprechende Ereignis aus und führt den Rückruf ohne Unterbrechung vollständig aus.

Also kein Warten, kein Threading, kein Speicherbedarf - ja, das ist kein Weg, um die Rest-API zu bedienen.


Ankleiden Asbest Longjohns ...

Gestern mein Titel bei Packt Publications, Reactive Programming with JavaScript . Es ist nicht wirklich ein Node.js-zentrierter Titel. In frühen Kapiteln soll die Theorie behandelt werden, in späteren Kapiteln wird die Praxis behandelt. Da ich es nicht wirklich für angebracht hielt, den Lesern keinen Webserver zu geben, schien Node.js bei weitem die naheliegende Wahl. Der Fall wurde geschlossen, noch bevor er geöffnet wurde.

Ich hätte meine Erfahrung mit Node.js sehr rosig ausdrücken können. Stattdessen war ich ehrlich in Bezug auf gute und schlechte Punkte.

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

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

Als ich als Lehrerassistent in Mathe tätig war, war einer der nicht naheliegenden Vorschläge, einem Schüler nicht zu sagen, dass etwas „einfach“ sei. Der Grund war im Nachhinein etwas offensichtlicher: Wenn Sie den Leuten etwas sagen, ist das einfach, jemand der Keine Lösung sieht sich am Ende als dumm an, weil sie nicht nur nicht das Problem lösen kann, sondern das Problem, das sie zu dumm sind, um es zu verstehen, ein einfaches ist!

Es gibt Gechas, die Leute, die aus Python / Django kommen, nicht nur ärgern, was die Quelle sofort neu lädt, wenn Sie etwas ändern. Bei Node.js ist das Standardverhalten, dass bei einer Änderung die alte Version bis zum Ende der Zeit aktiv bleibt oder bis Sie den Server manuell stoppen und erneut starten. Dieses unangemessene Verhalten ärgert nicht nur Pythonistas; Es irritiert auch native Node.js-Benutzer, die verschiedene Problemumgehungen anbieten. Die -Frage "Auto-reload 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 einer Homepage unter http://tinyurl.com/reactjs-node-supervisor . Dieses Problem bietet neuen Benutzern eine großartige Gelegenheit, sich dumm zu fühlen, weil sie der Meinung waren, das Problem sei gelöst worden, aber das alte fehlerhafte Verhalten ist völlig unverändert. Und es ist leicht zu vergessen, den Server zu prellen. Ich habe es schon mehrmals getan. Und die Botschaft, die ich gerne geben möchte, ist: „Nein, Sie sind nicht dumm, weil dieses Verhalten von Node.js Sie in 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, nehmen Sie vielleicht ein wenig Hilfe von Node Supervisor oder einer anderen Lösung, aber gehen Sie nicht davor, sich dumm zu fühlen. Du bist nicht derjenige mit dem Problem; Das Problem liegt im Standardverhalten von Node.js. "

Dieser Abschnitt wurde nach einigen Diskussionen hinterlassen, gerade weil ich keinen Eindruck von "Es ist einfach" machen möchte. Ich schneide mir immer wieder die Hände, während ich die Dinge zum Laufen bringe, und ich möchte Schwierigkeiten nicht beseitigen Stellen Sie sich vor zu der Überzeugung, dass die Funktionsweise von Node.js und seines Ökosystems eine unkomplizierte Angelegenheit ist, und wenn es auch für Sie nicht einfach ist, wissen Sie nicht, was Sie tun. Wenn Sie mit Node.js keine unangenehmen Schwierigkeiten haben, 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 in Ordnung sein.“ Sie sind nicht dumm, wenn Sie mit Node.js böse Überraschungen 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 Fazit nicht wirklich haben wollte, spricht darüber, was ich im Ökosystem finden konnte, und stellte eine Lösung für den schwachsinnigen Literalismus dar:

Eine andere Datenbank, die perfekt zu sein schien und dennoch 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. Es ist auch eine API, die die meisten nicht so guten Front-End-Entwickler gut genug verstehen. Mit dem node-localstorage-Paket wird zwar kein Wörterbuchsyntaxzugriff angeboten (Sie möchten localStorage.setItem (key, value) oder localStorage.getItem (key), nicht localStorage [key]) verwenden, die vollständige localStorage-Semantik ist jedoch implementiert , einschließlich eines Standard-Kontingents 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 wirklich eine großzügige und nützliche Menge an Spielraum, damit Entwickler mit ihr arbeiten können. Sie könnten eine wesentlich niedrigere Quote festlegen und den Entwicklern dennoch eine unermessliche Verbesserung gegenüber dem Hinken und dem Cookie-Management bieten. Ein Limit von 5 MB eignet sich nicht sehr schnell für die Verarbeitung von Big Data-Clients, aber es gibt eine recht großzügige Genehmigung, die einfallsreiche Entwickler für eine Menge nutzen können. Auf der anderen Seite ist 5 MB jedoch kein besonders großer Teil der meisten Festplatten, die kürzlich gekauft wurden, was bedeutet, dass wenn Sie und eine Website uneinig darüber sind, was vernünftigen Speicherplatz benötigt, oder eine Website einfach nur anstößig ist, ist dies nicht wirklich teuer Sie und Sie sind nicht in Gefahr einer überlasteten Festplatte, es sei denn, Ihre Festplatte war bereits zu voll. Vielleicht wären wir besser dran, wenn das Gleichgewicht etwas weniger oder ein bisschen mehr wäre, aber insgesamt ist es eine vernünftige Lösung, um die intrinsische Spannung im Zusammenhang mit dem Kunden zu lösen.

Es kann jedoch darauf hingewiesen werden, dass Sie, wenn Sie der einzige Code für Ihren Server sind, keinen zusätzlichen Schutz benötigen, um die Größe Ihrer Datenbank um mehr als 5 MB zu erhöhen. Die meisten Entwickler werden weder Werkzeuge brauchen noch wollen, dass sie als Kindermädchen dienen und sie vor dem Speichern von serverseitigen Daten von mehr als 5 MB schützen. Das 5-MB-Kontingent, das auf der Clientseite ein goldener Spagat ist, ist auf einem Node.js-Server ziemlich dumm. (Für eine Datenbank für mehrere Benutzer, wie in diesem Anhang beschrieben, wird möglicherweise etwas schmerzhaft darauf hingewiesen, dass dies nicht 5 MB pro Benutzerkonto ist, es sei denn, Sie erstellen für jedes Benutzerkonto eine separate Datenbank auf der Festplatte; dies sind 5 MB gemeinsam genutzt Alle Benutzerkonten zusammen. Das kann schmerzhaft werden, wenn Sie viral werden!) In der Dokumentation wird angegeben, dass die Quote anpassbar ist. Eine E-Mail an den Entwickler, die nach der Änderung der Quote gefragt hat, bleibt jedoch unbeantwortet. Dies gilt auch für die -Frage . Die einzige Antwort, die ich finden konnte, ist in der Github CoffeeScript-Quelle, wo sie als optionales zweites Ganzzahlargument für einen Konstruktor aufgeführt wird. 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, ist es dem Autor des Tools jedoch nicht gelungen, einer sehr gängigen Konvention zu folgen, bei der 0 als „unbegrenzt“ für eine Variable oder Funktion interpretiert wird, bei der eine Ganzzahl einen Höchstwert für die Ressourcennutzung angibt. Das Beste, was mit diesem Missverständnis zu tun ist, ist wahrscheinlich anzugeben, dass die Quote Infinity ist:

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

Zwei Kommentare in der richtigen Reihenfolge tauschen:

Die Menschen schossen sich unnötigerweise ständig mit JavaScript in den Fuß. Als Teil von JavaScript wurde die Sprache respektabel gemacht, sagte Douglas Crockford im Wesentlichen: „JavaScript als Sprache hat einige wirklich gute und einige wirklich schlechte Teile. Hier sind die guten Teile. Vergessen Sie einfach, dass noch etwas vorhanden ist. “Vielleicht wird das heiße Node.js-Ökosystem sein eigenes „ Douglas Crockford “entwickeln, der sagen wird:„ Das Node.js-Ökosystem ist ein codierender Wilder Westen, aber es gibt einige echte Edelsteine . Hier ist eine Roadmap. Hier sind die Bereiche zu fast allen Kosten zu vermeiden. Hier sind die Bereiche mit einigen der reichsten Einkommensquellen, die in JEDER Sprache oder in jeder Umgebung zu finden sind. “

Vielleicht kann jemand anderes diese Worte als Herausforderung annehmen, 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 reinen Arbeitszeit für alle Projekte kann es innerhalb eines oder zwei oder drei Jahren gerechtfertigt sein, etwaige Bemerkungen zu einem unreifen Ökosystem, das zum Zeitpunkt dieser Veröffentlichung gemacht wurde, scharf zu mildern. In fünf Jahren kann es sinnvoll sein, zu sagen: „Das Ökosystem Node.js 2015 hatte mehrere Minenfelder. Das 2020 Node.js-Ökosystem hat mehrere Paradiese. “


Ich kann ein paar Punkte teilen, wo und warum Knoten js verwendet werden.

  1. Für Echtzeitanwendungen wie Chat und kollaboratives Editieren gehen wir besser mit nodejs, da es sich um eine Ereignisbasis handelt, bei der Ereignisse und Daten an Clients vom Server ausgelöst werden.
  2. Einfach und leicht zu verstehen, da es sich um eine Javascript-Basis handelt, bei der die meisten Leute eine Idee haben.
  3. Die meisten aktuellen Webanwendungen, die sich auf eckige Js und Backbones konzentrieren, können mit Knotenseiten leicht mit clientseitigem Code interagieren, da beide Json-Daten verwenden.
  4. Viele Plugins verfügbar.

Nachteile: -

  1. Node unterstützt die meisten Datenbanken. Am besten ist jedoch mongodb, der komplexe Joins und andere nicht unterstützt.
  2. Fehler bei der Kompilierung ... Der Entwickler sollte alle Ausnahmen anders behandeln, wenn eine Fehlerabkommensanwendung aufhört, an der Stelle zu arbeiten, an der wir sie manuell starten oder ein Automatisierungswerkzeug verwenden müssen.

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


Wenn Ihre Anwendung hauptsächlich Web-APIs oder andere iO-Kanäle anbietet, geben Sie eine Benutzeroberfläche ein oder nehmen sie mit, kann node.js eine gute Wahl für Sie sein, insbesondere, wenn Sie die beste Skalierbarkeit ausnutzen möchten oder Ihre Hauptsprache im Leben ist ist Javascript (oder Javascript Transpiler von Art). Wenn Sie Microservices erstellen, ist node.js ebenfalls in Ordnung. Node.js eignet sich auch für jedes kleine oder einfache Projekt.

Sein Hauptverkaufsargument ist, dass Front-Ender die Verantwortung für das Back-End-Material übernehmen und nicht die typische Kluft. Ein weiteres berechtigtes Verkaufsargument ist, wenn Ihre Belegschaft von Anfang an auf Javascript ausgerichtet ist.

Über einen bestimmten Punkt hinaus 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, scheinen sie vertraut oder verzeihbar zu sein.

Wenn Ihre Anwendung synchrone Flüsse ausführen muss, bluten Sie vor halb eingebackenen Lösungen, die Ihren Entwicklungsprozess erheblich verlangsamen. Wenn Sie in Ihrer Anwendung rechenintensive Teile haben, gehen Sie mit Vorsicht vor (nur) node.js. Vielleicht lindern Koajs oder andere Neuerungen diese ursprünglich schwierigen Aspekte im Vergleich zu meiner ursprünglichen Verwendung von node.js oder dem Schreiben dieser.







web-applications