7 tips for a Node.js padawan

Node.js development is extremely fun and satisfying. There are over 35k modules to choose from, and overall node is very easy to develop a working application that can scale easily.

However for developers just starting off with Node.js development, there are a few bumps along the road. In this short post I cover a few of the things I questioned and ran into while learning Node.js.

Tip 1: Use nodemon for development. pm2 for production.

When you first get started with Node.js development, one of the things that will stick out like a sore thumb is having to run node [file].js over and over again. When I got started with node, this was extremely frustrating and painful. Especially having to control C every time I modified something.

Nodemon is an awesome tool, once you install it globally you can run your node.js scripts via:

nodemon [file].js

nodemon [file].js

Doing so will tell nodemon to monitor your script and all the scripts that it depends on for changes. This is an awesome way to do Node.js development and speeds everything up.

What about production? Unless you are using Heroku, Nodejitsu or other great Node.js hosting providers, chances are you will be using EC2 or another cloud provider to run your Node.js app. How do you properly run a Node.js app to make sure it’s always running?

The answer to that question is a great tool called PM2 https://github.com/Unitech/pm2. PM2 is a tool like nodemon which is intended to run your node app in production. Like Nodemon it will monitor your app for changes and redeploy them, but unlike Nodemon, if PM2 encounters a crash, it will restart your node.js app right away.

Where PM2 excels though is when you need to scale your app to multiple cores. PM2 comes with a built in “load balancer” that lets you easily specify how many instances of your Node app to run.

pm2 start app.js -i max

pm2 start app.js -i max

The -i parameters lets you specify how many instances to run, in this case PM2 comes with a built in constant called max which auto scales your app to the amoutn of cores you have. Remember Node runs only on one core!

Tip 2: Async or Q

The more you start to write node.js apps, the sooner you’ll realize the pain of callback hell. If you don’t know what callback hell is, here is an example:

If we take what we did previously with register, we can apply the waterfall pattern in async. The result of this is a very readable code pattern that doesn’t involve the pyramid of doom.

Another great library is Q https://github.com/kriskowal/q. This library is exposes the concept of promises. A promise is basically an object that is returned from a method with the “promise” that it will eventually provide a return value. This ties is very neatly with the asynchronous nature of javascript and node.js.

The promise me function returns an object right away. Calling then on the object will call the function you pass in with the value you want returned. Then also takes an additional callback which is run when the object fails to return the value.

This is a very neat way to avoid the insanity of callback hell. If we take our registration example, you can easily make it so that each of those functions is called when then is executed.

Q.fcall(checkIfNameExists)
.then(checkIfPasswordIsGood)
.then(createAccount)
.then(createBlog)
.then(function(result){// Do something with the result})
.catch(function(error){// Handle any error from all above steps}).done();

As I said previously, I dislike creating single purpose functions. Instead of passing in the function name to “then”, I would just create an anonymous inner function and pass that in, however the choice is yours.

In summary, if you start to realize you’re creating callback hell for yourself then it’s time to look into async.js or Q.

Tip 3: Debugging Node.js apps easily

Debugging Node.js apps will be confusing if you are coming from a language with heavy IDE integration like Java or C#. Most new node developers adopt the “flow” debugging pattern, where your best friend becomes console.log.

However there are still alternatives that are more convention to debugging. Node.js comes with a built in debugger that you can run by calling node debug, however the one I love is node-inspector.

Taken from their github repo “Node Inspector is a debugger interface for node.js using the Blink Developer Tools (former WebKit Web Inspector).”

In a nutshell node-inspector lets you debug your applications using whatever editor of your choice and chrome web tools. That is sexy.

Node-inspector lets you do some really cool things like live code changing, step debugging, scope injection and a bunch of other cool stuff.

It’s bit involved to setup, so I’ll let you follow the instructions over at

Tip 4: Nodefly

Once you have your application up and running, you might ask yourself how you could monitor it’s performance and profile it to make sure your app is running at optimum speed. The simplest answer to that is a great service I use called Nodefly.

Nodefly with a simple line of code starts to monitor your application for memory leaks, measure how long it takes for redis, mongo queries and a bunch of other cool stuff.

Tip 5: Module management with NPM.

One of the most common things to do in node is installing packages via NPM. Node has an amazing package manager which installs all the modules specified in your package.json manifest file. However one thing all beginers run into is keeping this package.json file updated with all the modules you are using.

It seems like a pain to always be opening your package.json to update the dependcies property with the new module you just installed, but what many don’t know is npm will do this for you!

Tip 6: Don’t check in your node_modules folder

While we are on the topic of modules and npm, not many know that you shouldn’t check in your node_modules folder. The biggest reason behind this is there is no need for you to check this folder in. Whenever someone checks your source out they can just run npm install and download all the modules required.

You might say that it’s not a big deal if you check in node_modules, but what if the person checking out your source is using an operating system other than yours and one of the modules that your app uses is compiled when it’s installed via npm? Your app will crash and the person that checked out your source will have no idea why!

For example modules like bcrypt and sentimental are compiled on the host system when you install them because they have native components written in C.

The best way to avoid checking in your node_modules folder is by adding it to .gitignore.

// .gitignore node_modules/*

Tip 7: Don’t forget to return

A common mistake made by all early node developers is forgetting to return after a callback. While some times this has no implications, there are many times where you’ll run into odd issues because your callback is being called twice.

At first glance, this snippet makes sense. If there is an error, send “error” in the callback, if not send good. But calling the callaback is not stopping the method from completing the execution. It will just move on to calling callback(“good”).

Inside long and complex lines of code, doing this will save you hours and hours of debugging.

Node.js is great platform to develop on. If you keep these 7 things in mind while developing, debugging and deploying to production you can save your time and prevent your hair from graying out.

Example: Flags and bitmasks

The bitwise logical operators are often used to create, manipulate, and read sequences of flags, which are like binary variables. Variables could be used instead of these sequences, but binary flags take much less memory (by a factor of 32).

Suppose there are 4 flags:

flag A: we have an ant problem

flag B: we own a bat

flag C: we own a cat

flag D: we own a duck

These flags are represented by a sequence of bits: DCBA. When a flag is set, it has a value of 1. When a flag is cleared, it has a value of 0. Suppose a variable flags has the binary value 0101:

1

varflags = 0x5; // binary 0101

This value indicates:

flag A is true (we have an ant problem);

flag B is false (we don’t own a bat);

flag C is true (we own a cat);

flag D is false (we don’t own a duck);

Since bitwise operators are 32-bit, 0101 is actually 00000000000000000000000000000101, but the preceding zeroes can be neglected since they contain no meaningful information.

A bitmask is a sequence of bits that can manipulate and/or read flags. Typically, a “primitive” bitmask for each flag is defined:

1

2

3

4

varFLAG_A = 0x1; // 0001

varFLAG_B = 0x2; // 0010

varFLAG_C = 0x4; // 0100

varFLAG_D = 0x8; // 1000

New bitmasks can be created by using the bitwise logical operators on these primitive bitmasks. For example, the bitmask 1011 can be created by ORing FLAG_A, FLAG_B, and FLAG_D:

1

varmask = FLAG_A | FLAG_B | FLAG_D; // 0001 | 0010 | 1000 => 1011

Individual flag values can be extracted by ANDing them with a bitmask, where each bit with the value of one will “extract” the corresponding flag. The bitmask masks out the non-relevant flags by ANDing with zeros (hence the term “bitmask”). For example, the bitmask 0100 can be used to see if flag C is set:

1

2

3

4

// if we own a cat

if(flags & FLAG_C) { // 0101 & 0100 => 0100 => true

// do stuff

}

A bitmask with multiple set flags acts like an “either/or”. For example, the following two are equivalent:

Flags can be set by ORing them with a bitmask, where each bit with the value one will set the corresponding flag, if that flag isn’t already set. For example, the bitmask 1100 can be used to set flags C and D:

1

2

3

// yes, we own a cat and a duck

varmask = FLAG_C | FLAG_D; // 0100 | 1000 => 1100

flags |= mask; // 0101 | 1100 => 1101

Flags can be cleared by ANDing them with a bitmask, where each bit with the value zero will clear the corresponding flag, if it isn’t already cleared. This bitmask can be created by NOTing primitive bitmasks. For example, the bitmask 1010 can be used to clear flags A and C:

1

2

3

// no, we don't neither have an ant problem nor own a cat

varmask = ~(FLAG_A | FLAG_C); // ~0101 => 1010

flags &= mask; // 1101 & 1010 => 1000

The mask could also have been created with ~FLAG_A & ~FLAG_C (De Morgan’s law):

1

2

3

// no, we don't have an ant problem, and we don't own a cat

varmask = ~FLAG_A & ~FLAG_C;

flags &= mask; // 1101 & 1010 => 1000

Flags can be toggled by XORing them with a bitmask, where each bit with the value one will toggle the corresponding flag. For example, the bitmask 0110 can be used to toggle flags B and C:

1

2

3

4

// if we didn't have a bat, we have one now, and if we did have one, bye-bye bat

For didactic purpose only (since there is the Number.toString(2) method), we show how it is possible to modify the arrayFromMask algorithm in order to create astring containing the binary representation of a number, rather than an array of booleans: