I'm back, as promised, with 5 more Node.js development mistakes from the “hall of fame” that I've set in place. 5 of the most common pitfalls that developers (and not exclusively those new to Node.js) fall into.
From:
- getting sloppy with your testing “routine”
- to taking the risk of ignoring the importance of using supervisor programs
- to invoking callbacks multiple times
- ...
... I've included the most “popular” Node.js errors (adding to the 5 ones from my last post) in this “hall of shame” here.
So that you can remain alert and careful and make the best out of your next Node.js project.
Ready, steady, go!
6. Executing a Callback More than Just Once
How does JavaScript manage to keep the whole “infrastructure” of asynchronous code elements “glued”? Perfectly connected, so they can function properly?
It relies on callbacks!
Note: callbacks used to be the “standard” back in the days; it was the only way that asynchronous elements could communicate with one another, this until promises became a more viable alternative...
Now one of the most common Node.js development mistakes that package developers fall for is that of invoking callbacks more than once.
They (you) design their APIs around callbacks, so executing them is a regular thing in the development process. Yet, many times they just save a file and reload their Node.js app just to make sure that it doesn't crash immediately. And it's precisely this “manoeuver” that results in multiple callback executions. Since, as expected, developers often “forget” to return after the first time.
The solution? Just add a return before the invoked callback; this way, you'll avoid the multiple invocations.
See? All it takes is a certain level of “vigilance”.
7. Superficially Testing Your Node.js App
Don't get overconfident in your work and therefore... “sloppy” when it comes to your testing routine.
Proper testing still is one of the most underrated steps of any Node.js app's development process. Yet, this is no excuse for you to try to be “in trends”, so to say.
In other words: your Node.js application is not even close to being ready if you haven't written and run the proper tests for it!
Give your code a deep scan, multiple times, to make sure everything works properly! If/when in doubt:
- you can always turn the most popular Node.js projects on Github into your main sources of inspiration
- enrich your toolbox with powerful testing tools such as Jasmine or Mocha
8. Node.js Development Mistakes: Throwing Errors Inside Callbacks
Here's the situation:
JavaScript, like most of the widely-used languages (C++, Java etc.), does support the notion of “exceptions”. And, in this respect, it even leverages the same syntax for handling exceptions and it can “throw” and catch them in try-catch blocks.
Yet (for there is, indeed, a “yet), this try-catch syntax doesn't work as expected in Node.js, where the asynchronous behavior comes into the picture:
The scope containing the given try-catch block might have already gone out of context; therefore, it proves itself “usefless” when it comes to catching the errors thrown from inside the callback.
The solution: follow the (err,...) pattern on all your callback function arguments. And reserve the first argument of all callbacks for an error object.
9. Not Using Supervisor Programs
You must be already familiar with the fail fast "commandment" of modern app development, am I right?
In case of an error, don't rush to get it fixed! Instead, let your supervisor program handle it and then restart the app for you!
Now since you're well aware of this good practice, overlooking the importance of supervisor programs and relying exclusively on analytics tools becomes even more... blamable.
And here's why it's one of the major Node.js development mistakes you could “fall victim to”:
- relying exclusively on analytics tools for tracking down bugs and issues in your Node.js app means that your investigations will cover its development stage only
- supervisor programs enable you to handle multiple apps on the same machine and even to streamline log management
- if “trouble strikes”, you can “lay back” and just let your app... crash; then let your supervisor program handle the error for you; it will restart your app/program in seconds
- … and it will even restart your app after each change applies to one of your files
Overall, this can only improve the developer experience during the app building/updating process.
10. Assigning to The “Exports” Variable Instead of the “Module.Exports”
Here's another one of those highly... “popular” Node.js development mistakes. And the cause of endless frustrations for Node.js developers:
Overlooking to make a clear distinction between “module.exports” and “exports”.
Here's how you, yourself, could end up falling into this common pitfall:
Node.js treats files as small, isolated modules, right? Well then if, let's say, your Node.js package has 2 files, for one of them to access the other one's functionality, it just needs to export it (its functionality) by adding new properties to the exports object.
// a.js
exports.verifyPassword = function(user, password, done) { ... }And if, let's say, you need to export this very function directly instead of the same object's property, you just overwrite exports and “enable” it to do it.
Note: when doing so, keep in mind not to treat “exports” as a global variable, but the module object's property instead.
In short: assigning a given value to the “exports” variable instead of directly to the “module.exports” property will have no impact on the “module.exports”. And, implicitly it won't export... anything.
The END! These are the most common Node.js development mistakes that you, too, risk falling “victim” to (if you haven't already).
Now that you're well aware of, you'll have “no excuse” for not using Node.js to its full potential in your next project! Happy coding!