Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Common Node.js Development Mistakes (Part 1)

DZone's Guide to

Common Node.js Development Mistakes (Part 1)

Node.js can be tricky. Read on to learn about five common mistakes that occur when using Node.js and how you can avoid them.

· Web Dev Zone ·
Free Resource

Deploy code to production now. Release to users when ready. Learn how to separate code deployment from user-facing feature releases with LaunchDarkly.

Image title

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 building your apps.
  • 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.

These mistakes, ironically, stem precisely from:

  1. Improperly implementing Node.js into one's projects.
  2. 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 making 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 a 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 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: Make sure you don't confuse profiling with testing; profiling information helps you monitor specific aspects of your Node.js application — its function returns time or its space — providing you with actionable insights in terms of what's going on “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 the need to keep your app closely monitored, all the time, is one of those common Node.js development mistakes that many underestimate.

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.log.
  • It will accept and print any number of arguments (nicely space-separated).

Now, here's the “ugly truth” behind over exploiting console.log for debugging your code:

  • By putting your Node.js app “on hold.” Each time you insert console.log, then restart your server/app, you're actually slowing down the development process.
  • This “handy, yet unorthodox” approach to debugging will only leave you with unruly code.
  • It will generate unnecessary code.
  • 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.log 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. This is when trouble happens.

To avoid these types 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.

Deploy code to production now. Release to users when ready. Learn how to separate code deployment from user-facing feature releases with LaunchDarkly.

Topics:
node.js ,web dev ,web application development ,backend development

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}