Now what we often tend to overlook in the debate around the advantages and disadvantages of different programming languages is that most of the criticism revolving around certain issues stems from the incorrect use of the language. Often the criticism is centered around safe code writing practices and how complicated Node.js can get. Even so, the platform has been around for a while and has been used to build a huge number of sophisticated and robust web services. However, like any other platform, Node.js is susceptible to developer issues and problems. Today, we will take a look at some of the common mistakes developers new to Node.js often make.
Common Mistakes That Node.js Developers Make
1. Blocking the event loop
Being a single-threaded environment, no two parts of your application can run in parallel. Simply put, since Node.js runs on a single thread, anything which blocks the event loop, blocks everything. Here, concurrency is achieved by handling input-output operations asynchronously. For example, what allows Node.js to focus on some other part of the application is a request to the database engine, from Node.js to fetch some document. However, all it takes to block the event loop is a piece of CPU-bound code in a Node.js instance with many clients connected, making all the clients wait. There is no clear-cut solution to this problem, other than to address each case individually. The primary idea is to not do CPU intensive work within the front facing Node.js instances, the ones clients connect to concurrently.
2. Invoking callbacks, multiple times
3. Call backs don’t run synchronously, don’t expect them to
4. Asynchronous error handling
5. Deeply nesting callbacks
Or “callback hell” as it is often referred to is not just a Node.js issue. The more complex the task is, the worse the issue can get. By nesting callbacks in such a way, we end up with hard to read, error-prone, and hard to maintain code. Hence, most use “callback hell” as a key point in disfavor of Node.js, but most of these people see callback nesting as unavoidable. But you see, this is not the case. There are enough solutions out there to keep your code nice and tidy, such as using control flow modules like async, promises and generators.
6. Using console.log for debugging purposes
8. Not testing religiously
Your application isn’t done if you haven’t written any tests for it. It’s in the rule book, and there’s no excuse for skipping this one, considering the many tools which exist to make the process easier. In case you are not sure how to get started with writing tests you can either browse popular Node projects on Github or find tutorials online.
9. Zero monitoring or profiling
Not monitoring or profiling a Node applications leaves you in the dark. A supervisor program monitor which can orchestrate your program is a highly useful thing to have whether your Node.js code is in production mode or running in your local development environment. There are proprietary services which take care of this stuff for you, such as the ones from New Relic, StrongLoop or Concurix, AppDynamics. Whatever you choose make sure you are always aware of the status of your application at all times.