Top Mistakes That Node.js Developers Make and Should be Avoided

In this article, we will take a look at some common mistakes that developers new to Node.js often make, and how they can be avoided to become a Node.js pro.

For the past few years, Node.js, accounting for its growth and popularity, has been a talking point for some time now. Well-establish companies like **Walmart and PayPal **have adapted it, making it one of the most recognized languages at present. However, as many other platforms, Node.js faces a lot of development problems that includes crucial mistakes committed by the developers themselves.

However, like any other platform, Node.js is vulnerable to developer problems and issues. Some of these mistakes degrade performance, while others make Node.js appear straight out unusable for whatever you are trying to achieve. In this article, we will take a look at ten common mistakes that developers new to Node.js often make, and how they can be avoided to become a Node.js pro.

1. Blocking the event loop

Being a single-threaded environment, no two parts of your application can run in parallel. Simply put, since Node.js runs on a single thread, anything which blocks the event loop, blocks everything. Here, concurrency is achieved by handling input-output operations asynchronously. For example, what allows Node.js to focus on some other part of the application is a request to the database engine, from Node.js to fetch some document. However, all it takes to block the event loop is a piece of CPU-bound code in a Node.js instance with many clients connected, making all the clients wait. There is no clear-cut solution to this problem, other than to address each case individually. The primary idea is to not do CPU intensive work within the front facing Node.js instances, the ones clients connect to concurrently.

2. Nested Callback or Callback Hell

If you properly analyze the common issues with Node.js, you would know that most of the problems are associated with callbacks and the callback hell or nested callback, whatever you may term it is one of the general mistakes.

In fact, this particular problem persists in most of the application development programs. The concern usually originates because the development of the application is a complex process. It also becomes difficult to maintain the codes.But you can sort out this issue by writing simple functions that are easy to read and providing them suitable links. For instance, codes such as Generators, Promises etc. will be helpful and you can keep the codes error free.The developers who expect that the call back will operate serially shouldn’t get under this misconception as everything is not carried out synchronously. Therefore, it is suggested that the addition must be done instantly after the call back to ensure everything goes smoothly.

3. Expecting Callbacks to Run Synchronously

Asynchronous programming with callbacks may not be something unique to JavaScript and Node.js, but they are responsible for its popularity. With other programming languages, we are accustomed to the predictable order of execution where two statements will execute one after another, unless there is a specific instruction to jump between statements. Even then, these are often limited to conditional statements, loop statements, and function invocations.

However, in JavaScript, with callbacks a particular function may not run well until the task it is waiting on is finished. The execution of the current function will run until the end without any stop:

function testTimeout() {
	console.log(“Begin”)
	setTimeout(function() {
		console.log(“Done!”)
	}, duration * 1000)
	console.log(“Waiting..”)
}

As you will notice, calling the “testTimeout” function will first print “Begin”, then print “Waiting…” followed by the the message “Done!” after about a second.

Anything that needs to happen after a callback has fired needs to be invoked from within it.

4. Lack of Profiling and Zero Monitoring

Often confused for testing, profiling is a completely different process. Profiling information helps with program optimization by studying various aspects related to the program like its space or function return time.In Node.js applications, profiling will help you understand things like delay in the event loop, system load, and CPU load or memory usage.

5. Developer is Unknown to Developing Tools

Often it is seen that in case the developers are inexperienced and fresher into the application development field, he remains unknown to the developing tools. It has already been indicated earlier that Node.js helps in complicated application building and if the developer is not familiar with the basic modules he may face problems.

The developer should know that if any change is done at the source, he has to restart and also he needs to refresh the browser when the static codes are getting modified and affecting the performance of the application. For restarting the server, you can use modules such as nodemon and for refreshing the nodemon and livereload is regarded appropriate.

6. Invoking a Callback More Than Once

JavaScript has relied on callbacks since forever. In web browsers, events are handled by passing references to (often anonymous) functions that act like callbacks. In Node.js, callbacks used to be the only way asynchronous elements of your code communicated with each other - up until promises were introduced. Callbacks are still in use, and package developers still design their APIs around callbacks. One common Node.js issue related to using callbacks is calling them more than once. Typically, a function provided by a package to do something asynchronously is designed to expect a function as its last argument, which is called when the asynchronous task has been completed:

module.exports.verifyPassword = function(user, password, done) {
	if(typeof password !== ‘string’) {
		done(new Error(‘password should be a string’))
		return
	}

	computeHash(password, user.passwordHashOpts, function(err, hash) {
		if(err) {
			done(err)
			return
		}

		done(null, hash === user.passwordHash)
	})
}

Notice how there is a return statement every time “done” is called, up until the very last time. This is because calling the callback doesn’t automatically end the execution of the current function. If the first “return” was commented out, passing a non-string password to this function will still result in “computeHash” being called. Depending on how “computeHash” deals with such a scenario, “done” may be called multiple times. Anyone using this function from elsewhere may be caught completely off guard when the callback they pass is invoked multiple times.

Being careful is all it takes to avoid this Node.js error. Some Node.js developers adopt a habit of adding a return keyword before every callback invocation:

if(err) {
	return done(err)
}

In many asynchronous functions, the return value has almost no significance, so this approach often makes it easy to avoid such a problem.

7. Assigning to “exports”, Instead of “module.exports”

Node.js treats each file as a small isolated module. If your package has two files, perhaps “a.js” and “b.js”, then for “b.js” to access “a.js”’s functionality, “a.js” must export it by adding properties to the exports object:

// a.js
exports.verifyPassword = function(user, password, done) { ... }

When this is done, anyone requiring “a.js” will be given an object with the property function “verifyPassword”:

// b.js
require(‘a.js’) // { verifyPassword: function(user, password, done) { ... } } 

However, what if we want to export this function directly, and not as the property of some object? We can overwrite exports to do this, but we must not treat it as a global variable then:

// a.js
module.exports = function(user, password, done) { ... }

Notice how we are treating “exports” as a property of the module object. The distinction here between “module.exports” and “exports” is very important, and is often a cause of frustration among new Node.js developers.

8. Throwing Errors from Inside Callbacks

JavaScript has the notion of exceptions. Mimicking the syntax of almost all traditional languages with exception handling support, such as Java and C++, JavaScript can “throw” and catch exceptions in try-catch blocks:

function slugifyUsername(username) {
	if(typeof username === ‘string’) {
		throw new TypeError(‘expected a string username, got '+(typeof username))
	}
	// ...
}

try {
	var usernameSlug = slugifyUsername(username)
} catch(e) {
	console.log(‘Oh no!’)
}

However, try-catch will not behave as you might expect it to in asynchronous situations. For example, if you wanted to protect a large chunk of code with lots of asynchronous activity with one big try-catch block, it wouldn’t necessarily work:

try {
	db.User.get(userId, function(err, user) {
		if(err) {
			throw err
		}
		// ...
		usernameSlug = slugifyUsername(user.username)
		// ...
	})
} catch(e) {
	console.log(‘Oh no!’)
}

If the callback to “db.User.get” fired asynchronously, the scope containing the try-catch block would have long gone out of context for it to still be able to catch those errors thrown from inside the callback.

This is how errors are handled in a different way in Node.js, and that makes it essential to follow the (err, …) pattern on all callback function arguments - the first argument of all callbacks is expected to be an error if one happens.

9. Assuming Number to Be an Integer Datatype

Numbers in JavaScript are floating points - there is no integer data type. You wouldn’t expect this to be a problem, as numbers large enough to stress the limits of float are not encountered often. That is exactly when mistakes related to this happen. Since floating point numbers can only hold integer representations up to a certain value, exceeding that value in any calculation will immediately start messing it up. As strange as it may seem, the following evaluates to true in Node.js:

Math.pow(2, 53)+1 === Math.pow(2, 53)

Unfortunately, the quirks with numbers in JavaScript doesn’t end here. Even though Numbers are floating points, operators that work on integer data types work here as well:

5 % 2 === 1 // true
5 >> 1 === 2 // true

However, unlike arithmetic operators, bitwise operators and shift operators work only on the trailing 32 bits of such large “integer” numbers. For example, trying to shift “Math.pow(2, 53)” by 1 will always evaluate to 0. Trying to do a bitwise-or of 1 with that same large number will evaluate to 1.

Math.pow(2, 53) / 2 === Math.pow(2, 52) // true
Math.pow(2, 53) >> 1 === 0 // true
Math.pow(2, 53) | 1 === 1 // true

You may rarely need to deal with large numbers, but if you do, there are plenty of big integer libraries that implement the important mathematical operations on large precision numbers, such as node-bigint.

10. Ignoring the Advantages of Streaming APIs

Let’s say we want to build a small proxy-like web server that serves responses to requests by fetching the content from another web server. As an example, we shall build a small web server that serves Gravatar images:

var http = require('http')
var crypto = require('crypto')

http.createServer()
.on('request', function(req, res) {
	var email = req.url.substr(req.url.lastIndexOf('/')+1)
	if(!email) {
		res.writeHead(404)
		return res.end()
	}

	var buf = new Buffer(1024*1024)
	http.get('http://www.gravatar.com/avatar/'+crypto.createHash('md5').update(email).digest('hex'), function(resp) {
		var size = 0
		resp.on('data', function(chunk) {
			chunk.copy(buf, size)
			size += chunk.length
		})
		.on('end', function() {
			res.write(buf.slice(0, size))
			res.end()
		})
	})
})
.listen(8080)

In this particular example of a Node.js problem, we are fetching the image from Gravatar, reading it into a Buffer, and then responding to the request. This isn’t such a bad thing to do, given that Gravatar images are not too large. However, imagine if the size of the contents we are proxying were thousands of megabytes in size. A much better approach would have been this:

http.createServer()
.on('request', function(req, res) {
	var email = req.url.substr(req.url.lastIndexOf('/')+1)
	if(!email) {
		res.writeHead(404)
		return res.end()
	}

	http.get('http://www.gravatar.com/avatar/'+crypto.createHash('md5').update(email).digest('hex'), function(resp) {
		resp.pipe(res)
	})
})
.listen(8080)

Here, we fetch the image and simply pipe the response to the client. At no point do we need to read the entire content into a buffer before serving it.

11. Using Console.log for Debugging Purposes

In Node.js, “console.log” allows you to print almost anything to the console. Pass an object to it and it will print it as a JavaScript object literal. It accepts any arbitrary number of arguments and prints them all neatly space-separated. There are a number of reasons why a developer may feel tempted to use this to debug his code; however, it is strongly recommended that you avoid “console.log” in real code. You should avoid writing “console.log” all over the code to debug it and then commenting them out when they are no longer needed. Instead, use one of the amazing libraries that are built just for this, such as debug.

Packages like these provide convenient ways of enabling and disabling certain debug lines when you start the application. For example, with debug it is possible to prevent any debug lines from being printed to the terminal by not setting the DEBUG environment variable. Using it is simple:

// app.js
var debug = require(‘debug’)(‘app’)
debug(’Hello, %s!’, ‘world’)

To enable debug lines, simply run this code with the environment variable DEBUG set to “app” or “*”:

DEBUG=app node app.js

12. Not Using Supervisor Programs

Regardless of whether your Node.js code is running in production or in your local development environment, a supervisor program monitor that can orchestrate your program is an extremely useful thing to have. One practice often recommended by developers designing and implementing modern applications recommends that your code should fail fast. If an unexpected error occurs, do not try to handle it, rather let your program crash and have a supervisor restart it in a few seconds. The benefits of supervisor programs are not just limited to restarting crashed programs. These tools allow you to restart the program on crash, as well as restart them when some files change. This makes developing Node.js programs a much more pleasant experience.

There is a plethora of supervisor programs available for Node.js. For example:

• pm2
• forever
• nodemon
• supervisor

All these tools come with their pros and cons. Some of them are good for handling multiple applications on the same machine, while others are better at log management. However, if you want to get started with such a program, all of these are fair choices.

#node-js #javascript #web-development