Just face it: you are making or have already made (at least) some of these common Node.js development mistakes that I'm about to put into the spotlight! Especially if you're new to Node.js.
For even if this high performant web server/JavaScript runtime's advantages are non-debatable:
- it guarantees low latency
- … and high throughput
- it's conveniently lightweight
- it provides you with a heavy load of plugins for custom-building your apps with
- it enables you to develop apps with two-way, real-time connections where, “untraditionally”, both the client and the server can initiate communications
… Node.js is, nevertheless, susceptible and vulnerable to a number of developer mistakes.
Which, ironically, stem precisely from:
- improperly implementing it into one's projects
- the incorrect usage of this JavaScript runtime environment itself
And this is why I've run my own“investigations”, filtered the results by “popularity”, and put together this list of 10 most common Node.js development mistakes that developers often make.
That you, too, risk to make and thus to... “sabotage” yourself!
Mistakes which:
- have an impact on your app projects' performance
- make Node.js simply... unusable
And now, let's not meander any longer and dig right into... the list of Node.js pitfalls that should:
- keep you more alert when working on your next Node.js projects
- give you some sort of guidance on how to make the most of all that Node.js has to offer
1. Blocking the Event Loop: Too Common and Almost Impossible to Avoid
Here's the context:
Node.js, as we all know it, is a single-threaded environment. Which, in a more down-to-earth language, means that you can't have two parts of your application run in parallel.
Node.js can focus on one single thread at a time and thus it achieves concurrency by carrying out input-output operations... asynchronously. This can only mean that if, God forbid, something blocks the event loop, everything gets blocked!
And all it takes is a piece of CPU-bound request, connected to various clients, to block the event loop.
Then, all the other clients “waiting in line” get blocked, as well!
Now how can you avoid making this mistake when building your Node.js app?
- you could add open-source modules and tools like StrongOps into your... toolbox and keep them at hand for detecting any small delays in the event loop
- you address each case... individually
- you try to avoid CPU intensive work in the front-facing Node.js instances (those that clients connect to simultaneously)
2. Using the Nesting Callbacks Approach, That Leads to... “Callback Hell”
Nesting callbacks deep into your code, to the point where it gets difficult to read, error-prone and “untamed”, is a well known “practice” with Node.js developers.
Probably one of the most common Node.js development mistakes.
Are you, too, one of those who stubbornly consider callback nesting inevitable for handling asynchronous operations?
Then you'd better shake this misconception off!
For there are ways to avoid this approach in your development process, thus keeping your code nice and tidy:
- use the async module
- use co-generator based flow-control
- use Promises
3. Not Profiling and Monitoring Your Node.js App
“Don't go to the dark side!”
What I'm trying to say here is that not profiling (or monitoring) your Node.js app will just... keep you in the dark. You won't be able to identify the delays in the event loop or to closely monitor the CPU load and memory usage.
You'll be just... guessing.
Note: mind you don't confuse profiling with testing; profiling information helps you monitor specific aspects of your Node.js application — its function return time or its space — providing you with actionable insights on... what's going “under the hood”.
A supervisor program monitor is of crucial importance, whether your project still runs in your local development environment or in production mode.
Speaking of which, here are some examples of monitoring programs:
- StrongLoop
- AppDynamics
- New Relic
- Concurix
Overlooking to keep your app closely monitored, all the times, is one of those too common Node.js development mistakes that you risk to... underrate.
4. Using Console.log to Debug Your Code
Try to resist the “temptation” of just plugging in “console.log” whenever something goes wrong.
And don't think that I do not understand how tempting this is:
- in Node.js you get to print just about anything to the console by using “console.org”
- it will “gladly” accept and print any number of arguments (nicely space-separated)
Now, here's the “ugly truth” behind overly exploiting console.org for debugging your code:
- by putting your Node.js app “on hold”, each time you need to insert console.org, then restarting it again, you're actually slowing down the development process
- this “handy, yet unorthodox” approach to debugging will only leave you with unruly code
- … and where do you add that it will generate unnecessary code, as well
- debugging might just get unexpectedly challenging when striving to identify the values that you are debugging in a... “noisy” context: the “noise” of all the other potential logging operations
And finally: try a little empathy! The next developer(s) landing on the same Node.js project might just... repeat the whole process
This is what the Debug module's built for, after all! Just use the debug function and... leave it there.
Instead of “plugging in” and deleting console.org multiple times.
5. Node.js Development Mistakes: Taking Number for Integer Data Type
First of all, do keep this in mind: in JavaScript, numbers are floating point data!
And since it's not a usual thing to have numbers so big as to “overstretch” the limits of the float, you shouldn't worry about this too much.
Still, when the “unusual” does happen, the float's limits get “pushed” and you're dealing with an unusually large number, trouble happens.
To avoid this type of “exceptional” situations, with a negative impact on your system, remember that:
- operators handle integers and float differently
- there are big integer libraries out there that you can rely on: libraries which apply the needed mathematical operations on large precision numbers
In conclusion: miscalculating your float, and implicitly its limits, as well, still is one of those common Node.js development mistakes that programmers often make.
To be continued with Part 2: 5 more Node.js development pitfalls to be aware of when working on your future projects...