Why every backend developer should learn NodeJS

I have a confession to make - I started off as a Java developer when I joined my first workplace, Google. It wasn't until 2009 that I first started playing around with JavaScript, and 2011 when I first played around with NodeJS.

I loved Node the very first time I worked with it, for various reasons, including but not limited to:

• It's Javascript, which makes it succinct and crisp
• Single-threaded by nature, which makes it easy to reason about code
• Asynchronous by default

It is the last one that I consider critical, which changed how I think about code in general. The thing is, when you code in Java, or Python, you end up with sub-optimal code by default, unless you spend time thinking about it.

Let us say we had (slightly contrived) teams database, where we can get the list of teams, and then for each team, fetch additional information for each team from the database. If you are writing this in Java, it is very easy (and I would argue more likely) to end up with code like the following:

teams = teamsDb.getTeams();
for (var i = 0; i < teams.size(); i++) {
    team = teams.get(i);
    team.setExtraInfo(
    	teamsDb.getTeamExtraInfo(team.getId());
}
return teams;

It does exactly what you want, which is to fetch a list of teams, and then for each team, fetch additional information about the team. But unless you are a very experienced programmer, or someone who thinks about performance all the time, you have missed a very key point - You are fetching the extra information sequentially!. It's not something that is obvious, but each call to the database to getTeamExtraInfo is actually a blocking call, so the loop

• Will make a call to the DB to fetch extra information for a team
• Block and wait for the DB to return
• Set it, and move onto the next item in the list

It is so common, and so standard, that you just don't think about it a second time.

Now, why do I say you should learn Node? Because, in Node, the default behaviour is non-blocking and asynchronous. In fact, it is very very hard to write blocking code in Node. So what would the above example look like in Node?

teamsDb.getTeams(function(teams) {
  for (var i = 0; i < teams.size(); i++) {
      team = teams.get(i);
      teamsDb.getTeamExtraInfo(team.getId(),
                function(teamExtra) {
            team.setTeamExtraInfo(teamExtra);
        });
      }
});

Each non-blocking call, each call that involves network I/O or any other I/O would end up taking a callback function that will get executed when the heavy work is completed. All functions are callback oriented (Promises and dealing with callback hell is a topic for another post!), which means that every time you call a function, you are forced to think:

• Is this call going to return immediately, or going to take a while?
• If this call is going to take a while, do I need to wait for it to finish before proceeding, or can I continue doing other work till it finishes?

I would argue that this forces you to think in a parallel friendly approach by default, because the minute you write this code, you realize that each call to get extra info is a DB call, and you might want to do it in parallel, rather than doing it sequentially. In fact, doing it sequentially is going to be harder than doing it in parallel!.

This is just a small example of how Node forces you to think in terms of callbacks and asynchronous behavior. Once you get used to this pattern, you can take this thinking process back to Java, Python or whatever, and be a better programmer! Or you could be like me, and just start loving Node and not want to go back!