Was in der Webentwicklung nicht immer alles „the next big thing“ sein soll! Wer jeder Jubelmeldung nachgeht, wird sehr bald sehr unglücklich. Da hilft nur das gute alte Spreu-vom-Weizen-Trennen. Also unterziehen wir heute Node.js einem kleinen Hype-Check.
Node.js kurz gefasst:
- Webserver, aufbauend auf der JavaScript-Engine Google V8
- im Rennen seit Ende 2009
- entwickelt von Ryan Dahl, der auch zu den Hauptentwicklern von V8 gehörte
- eventbasierter JS-Server
- bietet hohen Durchsatz im Vergleich zu herkömmlichen Servern
- ermöglicht JavaScript-Nutzung nicht nur im Browser, sondern auch auf der Server-Seite
Event- vs. Threadgesteuert
Dahl und Co setzen mit Node.js an einem der Engpässe an, die bei herkömmlichen Servern für die meisten Verzögerungen sorgen: dem threadgesteuerten Verarbeiten von Anfragen. Einem routinierten Schalterbeamten gleich, arbeiten herkömmliche Server eine Aufgabe nach der anderen ab: Ein User stellt beispielsweise eine Datenbankanfrage. Dieser Thread läuft an, wartet auf eine Antwort und blockiert für diese Zeit die Möglichkeit, weitere Anfragen zu stellen. Natürlich handelt es sich hier um Millisekunden – doch die summieren sich.
Die Pommes-Blockade
Als klassischer Vergleich für die thread- oder eventbasierte Arbeitsweise gilt das Schlangestehen im Fastfood-Restaurant: Während die Bestellung des ersten Kunden in der Schlange, nennen wir sie „Hamburger, Cola und Pommes“, zusammengestellt und abkassiert wird, warten alle anderen. Die herkömmliche Lösung lautet: mehr Servicekräfte an der Theke, die dann parallel arbeiten. Übertragen auf das IT-Beispiel heißt das: mehr Server/Threads und folglich höhere Hardwarekosten.
Eventgesteuertes Arbeiten läuft folgendermaßen: Bestellungen werden aufgenommen, an die Küche weitergeleitet, abkassiert und während der Kunde (manchmal sogar mit einem Timer ausgestattet) noch auf seine halbgaren Pommes wartet, kann er mit dem Burger anfangen. Der Mitarbeiter am Schalter nimmt inzwischen schon die nächste Bestellung auf. In einer Node.js-Architektur bedeutet das, dass ein Event-Loop abläuft: Im Hintergrund rattert die Datenbank-Abfrage des ersten Requests, gleichzeitig kann bereits der nächste bearbeitet werden. Ist der erste erledigt, werden die Ergebnisse via Callback-Funktion ausgeliefert: non-blocking heißt das Zauberwort.
Das Rad ist schon erfunden
Im Unterschied zu den meisten Java-Applikationen u.a. müssen Node.js-Apps Spezialaufgaben, wie etwa die Image-Skalierung, an externe Tools delegieren. Das Modell für ein solches arbeitsteiliges Arbeiten stammt offensichtlich aus der Unix-Welt: Verschiedene kleine Programme arbeiten Hand in Hand – und zwar exakt an dem Bereich, für den sie optimiert sind. Node.js tritt also nicht mit Anspruch an, das Rad neu zu erfinden. Es schließt eine vorhandene Lücke, bezieht dabei aber das Beste der altbewährten Tools mit ein.
Kein Hype ohne Haken
Man merkt Node.js zwar die jahrzehntelange Erfahrung der Entwickler an. Nichtsdestotrotz hat es noch einige Kinderkrankheiten. Von einer Version zur nächsten ändert sich beispielsweise oft so viel, dass bei Upgrades immer nochzu Kompatibilitätsproblemen kommen kann.
Dass mit Node.js nun auch JavaScript im Backend eingesetzt werden kann, ist eigentlich ein Riesenvorteil. Viele Firmen haben nämlich mit ihren JavaScript-Entwicklern schon Fachkräfte vor Ort. Allerdings erfordern Backend- und Frontend-Programmieren immer unterschiedliche Kenntnisse, so dass in der Praxis oft das Wissen fehlt.
Performance im Praxistext
Als IT:Agenten haben wir uns schon früh entschieden, dass sich die Einarbeitung in Node.js lohnt – zumindest wenn man weiß, für welche Anwendungszwecke es geeignet ist. Die Streamsite für die Pro7/Sat1-Show „The Voice of Germany“ ist genau so ein Projekt. Diese interaktive User-Plattform zur Show muss während der laufenden Sendung sehr hohen Traffic bewältigen: Zuschauer können kommentieren, abstimmen etc, Publikums-Chat, Twitter-Botschaften und diverse Nachrichten laufen hier zusammen. Das Projekt ist zudem Multi-Screen-tauglich, sprich es findet eine direkte Kommunikation zwischen Fernsehern und mobilen Endgeräten, iPads etwa, statt. Herkömmliche Server wären schnell überlastet, da jeder Request einzeln vom Client angefragt werden müsste. Node.js hält dagegen die Verbindung offen, so dass eine ständige Aktualisierung stattfinden kann, ohne den Server unnötig zu belasten und ohne zu blockieren.
Der Mind-Break
Eventbasierte Entwicklung ist allerdings keine Erfindung von node.js. Bereits die Jahrzehnte alte PL/1 oder das alte Visual Basic folgten diesem Paradigma. Was jedoch rechtfertigt diesen Hype dann? Ganz einfach: Der Mind-Break von einer statisch anmutenden Klick-Warten-Eingeben-Klick-Warten-Eingeben-Anwendung zu einer live gestreamten Website. War Streaming bisher vor allem Audio und Video vorbehalten, wird, aufbauend auf altbewährten Konzepten, nun jeder Inhalt und jede Veränderung einer Seite „streambar“. Die Ehre gebührt in diesem Fall zunächst HTML5 und den damit verbundenen Standards sowie ECMA Script. Diese haben die Clients erst dazu befähigt, solche Streams vernünftig zu verarbeiten.