I have worked as a developer for the last four years and studied development for several years before that. During this time I worked mainly with Java and C#, but also with many other object-oriented languages such as PHP and Ruby. In this time, one language I hadn’t developed with was JavaScript.

 At the time of starting this blog, I was a complete beginner with JS and although I had heard a lot about node and it was heavily used by the nerd.vision team; I never had the desire to try it. After spending a few days with node I regret not picking it up years ago!

One thing, in particular, that put me off using node was the horror stories of debugging issues within your apps. So as I was testing I made sure to try all common methods of debugging node as well as nerd.vision to see if debugging in node was a frustrating experience and if nerd.vision made it any easier.

Why use Node.js?

Node.js is a big deal in today's tech space, with companies like Amazon, Netflix, Reddit and Twitter to name a few using the language within their infrastructure. It is over 10 years old and its adoption rate is increasing rapidly. 

According to StackOverflow JavaScript is used by over half of all software developers due to its versatility in both front and back end applications.

Node is known as a performant and cost-effective framework, companies moving to node almost always see a dramatic increase in performance in terms of startup time and response time for their applications. It is easy to adapt with all the powerful features you need available as a package through NPM. 

After spending a few days with node I can say that that is no longer the case. I am by no means an expert in node, but I have a good idea of how it works under the hood and how to get the essential tasks done. There is still a lot to learn and avenues yet to be explored such as TypeScript, CoffeeScript and a number of packages to familiarize myself with.

How should you debug Node.js?

Debugging in node has often been regarded as a painful experience. I know from the developers I work with, the looks of frustration when finding what is often an obvious error when you know where to look, but not so obvious when you first see the error and inspect the code.

There are a few ways to debug node, and while developing my application I used a mix of all of them to try and fix my now obvious errors.

I created a multitude of console.log statements to print out everything that could potentially cause the issue, this did work and I was able to find my issues, but every time I needed to add another log I had to restart my server.

I used the inbuilt Inspect functions in node and attempted to decipher the often deep and complex output to find my issues. I am sure that as I get more familiar with the language I will get to a point where this would be a simple process. As a beginner, I did not find this approach particularly intuitive. On Top of this, I again had to restart my server to get the data I needed. 

I then used a step debugger in Chrome and through my IDE, with this approach I was able to get all the data I could ever need, sometimes too much. This approach was by far the most useful for me to use out of the three common methods of debugging.

One issue I have with all three of these approaches is that they are not particularly helpful in a production environment. They all require modifications to the source code and have the potential to impact performance and even stop a potential customer from using your application.

When developing locally it was fine, but when I started looking into hosting these applications in Docker or AWS, particularly if I wanted to host an application in a customer-facing environment I would certainly run into problems.

What is the best way to debug Node.js?

If I am debugging in production, I want a debugger that is always available and will be safe to use whenever I need it. In order to do this, I would need a debugger that fulfils all the following requirements;

• No restarts or redeploys to get a debugger installed
• No performance impact while debugging
• Non-breaking so it does not stop people using the application

When using nerd.vision this is exactly what you get! 

Installing the debugger is a one time process, when it is installed you can leave it running on all your node processes, so whenever you need a debugger it’s there. Whether you are hitting breakpoints or the debugger is idle there will be negligible performance impact so there is no need to remove the debugger when you’re not using it.

If you need to debug an issue, it's as simple as logging into the nerd.vision web app, going to your workspace for the node app and setting a breakpoint where you need it. As soon as that code fires in your application, all stack frames and variables are available to you and it’s that quick the person using the application won’t even know a breakpoint fired.

Conclusion

I haven’t been using node for a long time but I can say without a doubt that my opinion on node and JavaScript has changed dramatically. I do wish I had gotten into node sooner and will certainly invest more time into seeing what else it can do.

In my experience using nerd.vision, step debugging, using the inspect function and console logs for the last few days, I have found that there is no single correct way to debug node. All 4 of these approaches work and will get you to the route of your issue.

There is however now only one tool to debug node, and that’s nerd.vision. Whether I have an issue on my local environment, staging or production I can always get the data I need and I don’t have to restart my app or rebuild my docker images to do it.