The Top 10 Most Common Mistakes That Node.js Developers Make

Since the moment Node.js was unveiled to the world, it has seen a fair share of both praise and criticism. The debate still continues, and may not end anytime soon. What we often overlook in these debates is that every programming language and platform is criticized based on certain issues, which are created by how we use the platform. Regardless of how difficult Node.js makes writing safe code, and how easy it makes writing highly concurrent code, the platform has been around for quite a while and has been used to build a huge number of robust and sophisticated web services. These web services scale well, and have proven their stability through their endurance of time on the Internet.

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.

Mistake #1: Blocking the event loop

JavaScript in Node.js (just like in the browser) provides a single threaded environment. This means that no two parts of your application run in parallel; instead, concurrency is achieved through the handling of I/O bound operations asynchronously. For example, a request from Node.js to the database engine to fetch some document is what allows Node.js to focus on some other part of the application:

// Trying to fetch an user object from the database. Node.js is free to run other parts of the code from the moment this function is invoked..
db.User.get(userId, function(err, user) {
 // .. until the moment the user object has been retrieved here
})

However, a piece of CPU-bound code in a Node.js instance with thousands of clients connected is all it takes to block the event loop, making all the clients wait. CPU-bound codes include attempting to sort a large array, running an extremely long loop, and so on. For example:

function sortUsersByAge(users) {
 users.sort(function(a, b) {
  return a.age < b.age ? -1 : 1
 })
}

Invoking this “sortUsersByAge” function may be fine if run on a small “users” array, but with a large array, it will have a horrible impact on the overall performance. If this is something that absolutely must be done, and you are certain that there will be nothing else waiting on the event loop (for example, if this was part of a command-line tool that you are building with Node.js, and it wouldn’t matter if the entire thing ran synchronously), then this may not be an issue. However, in a Node.js server instance trying to serve thousands of users at a time, such a pattern can prove fatal.

If this array of users was being retrieved from the database, the ideal solution would be to fetch it already sorted directly from the database. If the event loop was being blocked by a loop written to compute the sum of a long history of financial transaction data, it could be deferred to some external worker/queue setup to avoid hogging the event loop.

As you can see, there is no silver-bullet solution to this kind of Node.js problem, rather each case needs to be addressed individually. The fundamental idea is to not do CPU intensive work within the front facing Node.js instances - the ones clients connect to concurrently.

Mistake #2: 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.

Mistake #3: Deeply Nesting Callbacks

Deeply-nesting callbacks, often referred to as “callback hell”, is not a Node.js issue in itself. However, this can cause problems making code quickly spin out of control:

function handleLogin(..., done) {
 db.User.get(..., function(..., user) {
  if(!user) {
   return done(null, ‘failed to log in’)
  }
  utils.verifyPassword(..., function(..., okay) {
   if(okay) {
    return done(null, ‘failed to log in’)
   }
   session.login(..., function() {
    done(null, ‘logged in’)
   })
  })
 })
}

The more complex the task, the worse this can get. By nesting callbacks in such a way, we easily end up with error-prone, hard to read, and hard to maintain code. One workaround is to declare these tasks as small functions, and then link them up. Although, one of the (arguably) cleanest solutions to this is to use a utility Node.js package that deals with asynchronous JavaScript patterns, such as Async.js:

function handleLogin(done) {
 async.waterfall([
  function(done) {
   db.User.get(..., done)
  },
  function(user, done) {
   if(!user) {
   return done(null, ‘failed to log in’)
   }
   utils.verifyPassword(..., function(..., okay) {
    done(null, user, okay)
   })
  },
  function(user, okay, done) {
   if(okay) {
    return done(null, ‘failed to log in’)
   }
   session.login(..., function() {
    done(null, ‘logged in’)
   })
  }
 ], function() {
  // ...
 })
}

Similar to “async.waterfall”, there are a number of other functions that Async.js provides to deal with different asynchronous patterns. For brevity, we used simpler examples here, but reality is often worse.

Mistake #4: 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.

Mistake #5: 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.

Mistake #6: 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.

Mistake #7: 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.

Mistake #8: 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.

Mistake #9: 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

Mistake #10: 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.

Conclusion

As you can tell, some of these Node.js problems can have devastating effects on your program. Some may be the cause of frustration while you’re trying to implement the simplest of things in Node.js. Although Node.js has made it extremely easy for newcomers to get started, it still has areas where it is just as easy to mess up. Developers from other programming languages may be able to relate to some of these issues, but these mistakes are quite common among new Node.js developers. Fortunately, they are easy to avoid. I hope this short guide will help beginners to write better code in Node.js, and to develop stable and efficient software for us all.

This article was written by MAHMUD RIDWAN, a Toptal freelance developer

How Much Coding Should Designers Know?

Many designers think each discipline should mind their own business, while others see no problem in professionals wearing multiple hats. Many developers see designers who code as a threat, while others see it as a facilitator. This is a hotly debated subject, and although I think some great designers are also superb at coding, I will always defend that the more you focus on a particular area the best you will be at it. But this shouldn’t be a reason for you to miss out on the benefits of having another skill under your belt.

Learn how to code and make yourself a great asset to any multi-disciplinary team.

As a designer who has gone as far to set up Linux servers and program back-end, I see no question that understanding ‘the basics’ of coding would benefit any designer. The question really is, how much coding should designers learn? At what point might designers be wasting their time, or really stepping over the line into the territory of developers?

In order to provide some insight into the potential benefits of learning to code, I’ve broken the different levels of coding knowledge down into degrees of usefulness.

Step 1: Know the basics of HTML and CSS

Any designer would greatly benefit from knowing the foundations of HTML and CSS and would be surprised by how easy it can be. Stop being lazy and just learn this, it will make you a better designer, guaranteed.

When is front-end just coding, not programming?

Is front-end coding? Yes! Is it programming? Only after a certain point.

HTML and CSS don’t involve programming logics. You can see that in HTML - HyperText Markup Language the letter M stands for Markup, what means that it’s nothing more than a coded structure of the page/screen elements. It works like a puzzle, but it doesn’t require a lot of mathematical thinking.

In laymen’s terms, HTML is an architectural map that tells the browser what to display. The HTML map will influence how search engine crawlers will interpret the site. So, the concern here is to make sure the code is very well structured and that those systems can understand it and rank it well.

CSS, or Cascading Style Sheets, is the code that tells the browser how to display things. Metaphorically, if HTML is the skeleton of a page or screen, CSS would be the skin and eyes colors, hairstyle, body shape, limbs sizes, etc. The language has a very simple code structure that determines typography, colors, positions and dimensions. The concern with HTML is to keep it very organized for maintenance and optimized for good performance.

Understanding code means understanding your pixels

Learning how to code gives you the opportunity to know how things work. Why do we need to worry about pixel-perfection, is it only for the sake of symmetry?

If you play with HTML and CSS, you’ll notice that everything is measured in pixels (there are other measurement units - not relevant here - but they will ultimately be converted to pixels). Understanding these mechanics will change your mindset and will care for design in a more efficient way for the development process. As a consequence, not only your projects will be easier to program as your projects may look much more structured.

Step 2: Front-end JavaScript and AJAX could make you a unique asset

This is where things can start to get complicated, but it’s also where a lot of fun happens. If you’re an analytical thinker, or specially motivated, you’ll get a lot out of learning JavaScript and AJAX. As well, your design perspective will improve in knowing exactly how far technology can take you and how far you can push it to be innovative. I don’t think going this deep is necessary though, because if you know the basics of HTML and CSS you’ll already be ahead of most competitors. However, you may find some fun in making things coming to life with the knowledge.

When does front-end become programming?

Although we could stop here and have the back-end implemented, we can make our project more dynamic by adding some scripting, like if we could give a few acrobatic abilities to the beautifully structured and painted body we created with HTML / CSS.

For that, we have our dear JavaScript, which is an actual logical programming language. JavaScript can be used to display dynamic interactions, animate elements, create a very responsive communication with the back-end or server, as well as other things. As there aren’t many limits to what can be accomplished with Javascript in front-end development, now we are talking about a programming language: functions, objects, logics, conditionals, math, math and more math so that it may be a little challenging. But it’s not that hard to learn, especially considering what most clients will require.

In my opinion if you want to say you’re a front-end developer, knowing (at least the basics of) JavaScript is mandatory. You should understand how AJAX works (which is used by nearly any modern website). You should test your interactions in real time, and if you’re a motion designer, like me, you can do some animations yourself rather than having to explain it to a programmer, which may not have the same eye for the kind of detail that you see as a designer.

As well, there are the pre-processors for HTML (Haml, Jade, etc.) and CSS (SCSS, LESS, etc.), which are languages that aim to facilitate and streamline the coding process using programming concepts (such as logics, modulation, among others). The code, as it states, is then pre-processed, generating the pure HTML and CSS (also called vanilla). Even if you know only the basics of programming, these could be real time-savers.

Knowing how to program informs the limitations of devices

If you, a designer, learn front-end you will clearly see various advantages for knowing it, such as knowing how things work and see the limitations of each device.

Even browsers behave differently - let alone separate devices - so knowing this when you are creating gives you a sense of making something solid, lowering the chances of future complications in projects. Every programmer I know got a layout that was impossible to reproduce at some point in their lives.

Knowing the mechanics behind a digital project will not only give you an idea of what limits your work, but also what boundaries of technology you can push. I remember when several agencies, such as Fantasy andFirstborn, made a reputation in the early 2000’s for using Javascript in a different and very creative way.

• 
• 
• 

Step 3: Back-end JavaScript might be overkill

Well, maybe we’re going too far here. Knowing the basics of back-end JavaScript can be useful depending on the stack your team uses (like MEAN stack, for example). But, you don’t have to go too far if all you need to know is how to run a project. However, if you dream of leading product teams, this may be helpful. But, if you call yourself a designer, not developer, your returns are seriously diminishing at this point, so you’d be better off expanding your creative skills.

Learn to code and collaborate better with developers

Would romantic relationships be easier if men could read the minds of women? Many would think so. I wonder the same thing about designers and developers.

Knowing how developers think and what they need to be able to do their job may sound like stepping on their territory, but it will make you a great asset to any multi-disciplinary team.

This can be very useful both for internal communications, as well as in idea pitches, because you know what to expect from the other members of the team. If you can do this, know your limitations (and how to push them), then you will be able to propose much more robust solutions to clients.

A designer who can code will see more job opportunities

One of the reasons why I closed my small company (RIP!), was the fact that I started international relationships that became increasingly more attractive than local businesses. For these contacts, today I work exclusively for this the global market, so 99% of my network is foreign. The opportunity that opened up this market for me was a scenario that required an individual who could do it all, including front-end. And I fit the bill; I could even program back-end. By then I ended up getting involved more and more with the dark side of the force, even to the point of setting up and managing Linux servers.

In every opportunity I had since then, knowing how to program made a big difference both in the screening processes and the day to day work. At Toptal we see a bunch of opportunities for professionals with this hybrid profile, and startups out there are eager to find people that can take over both the design and front-end of their early-stage applications.

Learning how to code might lead to some unexpected opportunities.

Still, there are some designers and programmers who dislike one another snooping into each other’s businesses. Why might this be? Some may be afraid of losing work, and some may be lazy to learn something new. But the truth is that you should analyze your options, and focus on what will increase your chances of success. You may not have enough time now to learn everything, but maybe knowing vanilla HTML and CSS should be sufficient to add a significant differential to your career. It should be quick and easy for you to take the first steps. The more you know, the more you expand your opportunities. So, by experience, I would never discourage any opportunity to learn new skills.

Step 4: Database Architecture and Software Engineering Won’t Get Designers Anywhere

Unless algebra and complex computing are your thing, I would say “Dear God, no!”. There are other useful side skills you could learn instead (like knitting). People are just as likely to want to hire a designer who knows how to knit as one who knows how to architect databases. Besides, you don’t want to be in a place where you need to take care of everything, believe me.

So, should designers program?

I would say no. You don’t need to. But more and more the work opportunities in the design field add web-development, or at least front-end notions, as a requirement or a differential. So you don’t need to, but maybe you should if you want to have something else to offer, especially if you’re having trouble finding work. Sometimes we can’t find an opportunity that fits our profile, and that’s when we need to adapt to what is out there.

Conclusion

All of this said, we all know that it is not mandatory for a designer to know how to program. I know a lot of designers that don’t, excellent ones in fact.

However, in some cases, I notice deficiencies from a development point-of-view, in details that could even harm a project’s productivity.

You don’t need to be a designer who is also an expert in front-end development to have these differential skills added to your CV or applied to your projects, and you have a lot of online resources to start walking down this road. Simple skills can impact your potential for success in a very positive way.

Do some research, look at what job offers are requesting, see the profile of designers startups are looking for, and maybe you can agree with me when I say you don’t need to learn how to code, but you should.

Think about it!

Source: Toptal