Node.js In Action

MEAP Edition Manning Early Access Program Node.js in Action version 14 Copyright 2012 Manning Publications For more information on this and other Manning titles go to www.manning.com ©Manning Publications Co. Please post comments or corrections to the Author Online forum: http://www.manning-sandbox.com/forum.jspa?forumID=790 ©Manning Publications Co. Please post comments or corrections to the Author Online forum: http://www.manning-sandbox.com/forum.jspa?forumID=790 brief contents PART 1: NODE FUNDAMENTALS Chapter 1: Welcome to Node.js Chapter 2: Building a multi-room chat application Chapter 3: Node programming fundamentals PART 2: WEB APPLICATION DEVELOPMENT WITH NODE Chapter 4: Buiding Node web applications Chapter 5: Storing Node application data Chapter 6: Testing Node applications Chapter 7: Connect Chapter 8: Connect’s built-in middleware Chapter 9: Express Chapter 10: Web application templating Chapter 11: Deploying Node web applications PART 3: GOING FURTHER WITH NODE Chapter 12: Beyond web servers Chapter 13: The Node ecosystem APPENDIXES Appendix A: Installing Node and community add-ons Appendix B: Debugging Node 1 This chapter covers: What Node.js is JavaScript on the server Asyncronous and evented nature of Node Types of applications Node is designed for Sample Node programs So what is Node.js? It’s likely you have heard the term. Maybe you use Node. Maybe you are curious about it. At this point in time, Node is very popular and young (it debuted in 2009 ). It is the second most watched project on GitHub , has1 2 quite a following in its Google group and IRC channel and has more than 15,0003 4 community modules published in NPM (the package manager) . All this to say, 5 .there is considerable traction behind this platform Footnote 1 First talk on Node by creator Ryan Dahl - http://jsconf.eu/2009/video_nodejs_by_ryan_dahl.htmlm Footnote 2 https://github.com/popular/starredm Footnote 3 http://groups.google.com/group/nodejsm Footnote 4 http://webchat.freenode.net/?channels=node.jsm Footnote 5 http://npmjs.orgm The official website (nodejs.org) defines Node as "a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js Welcome to Node.js ©Manning Publications Co. Please post comments or corrections to the Author Online forum: http://www.manning-sandbox.com/forum.jspa?forumID=790 1 uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices." In this chapter, we'll look at: Why JavaScript matters for server side development How the browser handles I/O using JavaScript How Node handles I/O on the server What are DIRTy applications and why they are a good fit for Node A sampling of a few basic Node programs Let's first turn our attention to JavaScript... For better or worse JavaScript is the world’s most popular programming language6 . If you have done any programming for the web, it is unavoidable. JavaScript, because of the sheer reach of the web, is the dream that"write once, run anywhere" Java had back in the 1990s. Footnote 6 "JavaScript: Your New Overlord” - http://www.youtube.com/watch?v=Trurfqh_6fQm Around the "Ajax revolution" in 2005, JavaScript went from being a "toy" language to something people write real and significant programs with. Some of the notable firsts were Google Maps and Gmail but today there are a host of web applications from Twitter to Facebook to Github. Since the release of Google Chrome in late 2008, JavaScript performance has been improving at an incredibly fast rate due to heavy competition between browser vendors (i.e. Mozilla, Microsoft, Apple, Opera, and Google). The performance of these modern JavaScript virtual machines are literally changing the types of applications we can build on the web . A compelling and frankly7 mind-blowing example of this is jslinux , a PC emulator running in JavaScript8 where you can load a Linux kernel, interact with the terminal session, and compile a C program all in your browser. Footnote 7 For some examples: http://www.chromeexperiments.com/m Footnote 8 http://bellard.org/jslinux/m Node specifically uses V8, the virtual machine that powers Google Chrome, for server-side programming. V8 gives a huge boost in performance because it cuts out 1.1 Built on JavaScript ©Manning Publications Co. Please post comments or corrections to the Author Online forum: http://www.manning-sandbox.com/forum.jspa?forumID=790 2 the middleman, prefering straight compilation into native machine code over executing bytecode or using an interpreter. Because Node uses JavaScript on the server there are other benefits: Developers can write web applications in one language, which helps by: reducing the "context" switch between client and server development, and allowing for code sharing between client and server (e.g. reusing the same code for form validation or game logic). JSON is a very popular data interchange format today and it is native JavaScript. JavaScript is the language used in various NoSQL databases (e.g. CouchDB/MongoDB) so interfacing with them is a natural fit (e.g. MongoDB shell and query language is JS, CouchDB map/reduce is JS). JavaScript is a compilation target and there are a number of languages that compile to it already .9 F o o t n o t e 9 m https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS Node uses one virtual machine (V8) that keeps up with the ECMAScript standard. In other words, you don’t have to wait for all the browsers to10 catch up to use new JavaScript language features in Node. Footnote 10 http://en.wikipedia.org/wiki/ECMAScriptm Who knew JavaScript would end up being a compelling language for writing server-side applications? Yet, due to its sheer reach, performance, and other characteristics mentioned previously, Node has gained a lot of traction. JavaScript is only one piece of puzzle though, the Node uses JavaScript is even moreway compelling. To understand the Node environment, let's dive into the JavaScript environment we are most familiar with: the browser. ©Manning Publications Co. Please post comments or corrections to the Author Online forum: http://www.manning-sandbox.com/forum.jspa?forumID=790 3 Node provides an event-driven and asynchronous platform for server-side JavaScript. It brings JavaScript to the server much in the same way a browser brings JavaScript to the client. It is important to understand how the browser works in order to understand how Node works. Both are event-driven (i.e. use an event loop ) and non-blocking when handling I/O (i.e. use asynchronous I/O ). Let’s11 12 look an example to explain what that means. Footnote 11 http://en.wikipedia.org/wiki/Event_loopm Footnote 12 http://en.wikipedia.org/wiki/Asynchronous_I/Om Take this common snippet of jQuery performing an Ajax request using XHR :13 Footnote 13 http://en.wikipedia.org/wiki/XMLHttpRequestm $.post('/resource.json', function (data) { console.log(data); }); // script execution continues In this program we perform an HTTP request for . When theresource.json response comes back, an anonymous function is called (a.k.a. the "callback" in this context) containing the argument , which is the data received from thatdata request. Notice that the code was written like this:not var data = $.post('/resource.json'); console.log(data); In this example, the assumption is that the response for resource.json would be stored in the variable and that the data when it is ready console.log function . The I/O operation (e.g. Ajax request) wouldwill not execute until then "block" script execution from continuing until ready. Since the browser is , if this request took 400ms to return, any other events happeningsingle-threaded on that page would wait until then before execution. You can imagine the poor user experience, for example, if an animation was paused or the user was trying to interact with the page somehow. I/O does not block execution I/O blocks execution until finished 1.2 Asynchronous and Evented: The Browser ©Manning Publications Co. Please post comments or corrections to the Author Online forum: http://www.manning-sandbox.com/forum.jspa?forumID=790 4 Thankfully that is not the case. When I/O happens in the browser, it happens outside of the event loop (i.e. main script execution) and then an "event" is emitted when the I/O is finished which is handled by a function (often called the14 "callback") as seen in figure 1.1: Footnote 14 For completeness, there are a few exceptions which "block" execution in the browser and usage ism typically discouraged: alert, prompt, confirm, and synchronous XHR. $.post('/resource.json', function (data) { console.log(data); }) EVENT LOOP Ajax request made for "resource.json" resource.json 4 1 2 user interaction - "onclick" another Ajax response User clicks, "onclick" event handled 1 2 ...waiting... 3Fin ally , Aja x r es pon se fo r " res ou rc e.js on " co mes back and i s han dled in the callb ack 4 Another Ajax response comes back3 Figure 1.1 An example of non-blocking I/O in the browser The I/O is happening asynchronously and not "blocking" the script execution allowing the event loop to respond to whatever other interactions or requests that are being performed on the page. This enables the browser to be responsive to the client and handle a lot of interactivity on the page. Make a note of that and let’s switch over to the server. For the most part, we are familiar with a conventional I/O model for server-side programming like the "blocking" jQuery example in section 1.2. Here's an example of how it looks in PHP: $result = mysql_query('SELECT * FROM myTable'); print_r($result); Execution stops until DB query completes 1.3 Asynchronous and Evented: The Server ©Manning Publications Co. Please post comments or corrections to the Author Online forum: http://www.manning-sandbox.com/forum.jspa?forumID=790 5 We are doing some I/O and the process is blocked from continuing until all the data has come back. For many applications this model is fine and is easy to follow. What may not be apparent is that the process has state/memory and is essentially doing "nothing" until the I/O is completed. That could take 10ms to minutes depending on the latency of the I/O operation. Latency can be unexpected as well, for example: The disk is performing a maintainence operation, pausing reads/writes A database query is slower because of increased load Pulling a resource from "sitexyz.com" is sluggish today for some reason If a program blocks on I/O, what does the server do when there are more requests to handle? Typically this means that we use a multi-threaded approach. A common implementation is to use one thread per connection and setup a thread pool for those connections. You can think of threads as computational workspaces in which the processor works on one task. In many cases, a thread is contained inside a process and maintains its own working memory. Each thread handles one or more server connections. While this sounds like a natural way to delegate server labor, to developers who've been doing this a long time, managing threads within an application can be complex. Also, when a large number of threads is needed to handle many concurrent server connections, threading can tax operating system resources. Threads require CPU to perform context-switches as well as additional RAM. To illustrate this, let's look at a benchmark (shown in Figure 1.2) comparing NGINX and Apache. NGINX , if you aren’t familiar with it, is an HTTP server15 like Apache but instead of using the multi-threaded approach with blocking I/O, it uses an event loop with asynchronous I/O (like the browser and Node). Because of these design choices, NGINX is often able to handle more requests and connected clients, making it a more responsive solution.16 Footnote 15 http://nginx.com/m Footnote 16 If you are more interested in this problem: http://www.kegel.com/c10k.htmlm ©Manning Publications Co. Please post comments or corrections to the Author Online forum: http://www.manning-sandbox.com/forum.jspa?forumID=790 6 Number of requests handled per second Programs utilizing an asynchronous and evented approach, like NGINX, are able to handle more communication between the client and the server Number of established client/server connections open 1 2 1 2 3 3 4 4 Such programs are also more responsive; in this example, at 3500 connections, each NGINX request is serviced roughly 3x faster Figure 1.2 WebFaction Apache / NGINX benchmark: http://jppommet.com/from-webfaction-a-little-holiday-present-1000 In Node, I/O almost always is performed outside of the main event loop allowing the server to stay efficient and responsive like NGINX. This makes it much harder for a process to become I/O bound because I/O latency isn’t going to crash your server or use the resources it would if you were blocking. It allows the server to be lightweight on what are typically the slowest operations a server performs. .17 Footnote 17 More details at http://nodejs.org/about/m This mix of an event-driven and asynchronous model and the widely accessible JavaScript language helps open up a exciting world of data-intensive real-time applications. There actually is acronym for the types of applications Node is designed for: .DIRT It stands for applications. Since Node itself is verydata-intensive real-time lightweight on I/O, it is good at shuffling/proxying data from one pipe to another. It allows a server to hold open a number of connections while handling many requests and keeping a small memory footprint. It is designed to be responsive like the browser. Real-time applications are a new use-case of the web. Many web applications 1.4 DIRTy Applications ©Manning Publications Co. Please post comments or corrections to the Author Online forum: http://www.manning-sandbox.com/forum.jspa?forumID=790 7 now provide information virtually instantly, implementing things like: online whiteboard collaboration, realtime pinpointing of approaching public transit buses, and multiplayer games. Whether its existing applications being enhanced with real-time components or completely new types of applications, the web is moving towards more responsive and collaborative environments. These new types of web applications, however, call for a platform that can respond almost instantly to a large number of concurrent users. Node is good at this and not just for web, but also other I/O heavy applications. A good example of a DIRTy application written with Node is Browserling18 (shown in Figure 1.3). The site allows in-browser use of other browsers. This is extremely useful to front-end web developers as it frees them from having to install numerous browsers and operating systems solely for testing. Browserling leverages a Node-driven project called StackVM, which manages virtual machines (VMs), created using the QEMU ("Quick Emulator") emulator. QEMU emulates the CPU and peripherals needed to run the browser. Footnote 18 browserling.comm Figure 1.3 Browserling: Interactive cross-browser testing utilizing Node.js Browserling has VMs run test browsers and then relays the keyboard and mouse input data from the user's browser to the emulated browser which, in turn, streams the repainted regions of the emulated browser and redraws them on the canvas of the user's browser. This is illustrated in figure 1.4. ©Manning Publications Co. Please post comments or corrections to the Author Online forum: http://www.manning-sandbox.com/forum.jspa?forumID=790 8 Browserling.com Emulated Browser (QEMU) Node.jsWebSocketsHTML5 Canvas users mouse and keyboard events updated images in the form of data uris 1 2 1 In the browser, user's mouse and keyboard events are passed over WebSockets in real time to Node.js which in turn passes those to the emulator 2 The repainted regions of the emulated browser affected by the user interaction are streamed back though Node and WebSockets and drawn on the canvas in the browser Figure 1.4 Browserling Workflow Browserling also provides a complimentary project using Node called Testling allowing you to run a tests suites against multiple browsers in parallel from the19 command line. Footnote 19 testling.comm Browserling and Testling are good examples of a DIRTy applications and the infrustructure for building a scalable network applications like it are at play when you sit down to write your first Node application. Let's take a look at how Node's API provides this tooling right out of the box. Node was built from the ground up to have an event-driven and asynchronous model. JavaScript has never had standard I/O libraries, which are common to server-side languages, the "host" environment has always determined this for JavaScript. The most common "host" environment for JavaScript, the one most developers are used to, is the browser which is event-driven and asynchronous. Node tries to keep consistency between the browser by reimplementing common "host" objects, for example: Timer API (e.g. )setTimeout 1.5 DIRTy by Default ©Manning Publications Co. Please post comments or corrections to the Author Online forum: http://www.manning-sandbox.com/forum.jspa?forumID=790 9 Console API (e.g. )console.log Node also includes a "core" set of modules for many types of network and file I/O. These include modules for: HTTP, TLS, HTTPS, File System (POSIX), Datagram (UDP), and NET (TCP). The "core" is intentially small, low-level, and uncomplicated including just the building blocks for I/O based applications. 3rd-party modules build upon these blocks to offer greater abstractions for common problems. SIDEBAR Platform vs. Framework Node is a platform for JavaScript applications which is not to be confused with a framework. It is a common misconception to think of Node as "Rails" or "Django" for JavaScript when it is much lower level. Although if you are interested in frameworks for web applications, we will talk about a popular one for Node called Express later on in this book. After all this discussion you probably are wondering what does Node code look like? Let's cover a few simple examples: A simple asyncronous example A "hello world" web server An example of streams In section 1.2, we looked at this Ajax example using jQuery: $.post('/resource.json', function (data) { console.log(data); }); Let's do something similar in Node but instead using the file system ( )fs module to load from disk. Notice how similar the program isresource.json compared to the previous jQuery example. var fs = require('fs'); fs.readFile('./resource.json', function (er, data) { console.log(data); 1.5.1 Simple Async Example ©Manning Publications Co. Please post comments or corrections to the Author Online forum: http://www.manning-sandbox.com/forum.jspa?forumID=790 10 }) In this program, we read the file from disk. When all theresource.json data is read, an anonymous function is called (a.k.a. the "callback") containing the arguments , if any error occured, and , which is the file data.er data The process "loops" behind the scenes able to handle any other operations that may come its way until the data is ready. All the evented/async benefits we talked about earlier are in play automatically. The difference here is that instead of making an Ajax request from the