Node.js By Example

3.7 (3 reviews total)
By Krasimir Tsonev
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Node.js Fundamentals

About this book

Node.js is a JavaScript-driven technology, which means that developers can use the same language to write backend code. Its growing community and the large amount of available modules make Node.js one of the most attractive development environments.

Node.js By Example covers Node.js fundamentals and teaches you how to use its technology to architect a project. It shows you how to manage an application's assets and how to implement the Model-View-Controller pattern. The next few chapters demonstrate how to develop the features of your social network. It also empowers you to communicate with a database, including storing, retrieving, and deleting data. The book ends by discussing the most popular ways to test your user interface in an efficient way.

Publication date:
May 2015


Chapter 1. Node.js Fundamentals

Node.js is one of the most popular JavaScript-driven technologies nowadays. It was created in 2009 by Ryan Dahl and since then, the framework has evolved into a well-developed ecosystem. Its package manager is full of useful modules and developers around the world have started using Node.js in their production environments. In this chapter, we will learn about the following:

  • Node.js building blocks

  • The main capabilities of the environment

  • The package management of Node.js


Understanding the Node.js architecture

Back in the days, Ryan was interested in developing network applications. He found out that most high performance servers followed similar concepts. Their architecture was similar to that of an event loop and they worked with nonblocking input/output operations. These operations would permit other processing activities to continue before an ongoing task could be finished. These characteristics are very important if we want to handle thousands of simultaneous requests.

Most of the servers written in Java or C use multithreading. They process every request in a new thread. Ryan decided to try something different—a single-threaded architecture. In other words, all the requests that come to the server are processed by a single thread. This may sound like a nonscalable solution, but Node.js is definitely scalable. We just have to run different Node.js processes and use a load balancer that distributes the requests between them.

Ryan needed something that is event-loop-based and which works fast. As he pointed out in one of his presentations, big companies such as Google, Apple, and Microsoft invest a lot of time in developing high performance JavaScript engines. They have become faster and faster every year. There, event-loop architecture is implemented. JavaScript has become really popular in recent years. The community and the hundreds of thousands of developers who are ready to contribute made Ryan think about using JavaScript. Here is a diagram of the Node.js architecture:

In general, Node.js is made up of three things:

On top of these three blocks, we have several bindings that expose low-level interfaces. The rest of Node.js is written in JavaScript. Almost all the APIs that we see as built-in modules and which are present in the documentation, are written in JavaScript.


Installing Node.js

A fast and easy way to install Node.js is by visiting and downloading the appropriate installer for your operating system. For OS X and Windows users, the installer provides a nice, easy-to-use interface. For developers that use Linux as an operating system, Node.js is available in the APT package manager. The following commands will set up Node.js and Node Package Manager (NPM):

sudo apt-get update
sudo apt-get install nodejs
sudo apt-get install npm

Running Node.js server

Node.js is a command-line tool. After installing it, the node command will be available on our terminal. The node command accepts several arguments, but the most important one is the file that contains our JavaScript. Let's create a file called server.js and put the following code inside:

var http = require('http');
http.createServer(function (req, res) {
   res.writeHead(200, {'Content-Type': 'text/plain'});
   res.end('Hello World\n');
}).listen(9000, '');
console.log('Server running at');


Downloading the example code

You can download the example code files from your account at for all the Packt Publishing books that you have purchased. If you purchased this book elsewhere, you can visit and register to have the files e-mailed directly to you.

If you run node ./server.js in your console, you will have the Node.js server running. It listens for incoming requests at localhost ( on port 9000. The very first line of the preceding code requires the built-in http module. In Node.js, we have the require global function that provides the mechanism to use external modules. We will see how to define our own modules in a bit. After that, the scripts continue with the createServer and listen methods on the http module. In this case, the API of the module is designed in such a way that we can chain these two methods like in jQuery.

The first one (createServer) accepts a function that is also known as a callback, which is called every time a new request comes to the server. The second one makes the server listen.

The result that we will get in a browser is as follows:


Defining and using modules

JavaScript as a language does not have mechanisms to define real classes. In fact, everything in JavaScript is an object. We normally inherit properties and functions from one object to another. Thankfully, Node.js adopts the concepts defined by CommonJS—a project that specifies an ecosystem for JavaScript.

We encapsulate logic in modules. Every module is defined in its own file. Let's illustrate how everything works with a simple example. Let's say that we have a module that represents this book and we save it in a file called book.js:

// book.js = 'Node.js by example'; = function() {
   console.log('I am reading ' +;

We defined a public property and a public function. Now, we will use require to access them:

// script.js
var book = require('./book.js');
console.log('Name: ' +;;

We will now create another file named script.js. To test our code, we will run node ./script.js. The result in the terminal looks like this:

Along with exports, we also have module.exports available. There is a difference between the two. Look at the following pseudocode. It illustrates how Node.js constructs our modules:

var module = { exports: {} };
var exports = module.exports;
// our code
return module.exports;

So, in the end, module.exports is returned and this is what require produces. We should be careful because if at some point we apply a value directly to exports or module.exports, we may not receive what we need. Like at the end of the following snippet, we set a function as a value and that function is exposed to the outside world: = 'Node.js by example'; = function() {
   console.log('Iam reading ' +;
module.exports = function() {  ... }

In this case, we do not have an access to .name and .read. If we try to execute node ./script.js again, we will get the following output:

To avoid such issues, we should stick to one of the two options—exports or module.exports—but make sure that we do not have both.

We should also keep in mind that by default, require caches the object that is returned. So, if we need two different instances, we should export a function. Here is a version of the book class that provides API methods to rate the books and that do not work properly:

// book.js
var ratePoints = 0;
exports.rate = function(points) {
   ratePoints = points;
exports.getPoints = function() {
   return ratePoints;

Let's create two instances and rate the books with different points value:

// script.js
var bookA = require('./book.js');
var bookB = require('./book.js');
console.log(bookA.getPoints(), bookB.getPoints());

The logical response should be 10 20, but we got 20 20. This is why it is a common practice to export a function that produces a different object every time:

// book.js
module.exports = function() {
   var ratePoints = 0;
   return {
      rate: function(points) {
         ratePoints = points;
      getPoints: function() {
         return ratePoints;

Now, we should also have require('./book.js')() because require returns a function and not an object anymore.


Managing and distributing packages

Once we understand the idea of require and exports, we should start thinking about grouping our logic into building blocks. In the Node.js world, these blocks are called modules (or packages). One of the reasons behind the popularity of Node.js is its package management.

Node.js normally comes with two executables—node and npm. NPM is a command-line tool that downloads and uploads Node.js packages. The official site,, acts as a central registry. When we create a package via the npm command, we store it there so that every other developer may use it.

Creating a module

Every module should live in its own directory, which also contains a metadata file called package.json. In this file, we have set at least two properties—name and version:

   "name": "my-awesome-nodejs-module",
   "version": "0.0.1"

We can place whatever code we like in the same directory. Once we publish the module to the NPM registry and someone installs it, he/she will get the same files. For example, let's add an index.js file so that we have two files in the package:

// index.js
console.log('Hello, this is my awesome Node.js module!');

Our module does only one thing—it displays a simple message to the console. Now, to upload the modules, we need to navigate to the directory containing the package.json file and execute npm publish. This is the result that we should see:

We are ready. Now our little module is listed in the Node.js package manager's site and everyone is able to download it.

Using modules

In general, there are three ways to use the modules that are already created. All three ways involve the package manager:

  • We may install a specific module manually. Let's say that we have a folder called project. We open the folder and run the following:

    npm install my-awesome-nodejs-module

    The manager automatically downloads the latest version of the module and puts it in a folder called node_modules. If we want to use it, we do not need to reference the exact path. By default, Node.js checks the node_modules folder before requiring something. So, just require('my-awesome-nodejs-module') will be enough.

  • The installation of modules globally is a common practice, especially if we talk about command-line tools made with Node.js. It has become an easy-to-use technology to develop such tools. The little module that we created is not made as a command-line program, but we can still install it globally by running the following code:

    npm install my-awesome-nodejs-module -g

    Note the -g flag at the end. This is how we tell the manager that we want this module to be a global one. When the process finishes, we do not have a node_modules directory. The my-awesome-nodejs-module folder is stored in another place on our system. To be able to use it, we have to add another property to package.json, but we'll talk more about this in the next section.

  • The resolving of dependencies is one of the key features of the package manager of Node.js. Every module can have as many dependencies as you want. These dependences are nothing but other Node.js modules that were uploaded to the registry. All we have to do is list the needed packages in the package.json file:

        "name": "another-module", 
        "version": "0.0.1", 
        "dependencies": {
            "my-awesome-nodejs-module": "0.0.1"   

    Now we don't have to specify the module explicitly and we can simply execute npm install to install our dependencies. The manager reads the package.json file and saves our module again in the node_modules directory. It is good to use this technique because we may add several dependencies and install them at once. It also makes our module transferable and self-documented. There is no need to explain to other programmers what our module is made up of.

Updating our module

Let's transform our module into a command-line tool. Once we do this, users will have a my-awesome-nodejs-module command available in their terminals. There are two changes in the package.json file that we have to make:

   "name": "my-awesome-nodejs-module",
   "version": "0.0.2",
   "bin": "index.js"

A new bin property is added. It points to the entry point of our application. We have a really simple example and only one file—index.js.

The other change that we have to make is to update the version property. In Node.js, the version of the module plays important role. If we look back, we will see that while describing dependencies in the package.json file, we pointed out the exact version. This ensures that in the future, we will get the same module with the same APIs. Every number from the version property means something. The package manager uses Semantic Versioning 2.0.0 ( Its format is MAJOR.MINOR.PATCH. So, we as developers should increment the following:

  • MAJOR number if we make incompatible API changes

  • MINOR number if we add new functions/features in a backwards-compatible manner

  • PATCH number if we have bug fixes

Sometimes, we may see a version like 2.12.*. This means that the developer is interested in using the exact MAJOR and MINOR version, but he/she agrees that there may be bug fixes in the future. It's also possible to use values like >=1.2.7 to match any equal-or-greater version, for example, 1.2.7, 1.2.8, or 2.5.3.

We updated our package.json file. The next step is to send the changes to the registry. This could be done again with npm publish in the directory that holds the JSON file. The result will be similar. We will see the new 0.0.2 version number on the screen:

Just after this, we may run npm install my-awesome-nodejs-module -g and the new version of the module will be installed on our machine. The difference is that now we have the my-awesome-nodejs-module command available and if you run it, it displays the message written in the index.js file:


Introducing built-in modules

Node.js is considered a technology that you can use to write backend applications. As such, we need to perform various tasks. Thankfully, we have a bunch of helpful built-in modules at our disposal.

Creating a server with the HTTP module

We already used the HTTP module. It's perhaps the most important one for web development because it starts a server that listens on a particular port:

var http = require('http');
http.createServer(function (req, res) {
   res.writeHead(200, {'Content-Type': 'text/plain'});
   res.end('Hello World\n');
}).listen(9000, '');
console.log('Server running at');

We have a createServer method that returns a new web server object. In most cases, we run the listen method. If needed, there is close, which stops the server from accepting new connections. The callback function that we pass always accepts the request (req) and response (res) objects. We can use the first one to retrieve information about incoming request, such as, GET or POST parameters.

Reading and writing to files

The module that is responsible for the read and write processes is called fs (it is derived from filesystem). Here is a simple example that illustrates how to write data to a file:

var fs = require('fs');
fs.writeFile('data.txt', 'Hello world!', function (err) {
   if(err) { throw err; }
   console.log('It is saved!');

Most of the API functions have synchronous versions. The preceding script could be written with writeFileSync, as follows:

fs.writeFileSync('data.txt', 'Hello world!');

However, the usage of the synchronous versions of the functions in this module blocks the event loop. This means that while operating with the filesystem, our JavaScript code is paused. Therefore, it is a best practice with Node to use asynchronous versions of methods wherever possible.

The reading of the file is almost the same. We should use the readFile method in the following way:

fs.readFile('data.txt', function(err, data) {
   if (err) throw err;

Working with events

The observer design pattern is widely used in the world of JavaScript. This is where the objects in our system subscribe to the changes happening in other objects. Node.js has a built-in module to manage events. Here is a simple example:

var events = require('events');
var eventEmitter = new events.EventEmitter();
var somethingHappen = function() {
   console.log('Something happen!');
.on('something-happen', somethingHappen)

The eventEmitter object is the object that we subscribed to. We did this with the help of the on method. The emit function fires the event and the somethingHappen handler is executed.

The events module provides the necessary functionality, but we need to use it in our own classes. Let's get the book idea from the previous section and make it work with events. Once someone rates the book, we will dispatch an event in the following manner:

// book.js
var util = require("util");
var events = require("events");
var Class = function() { };
util.inherits(Class, events.EventEmitter);
Class.prototype.ratePoints = 0;
Class.prototype.rate = function(points) {
   ratePoints = points;
Class.prototype.getPoints = function() {
   return ratePoints;
module.exports = Class;

We want to inherit the behavior of the EventEmitter object. The easiest way to achieve this in Node.js is by using the utility module (util) and its inherits method. The defined class could be used like this:

var BookClass = require('./book.js');
var book = new BookClass();
book.on('rated', function() {
   console.log('Rated with ' + book.getPoints());

We again used the on method to subscribe to the rated event. The book class displays that message once we set the points. The terminal then shows the Rated with 10 text.

Managing child processes

There are some things that we can't do with Node.js. We need to use external programs for the same. The good news is that we can execute shell commands from within a Node.js script. For example, let's say that we want to list the files in the current directory. The file system APIs do provide methods for that, but it would be nice if we could get the output of the ls command:

// exec.js
var exec = require('child_process').exec;
exec('ls -l', function(error, stdout, stderr) {
    console.log('stdout: ' + stdout);
    console.log('stderr: ' + stderr);
    if (error !== null) {
        console.log('exec error: ' + error);

The module that we used is called child_process. Its exec method accepts the desired command as a string and a callback. The stdout item is the output of the command. If we want to process the errors (if any), we may use the error object or the stderr buffer data. The preceding code produces the following screenshot:

Along with the exec method, we have spawn. It's a bit different and really interesting. Imagine that we have a command that not only does its job, but also outputs the result. For example, git push may take a few seconds and it may send messages to the console continuously. In such cases, spawn is a good variant because we get an access to a stream:

var spawn = require('child_process').spawn;
var command = spawn('git', ['push', 'origin', 'master']);
command.stdout.on('data', function (data) {
   console.log('stdout: ' + data);
command.stderr.on('data', function (data) {
   console.log('stderr: ' + data);
command.on('close', function (code) {
   console.log('child process exited with code ' + code);

Here, stdout and stderr are streams. They dispatch events and if we subscribe to these events, we will get the exact output of the command as it was produced. In the preceding example, we run git push origin master and sent the full command responses to the console.



Node.js is used by many companies nowadays. This proves that it is mature enough to work in a production environment. In this chapter, we saw what the fundamentals of this technology are. We covered some of the commonly used cases. In the next chapter, we will start with the basic architecture of our example application. It is not a trivial one. We are going to build our own social network.

About the Author

  • Krasimir Tsonev

    Krasimir Tsonev is a coder with over 10 years of experience in web development. The author of Node.js Blueprints, Packt Publishing, he works with a strong focus on quality and usability. Krasimir is interested in delivering cutting-edge applications. He enjoys working in the software industry and has a passion for creating and discovering new and effective digital experiences. Right now, he is working with technologies such as HTML5/CSS3, JavaScript, PHP, and Node.js, but he originally started out as a graphic designer. Later, being a Flash developer, he spent several years using ActionScript3 and frameworks such as RobotLegs. After that, as a freelancer, he continued to deliver full-stack web services for his clients, taking care of the graphic design and frontend and backend programming. Right now, with the rise of mobile application development, Krasimir is enthusiastic about working on responsive applications that target various devices. He currently lives and works in Bulgaria. He graduated from the Technical University of Varna with both a bachelor's and a master's degree in computer science. He loves blogging, writing books, and giving talks on the latest trends in web development.

    He has authored Node.js Blueprints, Packt Publishing (

    Browse publications by this author

Latest Reviews

(3 reviews total)
Very good example driven book. Good to read, i liked it very much.
It is a 200 pages long book. 100 pages are about client-side JavaScript. 40 pages are really about Node.js. 60 pages are about using MongoDB. It was boring. It would be more interesting if wanted to build a social app, but I bought this book to study Node.js.
Book Title
Unlock this book and the full library for FREE
Start free trial