Fr

Node.js Essentials

Node.js Essentials
Node.js Essentials takes you through the fundamentals
of Node.JS and demonstrates how Node.js can transform
the way you work with JavaScript and allow you to take
greater control over your code.
You will also learn how to create a HTTP server from
scratch, route requests, create a RESTful interface, and
authenticate users. You'll nd out how to test and optimize
your code when working with Node.js, using the Mocha
framework. Follow each step and discover how to test
both synchronous and asynchronous code using Mocha
unit tests.
With Node.js Essentials you'll nd everything you
need to create a complete full-stack application with
Node.js. It will help you harness JavaScript much more
effectively and in doing so expand your condence
and capabilities as a developer.

Who this book is written for

P U B L I S H I N G

pl

Create and use a HTTP server using

Express.js
Explore middleware including authentication
with Passport
Use MongoDB and LevelDB with Node.js
Debug and unit test applications

C o m m u n i t y

E x p e r i e n c e

D i s t i l l e d

Use Socket.IO to create real time interactions

Publish your modules to NPM to share
with others

Node.js Essentials

Congure and maintain applications

$ 24.99 US
15.99 UK

community experience distilled

Sa
m

What you will learn from this book

Fabian Cook

If you want to expand your capabilities as a developer,

this book is for you. This book covers everything you need
to use Node.js effectively, you will soon be able to handle
JavaScript in a much more fully-realized way.

ee

From client to server, learn how Node.js can help you use
JavaScript more effectively to develop faster and more scalable
applications with ease

Prices do not include

local sales tax or VAT
where applicable

Visit www.PacktPub.com for books, eBooks,

code, downloads, and PacktLib.

Fabian Cook

In this package, you will find:

The author biography

A preview chapter from the book, Chapter 1 'Getting Started'
A synopsis of the books content
More information on Node.js Essentials

About the Author

Fabian Cook is an experienced JavaScript developer who lives in Hawkes Bay,

New Zealand. He began working with Java and C# very early in his life, which lead
to using Node.js in an open source context. He is now currently working for a New
Zealand ISP, known as NOW NZ where they are utilizing the full power of Node.js,
Docker and CoreOS.

Preface

Preface
Node.js is simply a tool that lets you use JavaScript on the server side. However, it
actually does much more than that by extending JavaScript, it allows for a much
more integrated and efficient approach to development. It comes as no surprise that
it's a fundamental tool for full-stack JavaScript developers. Whether you work on the
backend or frontend, you adopt a much more collaborative and agile way of working
using Node.js, so that you and your team can focus on delivering a quality end
product. This will ensure that you're ready to take on any new challenge that gets
thrown at you.
This book will be fast paced and cover dependency management, running your own
HTTP server, real time communication, and everything in between that is needed to
get up and running with Node.js.

What this book covers

Chapter 1, Getting Started, covers the setup of Node.js. You will also cover how to
utilize and manage dependencies.
Chapter 2, Simple HTTP, covers how to run a simple HTTP server and helps you
understand routing and utilization of middleware.
Chapter 3, Authentication, covers the utilization of middleware and JSON Web Token
to authenticate users.
Chapter 4, Debugging, covers the integration of post-mortem techniques in your
development tasks and how to debug your Node.js programs.
Chapter 5, Configuration, covers the configuration and maintenance of your software
using centralized configuration options, arguments, and environmental variables.

Preface

Chapter 6, LevelDB and NoSQL, covers the introduction of NoSQL databases, such as
LevelDB and MongoDB. It also covers the use of the simple key/value store and a
more complete document database.
Chapter 7, Socket.IO, explores the real-time communication between clients, servers,
and back again and also how it authenticates and notifies the users.
Chapter 8, Creating and Deploying Packages, focuses on sharing the modules and
contributing to the eco-system
Chapter 9, Unit Testing, tests your code using Mocha, Sinon, and Chance and
also covers how to use mocks with functions and generate random values to
test your code
Chapter 10, Using More Than JavaScript, explains the usage of CoffeeScript with Node.
js to expand language capabilities.

Getting Started
Every Web developer must have come across it every once in a while, even if they
just dabble in simple Web pages. Whenever you want to make your Web page a
little more interactive, you grab your trustworthy friends, such as JavaScript and
jQuery, and hack together something new. You might have developed some exciting
frontend applications using AngularJS or Backbone and want to learn more about
what else you can do with JavaScript.
While testing your website on multiple browsers you must have come across Google
Chrome at some point and you might have noticed that it is a great platform for
JavaScript applications.
Google Chrome and Node.js have something very big in common: they both work on
Google's high-performance V8 JavaScript engine, this gives us the same engine in the
browser that we will be using in the backend, pretty cool, right?

Setting up
In order to get started and use Node.js, we need to download and install Node.js.
The best way to install it will be to head over to https://nodejs.org/ and
download the installer.
At the time of writing, the current version of Node.js is 4.2.1.
To ensure consistency, we are going to use a npm package to install the correct
version of Node.JS and, for this, we are going to use the n package described at
https://www.npmjs.com/package/n.
Currently, this package has support only for *nix machines. For Windows. see
nvm-windows or download the binary for 4.2.1 from https://nodejs.org/dist/
v4.2.1/.

[1]

Getting Started

Once you have Node.js installed, open a terminal and run:

[~]$ npm install -g n

The g argument will install the package globally so we can use the package anywhere.
Linux users may need to run commands that install global packages as sudo.
Using the recently install package, run:
[~]$ n

This will display a screen with the following packages:

node/0.10.38
node/0.11.16
node/0.12.0
node/0.12.7
node/4.2.1

If node/4.2.1 isn't marked we can simply run the following packages; this will
ensure that node/4.2.1 gets installed:
[~]$ sudo n 4.2.1

To ensure that the node is good-to-go, lets create and run a simple hello world
example:
[~/src/examples/example-1]$ touch example.js
[~/src/examples/example-1]$ echo "console.log(\"Hello world\")" >
example.js
[~/src/examples/example-1]$ node example.js
Hello World

Cool, it works; now let's get down to business.

Hello require
In the preceding example, we just logged a simple message, nothing interesting,
so let's dive a bit deeper in this section.

[2]

Chapter 1

When using multiple scripts in the browser, we usually just include another script
tag such as:
<script type='application/javascript' src='script_a.js'>
</script>
<script type='application/javascript' src='script_b.js'>
</script>

Both these scripts share the same global scope, this usually leads to some unusual
conflicts when people want to give variables the same name.
//script_a.js
function run( ) {
console.log( "I'm running from script_a.js!" );
}
$( run );
//script_b.js
function run( ) {
console.log( "I'm running from script_b.js!" );
}
$( run );

This can lead to confusion, and when many files are minified and crammed together
it causes a problem; script_a declares a global variable, which is then declared
again in script_b and, on running the code, we see the following on the console:
> I'm running from script_b.js!
> I'm running from script_b.js!

The most common method to get around this and to limit the pollution of the global
scope is to wrap our files with an anonymous function, as shown:
//script_a.js
(function( $, undefined ) {
function run( ) {
console.log( "I'm running from script_a.js!" );
}
$( run );
})( jQuery );
//script_b.js

[3]

Getting Started
(function( $, undefined ) {
function run( ) {
console.log( "I'm running from script_b.js!" );
}
$( run );
})( jQuery );

Now when we run this, it works as expected:

> I'm running from script_a.js!
> I'm running from script_b.js!

This is good for code that isnt depended upon externally, but what do we do for the
code that is? We just export it, right?
Something similar to the following code will do:
(function( undefined ) {
function Logger(){
}
Logger.prototype.log = function( message /*...*/ ){
console.log.apply( console, arguments );
}
this.Logger = Logger;
})( )

Now, when we run this script, we can access Logger from the global scope:
var logger = new Logger( );
logger.log( "This", "is", "pretty", "cool" )
> This is pretty cool

So now we can share our libraries and everything is good; But what if someone else
already has a library that exposes the same Logger class.
What does node do to solve this issue? Hello require!
Node.js has a simple way to bring in scripts and modules from external sources,
comparable to require in PHP.
Lets create a few files in this structure:
/example-2
/util
index.js
logger.js

[4]

Chapter 1
main.js
/* util/index.js */
var logger = new Logger( )
var util = {
logger: logger
};
/* util/logger.js */
function Logger(){
}
Logger.prototype.log = function( message /*...*/ ){
console.log.apply( console, arguments );
};
/* main.js */
util.logger.log( "This is pretty cool" );

We can see that main.js. is dependent on util/index.js, which is in turn

dependent on util/logger.js.
This should just work right? Maybe not. Let's run the command:
[~/src/examples/example-2]$ node main.js
ReferenceError: logger is not defined
at Object.<anonymous> (/Users/fabian/examples/example-2/main.js:1:63)
/* Removed for simplicity */
at Node.js:814:3

So why is this? Shouldn't they be sharing the same global scope? Well, in Node.
js the story is a bit different. Remember those anonymous functions that we were
wrapping our files in earlier? Node.js wraps our scripts in them automatically and
this is where require fits in.
Lets fix our files, as shown:
/* util/index.js */
Logger = require( "./logger" )
/* main.js */
util = require( "./util" );

[5]

Getting Started

If you notice, I didn't use index.js when requiring util/index.js; the reason for
this is that when you a require a folder rather than a file you can specify an index
file that can represent that folder's code. This can be handy for something such as a
model folder where you expose all your models in one require rather than having a
separate require for each model.
So now, we have required our files. But what do we get back?
[~/src/examples/example-2]$ node
> var util = require( "./util" );
> console.log( util );
{}

Still, there is no logger. We have missed an important step; we haven't told Node.js
what we want to expose in our files.
To expose something in Node.js, we use an object called module.exports. There
is a shorthand reference to it that is just exports. When our file is wrapped in an
anonymous function, both module and exports are passed as a parameter, as shown
in the following example:
function Module( ) {
this.exports = { };
}
function require( file ) {
// .....
returns module.exports;
}
var module = new Module( );
var exports = module.exports;
(function( exports, require, module ) {
exports = "Value a"
module.exports = "Value b"
})( exports, require, module );
console.log( module.exports );
// Value b

Downloading the example code

You can download the example code files for all Packt books you have
purchased from your account at http://www.packtpub.com. If you
purchased this book elsewhere, you can visit http://www.packtpub.
com/support and register to have the files e-mailed directly to you.

[6]

Chapter 1

The example shows that exports is initially just a reference to module.exports.

This means that, if you use exports = { }, the value you set it as won't be
accessible outside the function's scope. However, when you add properties to an
exports object, you are actually adding properties to the module.exports object as
they are both the same value. Assigning a value to module.exports will export that
value because it is accessible outside the function's scope through the module.
With this knowledge, we can finally run our script in the following manner:
/* util/index.js */
Logger = require( "./logger.js" );
exports.logger = new Logger( );
/* util/logger.js */
function Logger( ){
}
Logger.prototype.log = ( message /*...*/ ) {
console.log.apply( console, arguments );
};
module.exports = Logger;
/* main.js */
util = require( "./utils" );
util.logger.log( "This is pretty cool" );

Running main.js:
[~/src/examples/example-2]$ node main.js
This is pretty cool

Require can also be used to include modules in our code. When requiring
modules, we don't need to use a file path, we just need the name of the node
module that we want.
Node.js includes many prebuilt core modules, one of which is the util module.
You can find details on the util module at https://nodejs.org/api/util.html.
Let's see the util module command:
[~]$ node
> var util = require( "util" )
> util.log( 'This is pretty cool as well' )
01 Jan 00:00:00 - This is pretty cool as well

[7]

Getting Started

Hello npm
Along with internal modules there is also an entire ecosystem of packages; the most
common package manager for Node.js is npm. At the time of writing, there are a total
of 192,875 packages available.
We can use npm to access packages that do many things for us, from routing HTTP
requests to building our projects. You can also browse the packages available at
https://www.npmjs.com/.
Using a package manager you can bring in other modules, which is great as you can
spend more time working on your business logic rather than reinventing the wheel.
Let's download the following package to make our log messages colorful:
[~/src/examples/example-3]$ npm install chalk

Now, to use it, create a file and require it:

[~/src/examples/example-3]$ touch index.js
/* index.js */
var chalk = require( "chalk" );
console.log( "I am just normal text" )
console.log( chalk.blue( "I am blue text!" ) )

On running this code, you will see the first message in a default color and the second
message in blue. Let's look at the command:.
[~/src/examples/example-3]$ node index.js
I am just normal text
I am blue text!

Having the ability to download existing packages comes in handy when you require
something that someone else has already implemented. As we said earlier, there are
many packages out there to choose from.
We need to keep track of these dependencies and there is a simple solution to that:
package.json.
Using package.json we can define things, such as the name of our project, what the
main script is, how to run tests, our dependencies, and so on. You can find a full list
of properties at https://docs.npmjs.com/files/package.json.

[8]

Chapter 1

npm provides a handy command to create these files and it will ask you the relevant
questions needed to create your package.json file:
[~/src/examples/example-3]$ npm init

The preceding utility will walk you through the creation of a package.json file.
It only covers the most common items and tries to guess valid defaults.
Run the npm help json command for definitive documentation on these fields and
to know what they do exactly.
Afterwards, use npm and install <pkg> --save to install a package and save it as a
dependency in the package.json file.
Press ^C to quit at any time:
name: (example-3)
version: (1.0.0)
description:
entry point: (main.js)
test command:
git repository:
keywords:
license: (ISC)

About to write to /examples/example-3/package.json:

{
"name": "example-3",
"version": "1.0.0",
"description": "",
"main": "main.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "....",
"license": "ISC"
}
Is this ok? (yes)

The utility will provide you with default values, so it is easier to just skip through
them using the Enter key.

[9]

Getting Started

Now when installing our package we can use the --save option to save chalk as a
dependency, as shown:
[~/src/examples/example-3]$ npm install --save chalk

We can see chalk has been added:

[~/examples/example-3]$ cat package.json
{
"name": "example-3",
"version": "1.0.0",
"description": "",
"main": "main.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "...",
"license": "ISC",
"dependencies": {
"chalk": "^1.0.0"
}
}

We can add these dependencies manually by modifying package.json; this is the

most common method to save dependencies on installation.
You can read more about the package file at: https://docs.npmjs.com/files/
package.json.
If you are creating a server or an application rather than a module, you most likely
want to find a way to start your process without having to give a path to your main
file all the time; this is where the script object in your package.json file comes
into play.
To set your start up script, you just need to set the start property in the scripts
object, as shown:
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"start": "node server.js"
}

Now, all we need to do is run npm start and then npm will run the start script we have
already specified.

[ 10 ]

Chapter 1

We can define more scripts, for example if we want a start script for the development
environment we can also define a development property; with non-standard script
names however, instead of just using npm <script>, we need to use npm run
<script>. For example, if we want to run our new development script we will have
to use npm run development.
npm has scripts that are triggered at different times. We can define a postinstall
script that runs after we run npm install; we can use this if we want to trigger a

package manager to install the modules (for example, bower)

You can read more about the scripts object here: https://docs.npmjs.com/misc/

scripts.

You need to define a package if you are working in a team of developers where the
project is to be installed on different machines. If you are using a source control tool
such as git, it is recommended that you add the node_modules directory into your
ignore file, as shown:
[~/examples/example-3]$ echo "node_modules" > .gitignore
[~/examples/example-3]$ cat .gitignore
node_modules

Summary
That was quick, wasn't it? We have covered the fundamentals of Node.js, which we
need to continue on our journey.
We have covered how easy it is to expose and protect public and private code
compared to regular JavaScript code in the browser, where the global scope can
get very polluted.
We also know how to include packages and code from external sources and how to
ensure that the packages included are consistent.
As you can see there is a huge ecosystem of packages in one of the many package
managers, such as npm, just waiting for us to use and consume.
In the next chapter, we will focus on creating a simple server to route, authenticate,
and consume requests.

[ 11 ]

Get more information Node.js Essentials

Where to buy this book

You can buy Node.js Essentials from the Packt Publishing website.
Alternatively, you can buy the book from Amazon, BN.com, Computer Manuals and most internet
book retailers.
Click here for ordering and shipping details.

www.PacktPub.com

Stay Connected: