Prediger / Winzinger Node.js
1. Auflage 2015
ISBN: 978-3-446-43758-6
Verlag: Carl Hanser
Format: PDF
Kopierschutz: 1 - PDF Watermark
Professionell hochperformante Software entwickeln
E-Book, Deutsch, 368 Seiten
ISBN: 978-3-446-43758-6
Verlag: Carl Hanser
Format: PDF
Kopierschutz: 1 - PDF Watermark
- Begleiten Sie uns im Umfeld von JavaScript und Node.js durch den kompletten Entwicklungszyklus - Develop, Build, Test, Run.
- Erleben Sie Node.js in Aktion - anhand einer Vielzahl kleiner Beispiele, die typische Probleme und deren Lösung mit gängigen Tools und Frameworks zeigen.
- Sammeln Sie ausreichend Hintergrundinformation und Best Practices, um selbst zu entscheiden, ob JavaScript und Node.js 'the right tool for the job' ist.
- Extra: E-Book inside
Es gibt nur wenige Sprachen, die sich seit so langer Zeit so klar am Markt behaupten wie JavaScript. Dies ist durchaus erstaunlich, wenn man sich vor Augen hält, wie der Werdegang von JavaScript aussieht und wie schlecht sein Ruf war.
Mit Node.js und der darunter liegenden V8 Engine von Google ist mehr entstanden als nur eine hoch performante Server-Runtime: Wir können jetzt auf ein riesiges System von Modulen zurückgreifen und auf professionelle Entwicklungswerkzeuge, die den Vergleich mit Tools aus dem Enterprise-Umfeld nicht scheuen müssen.
Wenn massiver Datenverkehr behandelt werden muss, ist Node.js eine valide Option, weil es Server viel besser auslasten kann als 'traditionelle' Systeme. Es kann mehr Leistung auf vorhandener Hardware erbringen oder den selben Ansturm mit weniger Ressourcen abarbeiten. Führt man sich die bereits heute sichtbaren Auswirkungen der Digitalisierung vor Augen, so ist unstrittig, dass es immer weniger attraktiv sein wird, Systeme mit einem großen Resource-Footprint zu betreiben. Node.js und JavaScript hingegen können genau hier ihre Fähigkeiten ausspielen und werden sicherlich noch lange im Markt zu finden sein.
AUS DEM INHALT //
Tooling, IDEs und Hosting // NPM // Testing, Debugging & Monitoring // Dateien & Streams // Datenbanken // REST & SOAP Services // Web-Frontends // (native) Plug-ins // Deployment & Hosting // Architektur & Performanceoptimierung
Systemvoraussetzungen für E-Book inside: Internet-Verbindung und Adobe-Reader
Autoren/Hrsg.
Fachgebiete
Weitere Infos & Material
1;Vorwort;12
1.1;.?.?. und ihre Motivation;14
1.2;Das Zielpublikum;14
1.3;Das Buch;15
1.4;Die Welt von JavaScript;16
2;1?Hello, Node.js;18
2.1;1.2?Installation;25
2.1.1;1.2.1?Windows;25
2.1.2;1.2.2?Mac OS X;25
2.1.3;1.2.3?Debian;26
2.1.4;1.2.4?Ubuntu;26
2.1.5;1.2.5?openSUSE und SLE;27
2.1.6;1.2.6?Fedora;28
2.1.7;1.2.7?RHEL und CentOS;28
2.2;1.3?IDEs;28
2.2.1;1.3.1?cloud9;29
2.2.2;1.3.2?WebStorm;31
2.2.3;1.3.3?Nodeclipse;32
2.2.4;1.3.4?WebMatrix/VisualStudio;33
2.2.5;1.3.5?Atom;33
2.3;1.4?nvm & nodist – mit Node-Versionen jonglieren;34
2.3.1;1.4.1?*ix-Systeme;35
2.3.2;1.4.2?Windows;36
2.4;1.5?npm – Node Packaged Modules;38
2.4.1;1.5.1?npm install – ein Modul laden;39
2.4.2;1.5.2?Global? Lokal?;40
2.4.3;1.5.3?package.json;41
2.4.4;1.5.4?Module patchen;41
2.4.5;1.5.5?Browserify;45
2.5;1.6?Kein Code?;47
3;2?You build it .?.?.;52
3.1;2.1?File I/O;53
3.1.1;2.1.1?Dateifunktionen in Node.js;53
3.1.2;2.1.2?Permissions;56
3.1.3;2.1.3?„watch“ – Änderungen im Auge behalten;57
3.1.4;2.1.4?Erweiterungen;58
3.1.4.1;2.1.4.1?Modul „fs-extra“;59
3.1.4.2;2.1.4.2?Modul „file“;60
3.1.4.3;2.1.4.3?Modul „find“;60
3.1.4.4;2.1.4.4?Modul „properties“;61
3.1.4.5;2.1.4.5?Modul „token-filter“;62
3.2;2.2?Streams;63
3.2.1;2.2.1?Aus Streams lesen .?.?.;64
3.2.1.1;2.2.1.1?Objekte und Strings;65
3.2.2;2.2.2?.?.?. und in Streams schreiben;66
3.2.2.1;2.2.2.1?Streams verknüpfen;66
3.2.3;2.2.3?Eigene Streams implementieren;67
3.2.3.1;2.2.3.1?Ein Random-Number-Generator;68
3.2.3.2;2.2.3.2?Ein Daten-Lösch-Stream;70
3.2.3.3;2.2.3.3?Ein Verschlüsselungsserver für geheime Botschaften;71
3.2.4;2.2.4?Buffers and Strings;73
3.3;2.3?Daten für immer;74
3.3.1;2.3.1?Neo4j;74
3.3.1.1;2.3.1.1?Asynchron?;77
3.3.1.2;2.3.1.2?Querying Neo4j;78
3.3.1.3;2.3.1.3?Cypher für Abfragen;79
3.3.1.4;2.3.1.4?Indizes;81
3.3.1.5;2.3.1.5?Cypher für Batches;82
3.3.2;2.3.2?MongoDB;83
3.3.2.1;2.3.2.1?Wann sind Daten geschrieben?;84
3.3.2.2;2.3.2.2?_id;85
3.3.2.3;2.3.2.3?Die Mongo-API;85
3.4;2.4?Sichtbarkeit erzeugen – im Web;90
3.4.1;2.4.1?Middleware Framework Connect;90
3.4.1.1;2.4.1.1?Installation und einführendes Beispiel;91
3.4.1.2;2.4.1.2?Ausprägungen von Connect-Middleware-Typen;92
3.4.1.3;2.4.1.3?Integrierte Middleware-Komponenten;94
3.4.1.4;2.4.1.4?Middleware-Strukturen;102
3.4.2;2.4.2?Webentwicklung mit Express;107
3.4.2.1;2.4.2.1?Ready for take off: Installation und Einführungsbeispiel;108
3.4.2.2;2.4.2.2?Routing von HTTP-Anfragen;111
3.4.2.3;2.4.2.3?Views und Web-Templating;115
3.4.3;2.4.3?Express 4;116
3.4.4;2.4.4?Jade;118
3.4.4.1;2.4.4.1?Einbindung in Express;120
3.4.4.2;2.4.4.2?Sprachelemente von Jade;120
3.4.5;2.4.5?swig;133
3.4.5.1;2.4.5.1?Grundeinstellungen;133
3.4.5.2;2.4.5.2?Einbindung in Express;134
3.4.5.3;2.4.5.3?Sprachelemente von swig;135
3.4.5.4;2.4.5.4?Filterliste;138
3.4.5.5;2.4.5.5?Verketten von Filtern;141
3.4.5.6;2.4.5.6?Die swig-API;141
3.4.5.7;2.4.5.7?Eigene Funktionalitäten hinzufügen;143
3.4.6;2.4.6?Sessions & Authentifizierung;144
3.4.6.1;2.4.6.1?Ich will Kekse und biete dafür eine Session;145
3.4.6.2;2.4.6.2?Authentifizierung (Authentication);147
3.4.6.3;2.4.6.3?Facebook;150
3.4.6.4;2.4.6.4?Twitter;151
3.4.6.5;2.4.6.5?Google;152
3.5;2.5?socket.io;153
3.5.1;2.5.1?Verbindung herstellen;154
3.5.2;2.5.2?Kommunikation;155
3.5.3;2.5.3?Broadcast;156
3.5.4;2.5.4?Private Daten;156
3.5.5;2.5.5?Rückantwort und Bestätigung;156
3.5.6;2.5.6?Namespaces;157
3.5.7;2.5.7?Räume;158
3.5.8;2.5.8?Autorisierung;160
3.5.8.1;2.5.8.1?Globale Autorisierung;160
3.5.8.2;2.5.8.2?Autorierung mit Namespaceses;161
3.5.8.3;2.5.8.3?Benutzerdefinierte Variablen und Autorisierung;162
3.5.9;2.5.9?Sessions mit „socket.io-session“;162
3.5.9.1;2.5.9.1?socket.io-bundle;162
3.5.9.2;2.5.9.2?socket.io-passport;163
3.5.10;2.5.10?Version 1.0;164
3.6;2.6?Node.js und Webservices;168
3.6.1;2.6.1?SOAP-Services;168
3.6.1.1;2.6.1.1?Von und nach SOAP;170
3.6.2;2.6.2?REST-Services;180
3.6.2.1;2.6.2.1?Von Nomen, Verben und Routen;181
3.6.2.2;2.6.2.2?Ansichtssache? Verhandlungssache;185
3.6.2.3;2.6.2.3?Fehlermeldungen;187
3.6.2.4;2.6.2.4?Plug-ins;188
3.6.2.5;2.6.2.5?Sicherheit und Authentifizierung;193
3.6.3;2.6.3?XML-Verarbeitung;200
3.6.3.1;2.6.3.1?XML-Parsing;200
3.6.3.2;2.6.3.2?XML-Erzeugung und -Veränderung;206
3.6.3.3;2.6.3.3?Exkurs: Ein (selbst unterschriebenes) Zertifikat erstellen;208
3.7;2.7?Clustering;210
3.7.1;2.7.1?Methoden und Eigenschaften von cluster;214
3.7.1.1;2.7.1.1?isMaster/isWorker;214
3.7.1.2;2.7.1.2?fork/online – Event;214
3.7.1.3;2.7.1.3?exit – Event;215
3.7.1.4;2.7.1.4?workers;215
3.7.2;2.7.2?Der Master;215
3.7.2.1;2.7.2.1?setupMaster();216
3.7.2.2;2.7.2.2?fork();217
3.7.2.3;2.7.2.3?disconnect();217
3.7.3;2.7.3?Der Worker;218
3.7.3.1;2.7.3.1?Die Attribute „id“ und „process“;218
3.7.3.2;2.7.3.2?Das suicide-Attribut;218
3.7.3.3;2.7.3.3?kill() & disconnect();218
3.8;2.8?Der Callback-Hölle entfliehen;219
3.8.1;2.8.1?async;220
3.8.1.1;2.8.1.1?Kontrollfluss;222
3.8.2;2.8.2?Q;229
3.8.2.1;2.8.2.1?then;231
3.8.2.2;2.8.2.2?fail;232
3.8.2.3;2.8.2.3?progress;232
3.9;2.9?Auf Herz und Nieren – Node.js-Anwendungen testen;233
3.9.1;2.9.1?Mocha;234
3.9.1.1;2.9.1.1?Asynchrone Aufrufe und Timeouts;237
3.9.1.2;2.9.1.2?Set-Up & Tear-Down;239
3.9.1.3;2.9.1.3?Only & Skip;240
3.9.1.4;2.9.1.4?Mocha im Browser;240
3.9.2;2.9.2?Assert & Chai;242
3.9.2.1;2.9.2.1?Assert;242
3.9.2.2;2.9.2.2?Chai;244
3.9.3;2.9.3?Sinon;249
3.9.3.1;2.9.3.1?Spies;251
3.9.3.2;2.9.3.2?Stubs;252
3.9.3.3;2.9.3.3?Mocks;253
3.9.3.4;2.9.3.4?Faked Timers;254
3.9.4;2.9.4?Jasmine;255
3.9.5;2.9.5?Continuous Test;256
3.9.5.1;2.9.5.1?Mocha & Jasmine im Überwachungsmodus;256
3.9.5.2;2.9.5.2?Travis-CI;257
4;3?.?.?. you run it!;262
4.1;3.1.1?Patterns & Style;263
4.1.1;3.1.1.1?package.json;264
4.1.1.1;3.1.1.2?Import & Export;265
4.1.1.2;3.1.1.3?Tests;266
4.1.1.3;3.1.1.4?Dokumentation;267
4.1.2;3.1.2?Ausführbare Module;269
4.1.3;3.1.3?Module mit nativen Abhängigkeiten;271
4.1.3.1;3.1.3.1?OS Libraries;272
4.1.3.2;3.1.3.2?Sourcecode Dependencies;273
4.1.3.3;3.1.3.3?Hands-On mit Add-On;274
4.1.4;3.1.4?It works on my machine – Dependency Hell;283
4.1.5;3.1.5?Veröffentlichung von Modulen;286
4.1.5.1;3.1.5.1?Einen Benutzer erzeugen .?.?.;286
4.1.5.2;3.1.5.2?.?.?. und das Modul publizieren;286
4.2;3.2?Private Repositories für npm;287
4.2.1;3.2.1?reggie;288
4.2.1.1;3.2.1.1?Inbetriebnahme;288
4.2.1.2;3.2.1.2?reggie publish;289
4.2.1.3;3.2.1.3?Laden von Modulen;289
4.2.1.4;3.2.1.4?HTTP-Abfragen;291
4.2.1.5;3.2.1.5?npm-Client;291
4.2.2;3.2.2?sinopia;292
4.3;3.3?Deployment;294
4.3.1;3.3.1?Ein eigener Server;295
4.3.1.1;3.3.1.1?Docker;295
4.3.1.2;3.3.1.2?Modul „forever“;297
4.3.1.3;3.3.1.3?pm2;301
4.3.1.4;3.3.1.4?git-deploy;307
4.3.2;3.3.2?Cloud;308
4.3.2.1;3.3.2.1?PaaS-Provider;308
4.3.2.2;3.3.2.2?Server-Systeme;312
4.4;3.4?Was Node.js antreibt .?.?. V8 Engine;313
4.4.1;3.4.1?Architektur;314
4.4.2;3.4.2?Die Performance-Tricks;316
4.4.2.1;3.4.2.1?„Fast Property Access“;317
4.4.2.2;3.4.2.2?Arrays;318
4.4.2.3;3.4.2.3?Kein Interpretationsspielraum;319
4.4.2.4;3.4.2.4?Garbage Collection;319
4.4.2.5;3.4.2.5?Caching Modules;320
4.5;3.5?Logging;321
4.5.1;3.5.1?debug;321
4.5.2;3.5.2?winston;324
4.5.2.1;3.5.2.1?Transportmechanismen;324
4.5.2.2;3.5.2.2?Logger-Instanz;325
4.5.2.3;3.5.2.3?Logging Levels;326
4.5.2.4;3.5.2.4?Strukturierte Daten loggen;326
4.5.2.5;3.5.2.5?Profiling;327
4.5.3;3.5.3?Bunyan;328
4.5.3.1;3.5.3.1?Konfiguration;329
4.5.3.2;3.5.3.2?Child Logger;330
4.5.3.3;3.5.3.3?Die „src“-Option;331
4.5.3.4;3.5.3.4?Streams;331
4.6;3.6?Debugging;332
4.6.1;3.6.1?Der Node-Debugger;332
4.6.2;3.6.2?Node-Inspector;335
4.7;3.7?Monitoring;338
4.7.1;3.7.1?Kommerzielle Monitoring-Services;340
4.7.1.1;3.7.1.1?New Relic;340
4.7.1.2;3.7.1.2?Nodetime;342
4.7.1.3;3.7.1.3?StrongOps;346
4.8;3.8?Alternativen zu Node.js;351
4.8.1;3.8.1?Vert.x – die polyglotte JVM-Alternative;352
4.8.1.1;3.8.1.1?Architektur;352
4.8.1.2;3.8.1.2?Hands-On;359
4.8.1.3;3.8.1.3?Node.js oder Vert.x?;364
5;Index;366
| 1 | Hello, Node.js |
Was ist Node.js eigentlich und wie arbeitet man nun damit? Das ist die zentrale Frage, die im ersten Teil des Buchs beantwortet werden soll. Hier geht es nicht darum, welche Bibliotheken bei der Erstellung großer Softwareprojekte besonders hilfreich sind oder wie man dafür sorgt, dass eine Node.js-Anwendung stabil läuft, auch wenn sie eine Unmenge von Anfragen abarbeiten muss. Nein, dieser Teil des Buchs liegt zeitlich vor den ersten Zeilen Anwendungscode, die hoffentlich bald entstehen.
Am Anfang dürfen natürlich ein paar einführende Worte zu Node.js nicht fehlen. Woher kommt dieses Node eigentlich und was ist daran besonders? Die technischen Tiefen werden erst im letzten Teil des Buchs erreicht, aber eine Idee von der Funktionsweise sollte man trotzdem von Anfang an haben.
Und neben der Idee bedarf es natürlich auch noch des notwendigen Handwerkszeugs. Node.js braucht eine Laufzeitumgebung ? für welche Systeme existiert die und wo kann man sie bekommen? Mit welchen Tools kann Quellcode editiert werden? Wo findet man Bibliotheken und wie kann man diese benutzen? Wenn auch diese Fragen alle geklärt sind, hat man keine Ausreden mehr, sich die Finger am Code schmutzig zu machen. Und auch wenn man kein Enterprise-System realisieren möchte ? Spaß kann man mit Node.js allemal haben. Und das ist schon mal ein ganz wichtiger Punkt!
| 1.1 | Einführung in Node.js |
Node.js hat ein unglaubliches Wachstum hingelegt. Von der ersten Ankündigung durch Ryan Dahl 20091 bis heute (Ende 2014) sind nur fünf Jahre vergangen. Das Node.js Repository auf GitHub ist aktuell auf Platz zwei der „most starred repositories“2 (und unter den ersten 15 der „most forked repositories“3).
Auf der anderen Seite gibt es auch einen geradezu aggressiven „Backlash“4. Natürlich ist das „trolling“ ? sinnvolle Argumente sind in solchen Fällen nur selten auszumachen. Auch Beiträge wie „Node.JS Is Stupid And If You Use It So Are You“5 fallen ganz klar in diese Kategorie.
Warum ist das so? Node.js ist immer noch vergleichsweise neu, hat sich aber schon an vielen Stellen einen festen Platz in der Anwendungslandschaft ergattert. Nichtsdestotrotz gibt es aber immer noch eine Art missionarischen Effekt. Überzeugte Anwender möchten Node.js weiter aus seiner Nische holen und versuchen, andere von seinen Vorteilen zu überzeugen. Dann gibt es natürlich auch den gegenläufigen Effekt: Jemand probiert etwas aus, von dem er gerade Lobpreisungen über sich hat ergehen lassen. Und dann passt es nicht zu seinem Problem, seinen Erwartungen oder einfach seiner aktuellen Denkweise. Er hat Zeit investiert und ist enttäuscht. Also muss die Technologie nutzlos, unsinnig oder überflüssig sein. Unter Umständen reicht für viele Entwickler alleine schon die Tatsache, dass Node.js auf JavaScript basiert, um es als indiskutabel einzustufen.
Weshalb haben wir nun ein Buch über Node.js geschrieben? Nicht weil wir missionieren möchten und denken, dass Node.js das Beste seit geschnitten Brot ist. Es gibt Situationen, in denen Node.js eine gute Lösung darstellt, aber auch Situationen, in denen man vielleicht zu einer Alternative greifen sollte. In den nächsten Kapiteln versuchen wir nicht nur Vorteile, sondern auch Nachteile zu zeigen ? insbesondere auch im Hinblick auf „professionelle Softwareentwicklung“. JavaScript hat nicht den besten Ruf in unserer Industrie und es wird schnell behauptet, dass es nicht als Basis für unternehmenskritische Anwendungen dienen kann. Es ist natürlich schwierig, hier absolute K.O.-Kriterien für oder gegen eine solche Verwendung zu finden ? Node.js ist sicherlich erwachsen genug, um nicht sofort auszuscheiden. Wir versuchen aber, viele Aspekte zu betrachten, die in den Bereich der professionellen Softwareentwicklung fallen, und beleuchten, wie diese Aspekte in Node.js und JavaScript behandelt werden. Unserer Meinung nach schneiden Node.js und JavaScript hier nicht immer optimal ab. Allerdings hängt es vom konkreten Szenario ab, ob ein ganz bestimmter Aspekt nun benötigt wird oder nicht. Node.js hat es auf jeden Fall verdient, eine Chance zu bekommen. Es kann vielleicht nicht in allen Bereichen mit etablierten Sprachen und Umgebungen wie dem Java-Ökosystem mithalten, aber es gibt durchaus Situationen, in denen Node.js einfach auf der Überholspur vorbeizieht …
Also, was ist der Nutzen von Node.js? Oder besser: Welches Problem löst Node.js besser als andere Technologien?
Eines der wichtigsten Probleme für Internetanwendungen ist Skalierbarkeit. Wenn die Benutzeranzahl steigt, soll der Ressourcenverbrauch nach Möglichkeit linear steigen. Von den relevanten Ressourcen CPU, I/O und RAM soll Node.js vor allem die Skalierbarkeit bei I/O-intensiven Anwendungen verbessern.
Um dies zu erreichen, setzt Node.js vollständig auf asynchrone I/O-Zugriffe. Wann immer Node.js auf eine Datenbank, einen Webservice oder auf das Dateisystem zugreift, erfolgt der Aufruf asynchron. Was macht das für einen Unterschied?
Im synchronen Fall könnte ein Datenbankaufruf folgendermaßen aussehen:
Der aktuelle Thread wartet auf das Ergebnis und wird „geweckt“, wenn das Ergebnis vorliegt (s. Bild 1.1). Dieses Verfahren funktioniert gut und ist aus konzeptioneller Sicht leicht zu begreifen. Als Entwickler kann man so programmieren, als ob man keine Nebenläufigkeit hätte. Man muss sich (meist) nicht um Synchronisation kümmern. Und das Wichtigste: Die Kosten für das Wechseln von einem Thread zum nächsten sind vernachlässigbar.
Bild 1.1 multi-threaded Server
Doch was tun, wenn die Kosten für den Wechsel nicht mehr vernachlässigbar sind? Wenn auf den „Thread Context Switch“ ein signifikanter Anteil an der Gesamtlaufzeit entfällt?
Hinzu kommt, dass Threads Hauptspeicher verbrauchen. Ein Java-Applikationsserver hat oft 200 bis 300 Threads. Auf einem 64-Bit-Linux-System wird für einen Thread 1 MB für den Stack reserviert. Somit werden ca. 250 MB verbraucht, die nur für die Threads benötigt werden. In vielen Anwendungen spielt das keine Rolle, da für den Heap allein 8 GB veranschlagt werden. Doch wenn die Anwendung
-
sehr viele parallele Zugriffe hat,
-
viel I/O (Datenbank, Dateisystem etc.) benötigt,
wird es eng. Was heißt in diesem Zusammenhang „viel“? 100 Zugriffe pro Minute sind (unserer nach) noch nicht viel. Spätestens bei 100 parallelen Zugriffen pro Sekunde wird Node.js definitiv interessant.
Keine Threads!
Was macht Node.js anders? Node.js verwendet nur einen Thread. Das ist alles. Nun ja, das ist nun etwas plakativ formuliert und technisch auch nicht ganz korrekt, aber in einer ersten Näherung ist es das, was Node.js anders macht als die meisten gewohnten Umgebungen. Wie handhabt Node.js dann Hunderte von parallelen Zugriffen? Es arbeitet einfach einen Auftrag nach dem anderen ab ? und wann immer dann auf einen langsamen I/O-Zugriff gewartet werden muss, wird der aktuelle Auftrag einfach beendet und ein neuer Auftrag für die Verarbeitung der Antwort erzeugt.
Bild 1.2 Node.js Event-Loop
In der Abbildung „Node.js Event-Loop“ ist der Ablauf ? stark vereinfacht ? skizziert. Es gibt eine Warteschlange mit Aufträgen, die bereit zur Verarbeitung sind („ready to execute“). Sobald der Verarbeitungs-Thread frei ist, beginnt er mit der Abarbeitung des Auftrags „a“. Wenn dann jedoch ein I/O-Zugriff erfolgt, wird die Abarbeitung des Auftrags beendet und ein Folgeauftrag „a1“ erzeugt. Dieser Auftrag wird jedoch erst dann in die „ready-to-execute“-Queue eingestellt, wenn der I/O-Zugriff abgeschlossen ist.
Bei Node.js muss der Entwickler jeden Folgeauftrag als „Callback-Funktion“ selbst definieren ? ein Vorgehen, das jedem JavaScript-Entwickler sehr vertraut sein dürfte und zu Code wie dem folgenden führt:
Wirklich schwer zu lesen wird es, wenn bei der Verarbeitung der Antwort wiederum ein I/O-Zugriff mit der nächsten Callback-Funktion zu schreiben ist. Statt der geschachtelten anonymen Funktionen kann man natürlich auch mit explizit benannten Funktionen arbeiten:
Damit wird es jedoch schwerer, den tatsächlichen Ablauf in den Codestrukturen nachzuvollziehen.
Da es vielen Programmierern so geht, gibt es eine große Menge an Node.js-Bibliotheken, die einen besser lesbaren Code ermöglichen. Zwei solche Bibliotheken werden im zweiten Teil im Abschnitt 2.8 gezeigt.
Wenn es keine Threads gibt, stellt sich die Frage: Wie nutzt man Multi-Prozessor und Multi-Core-Maschinen sinnvoll aus? Wenn man Node.js auf einer solchen Maschine laufen lässt, wäre gerade mal ein Core ausgelastet. Deshalb sollte man pro Core eine Node.js-Instanz laufen lassen und noch einen Core für andere Aufgaben freihalten. Das bedeutet aber auch, dass man sich um das Thema Session State kümmern muss.
Kriterien für den Einsatz von Node.js
Durch die Vermeidung von Threads benötigt Node.js tendenziell weniger Hauptspeicher und durch den Wegfall des Thread-Context-Wechsels auch weniger CPU-Zyklen; was aber ? wie gesagt ? erst bei einer hohen Anzahl konkurrierender Zugriffe relevant wird.
Machen aber die Kosten für die Server einen relevanten Anteil am Budget...
