5 Node.js Tips for Newcomers

With the explosion of Node, there are many developers diving into it for the first time. As everyone knows who has developed with Node for some time, there are a few concepts and gotchas that can cause some headaches. Hopefully these will help with some of those problems.

Tip #1: Debugging

Developers from other languages like Java and C#, are more used to heavy IDE integrations for debugging. JavaScript developers starting out adopt the “flow” debugging pattern where  console.log becomes their friend.

I’ve talk about this in a previous post, but Node comes with a great debugger built in. In order to debug a script file, just add  debug to the command:

Node Watch ValueThe debugger allows you to do all the normal debugger-type things. Set breakpoints, add watchers, stepping in and out of functions. It’s every Node developers prerogative to get to know it.

Node Inspector has also become a popular option for debugging. It create an endpoint that will allow you to use the Chrome Dev Tools for debugging which is probably the closest you’ll get to the IDE integrated debugging experience.

Tip #2: Avoid Synchronous Code

Node, by design, is single threaded. To allow this thread to accept large numbers of requests, the code needs to make sure it’s not waiting, or blocking on a long-running, synchronous operation. Since Node was, from the bottom-up, to be asynchronous, it makes an excellent fit for evented type applications.

Even though Node wants you to be asynchronous, there’s still ways to make blocking calls. Some default modules have methods that come with both synchronous and asynchronous versions. Such as writeFile and writeFileSync of the fs module.

Even if you are careful to avoid it in your own code, be mindful of any packages you install as they might be making blocking calls. Performance will be greatly impacted depending on what is used. Just be mindful.

Tip #3: Learn Promises

As you learn Node more and more, you’ll most certainly run into the pyramid of doom, or callback hell as it’s more commonly known as. If you’re not familiar with the concept, here’s an example:

As you can see, the code slowly creeps to the right. This is a by-product of being asynchronous, how can this be avoided? Promises

Q and Bluebird are two of the more popular, but there’s also async and native ES2015 promises. Using promises, the code above would look something more like this:

No callback hell and easier to follow.

Tip #4: Add Return Statements

One of the most common mistake new developers make in Node is forgetting to add return statements when they call their callbacks. Sometimes this can have no adverse effects, but if you ever see a situation where callbacks are being called multiple times, most likely a return should’ve been added.

Let’s look at an example:

If there’s never an error in that function, there’s no issues. The problem rises if there’s an error. The first call doesn’t stop execution. Meaning the second call will also happen. In order to fix this, just put  return in front of each callback call.

When apps get more complex, adding returns after callbacks can save hours of debugging.

Tip #5: Don’t Check-in node_modules

Not many new Node developers know that you shouldn’t check in the node_modules folder. If someone else is going to be working on the code, let them install the packages themselves.

You might say that it isn’t that big of a deal, but if they’re running a different operating system than you, certain modules may not work. Especially modules like bcrypt or mongoose, that require a compile step on the source machine to operate properly. This is because there’s components that are written in C.