Node.js (eBook)

Professionell hochperformante Software entwickeln

Robert Prediger, Ralph Winzinger (Autoren)

eBook Download: PDF | EPUB

2015
368 Seiten
Hanser, Carl (Verlag)
978-3-446-44721-9 (ISBN)

Infos

NODE.JS//

- What is Node.js and why should I care? Lernen Sie die Charakteristiken und typischen Einsatzgebiete von Node.js kennen.

- 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.

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



Robert Prediger ist seit über 25 Jahren in der Projektleitung und Softwareentwicklung tätig. Seit nunmehr 15 Jahren entwickelt er hauptsächlich Web-Anwendungen. Vor vier Jahren ist er auf Node.js gestoßen und war von Anfang an von dessen Stabilität und Geschwindigkeit fasziniert. Seither hat er bereits einige Projekte auf dieser technologischen Basis realisiert.

Ralph Winzinger realisiert seit knapp 20 Jahren Softwaresysteme und ist als Software-Architekt im Enterprise-Umfeld tätig. Neben dem täglichen Projektgeschäft beschäftigen ihn innovative Technologien und hoch skalierbare Systeme, wodurch sich das Interesse für Node.js ergeben hat und die damit verbundene Frage, ob es sich professionell im Enterprise-Bereich einsetzen lässt.

Inhalt

Vorwort 12
..... und ihre Motivation 14
Das Zielpublikum 14
Das Buch 15
Die Welt von JavaScript 16
1 Hello, Node.js 18
1.2 Installation 25
1.2.1 Windows 25
1.2.2 Mac OS X 25
1.2.3 Debian 26
1.2.4 Ubuntu 26
1.2.5 openSUSE und SLE 27
1.2.6 Fedora 28
1.2.7 RHEL und CentOS 28
1.3 IDEs 28
1.3.1 cloud9 29
1.3.2 WebStorm 31
1.3.3 Nodeclipse 32
1.3.4 WebMatrix/VisualStudio 33
1.3.5 Atom 33
1.4 nvm & nodist – mit Node-Versionen jonglieren
1.4.1 *ix-Systeme 35
1.4.2 Windows 36
1.5 npm – Node Packaged Modules 38
1.5.1 npm install – ein Modul laden 39
1.5.2 Global? Lokal? 40
1.5.3 package.json 41
1.5.4 Module patchen 41
1.5.5 Browserify 45
1.6 Kein Code? 47
2 You build it ..... 52
2.1 File I/O 53
2.1.1 Dateifunktionen in Node.js 53
2.1.2 Permissions 56
2.1.3 „watch“ – Änderungen im Auge behalten 57
2.1.4 Erweiterungen 58
2.1.4.1 Modul „fs-extra“ 59
2.1.4.2 Modul „file“ 60
2.1.4.3 Modul „find“ 60
2.1.4.4 Modul „properties“ 61
2.1.4.5 Modul „token-filter“ 62
2.2 Streams 63
2.2.1 Aus Streams lesen ..... 64
2.2.1.1 Objekte und Strings 65
2.2.2 ..... und in Streams schreiben 66
2.2.2.1 Streams verknüpfen 66
2.2.3 Eigene Streams implementieren 67
2.2.3.1 Ein Random-Number-Generator 68
2.2.3.2 Ein Daten-Lösch-Stream 70
2.2.3.3 Ein Verschlüsselungsserver für geheime Botschaften 71
2.2.4 Buffers and Strings 73
2.3 Daten für immer 74
2.3.1 Neo4j 74
2.3.1.1 Asynchron? 77
2.3.1.2 Querying Neo4j 78
2.3.1.3 Cypher für Abfragen 79
2.3.1.4 Indizes 81
2.3.1.5 Cypher für Batches 82
2.3.2 MongoDB 83
2.3.2.1 Wann sind Daten geschrieben? 84
2.3.2.2 _id 85
2.3.2.3 Die Mongo-API 85
2.4 Sichtbarkeit erzeugen – im Web 90
2.4.1 Middleware Framework Connect 90
2.4.1.1 Installation und einführendes Beispiel 91
2.4.1.2 Ausprägungen von Connect-Middleware-Typen 92
2.4.1.3 Integrierte Middleware-Komponenten 94
2.4.1.4 Middleware-Strukturen 102
2.4.2 Webentwicklung mit Express 107
2.4.2.1 Ready for take off: Installation und Einführungsbeispiel 108
2.4.2.2 Routing von HTTP-Anfragen 111
2.4.2.3 Views und Web-Templating 115
2.4.3 Express 4 116
2.4.4 Jade 118
2.4.4.1 Einbindung in Express 120
2.4.4.2 Sprachelemente von Jade 120
2.4.5 swig 133
2.4.5.1 Grundeinstellungen 133
2.4.5.2 Einbindung in Express 134
2.4.5.3 Sprachelemente von swig 135
2.4.5.4 Filterliste 138
2.4.5.5 Verketten von Filtern 141
2.4.5.6 Die swig-API 141
2.4.5.7 Eigene Funktionalitäten hinzufügen 143
2.4.6 Sessions & Authentifizierung
2.4.6.1 Ich will Kekse und biete dafür eine Session 145
2.4.6.2 Authentifizierung (Authentication) 147
2.4.6.3 Facebook 150
2.4.6.4 Twitter 151
2.4.6.5 Google 152
2.5 socket.io 153
2.5.1 Verbindung herstellen 154
2.5.2 Kommunikation 155
2.5.3 Broadcast 156
2.5.4 Private Daten 156
2.5.5 Rückantwort und Bestätigung 156
2.5.6 Namespaces 157
2.5.7 Räume 158
2.5.8 Autorisierung 160
2.5.8.1 Globale Autorisierung 160
2.5.8.2 Autorierung mit Namespaceses 161
2.5.8.3 Benutzerdefinierte Variablen und Autorisierung 162
2.5.9 Sessions mit „socket.io-session“ 162
2.5.9.1 socket.io-bundle 162
2.5.9.2 socket.io-passport 163
2.5.10 Version 1.0 164
2.6 Node.js und Webservices 168
2.6.1 SOAP-Services 168
2.6.1.1 Von und nach SOAP 170
2.6.2 REST-Services 180
2.6.2.1 Von Nomen, Verben und Routen 181
2.6.2.2 Ansichtssache? Verhandlungssache 185
2.6.2.3 Fehlermeldungen 187
2.6.2.4 Plug-ins 188
2.6.2.5 Sicherheit und Authentifizierung 193
2.6.3 XML-Verarbeitung 200
2.6.3.1 XML-Parsing 200
2.6.3.2 XML-Erzeugung und -Veränderung 206
2.6.3.3 Exkurs: Ein (selbst unterschriebenes) Zertifikat erstellen 208
2.7 Clustering 210
2.7.1 Methoden und Eigenschaften von cluster 214
2.7.1.1 isMaster/isWorker 214
2.7.1.2 fork/online – Event 214
2.7.1.3 exit – Event 215
2.7.1.4 workers 215
2.7.2 Der Master 215
2.7.2.1 setupMaster() 216
2.7.2.2 fork() 217
2.7.2.3 disconnect() 217
2.7.3 Der Worker 218
2.7.3.1 Die Attribute „id“ und „process“ 218
2.7.3.2 Das suicide-Attribut 218
2.7.3.3 kill() & disconnect()
2.8 Der Callback-Hölle entfliehen 219
2.8.1 async 220
2.8.1.1 Kontrollfluss 222
2.8.2 Q 229
2.8.2.1 then 231
2.8.2.2 fail 232
2.8.2.3 progress 232
2.9 Auf Herz und Nieren – 
233 
2.9.1 Mocha 234
2.9.1.1 Asynchrone Aufrufe und Timeouts 237
2.9.1.2 Set-Up & Tear-Down
2.9.1.3 Only & Skip
2.9.1.4 Mocha im Browser 240
2.9.2 Assert & Chai
2.9.2.1 Assert 242
2.9.2.2 Chai 244
2.9.3 Sinon 249
2.9.3.1 Spies 251
2.9.3.2 Stubs 252
2.9.3.3 Mocks 253
2.9.3.4 Faked Timers 254
2.9.4 Jasmine 255
2.9.5 Continuous Test 256
2.9.5.1 Mocha & Jasmine im Überwachungsmodus
2.9.5.2 Travis-CI 257
3 ..... you run it! 262
3.1.1 Patterns & Style
3.1.1.1 package.json 264
3.1.1.2 Import & Export
3.1.1.3 Tests 266
3.1.1.4 Dokumentation 267
3.1.2 Ausführbare Module 269
3.1.3 Module mit nativen Abhängigkeiten 271
3.1.3.1 OS Libraries 272
3.1.3.2 Sourcecode Dependencies 273
3.1.3.3 Hands-On mit Add-On 274
3.1.4 It works on my machine – Dependency Hell 283
3.1.5 Veröffentlichung von Modulen 286
3.1.5.1 Einen Benutzer erzeugen ..... 286
3.1.5.2 ..... und das Modul publizieren 286
3.2 Private Repositories für npm 287
3.2.1 reggie 288
3.2.1.1 Inbetriebnahme 288
3.2.1.2 reggie publish 289
3.2.1.3 Laden von Modulen 289
3.2.1.4 HTTP-Abfragen 291
3.2.1.5 npm-Client 291
3.2.2 sinopia 292
3.3 Deployment 294
3.3.1 Ein eigener Server 295
3.3.1.1 Docker 295
3.3.1.2 Modul „forever“ 297
3.3.1.3 pm2 301
3.3.1.4 git-deploy 307
3.3.2 Cloud 308
3.3.2.1 PaaS-Provider 308
3.3.2.2 Server-Systeme 312
3.4 Was Node.js antreibt ..... V8 Engine 313
3.4.1 Architektur 314
3.4.2 Die Performance-Tricks 316
3.4.2.1 „Fast Property Access“ 317
3.4.2.2 Arrays 318
3.4.2.3 Kein Interpretationsspielraum 319
3.4.2.4 Garbage Collection 319
3.4.2.5 Caching Modules 320
3.5 Logging 321
3.5.1 debug 321
3.5.2 winston 324
3.5.2.1 Transportmechanismen 324
3.5.2.2 Logger-Instanz 325
3.5.2.3 Logging Levels 326
3.5.2.4 Strukturierte Daten loggen 326
3.5.2.5 Profiling 327
3.5.3 Bunyan 328
3.5.3.1 Konfiguration 329
3.5.3.2 Child Logger 330
3.5.3.3 Die „src“-Option 331
3.5.3.4 Streams 331
3.6 Debugging 332
3.6.1 Der Node-Debugger 332
3.6.2 Node-Inspector 335
3.7 Monitoring 338
3.7.1 Kommerzielle Monitoring-Services 340
3.7.1.1 New Relic 340
3.7.1.2 Nodetime 342
3.7.1.3 StrongOps 346
3.8 Alternativen zu Node.js 351
3.8.1 Vert.x – die polyglotte JVM-Alternative 352
3.8.1.1 Architektur 352
3.8.1.2 Hands-On 359
3.8.1.3 Node.js oder Vert.x? 364
Index 366

Textauszug

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:

result = database.query("SELECT * FROM user"); result.get…

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 Meinung 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:

database.query( "SELECT * FROM user", function(result) { result… } );

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:

function schritt1(result) { ... database.query("...", schritt2); } function schritt2(result) { ... } database.query("...", schritt1);

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...

Produkt-Details

• Erscheint lt. Verlag: 6.8.2015
• Verlagsort: München
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik ► Web / Internet
• Schlagworte: Enterprise • Framework • Google V8 • JavaScript • Qualitätssicherung • security • Webentwicklung
• ISBN-10: 3-446-44721-0 / 3446447210
• ISBN-13: 978-3-446-44721-9 / 9783446447219