June 18, 2019
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.
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.
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.
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.
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;
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.
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.
Technical Support Engineer and Developer advocate for nerd.vision and other software projects. Background in object-oriented software development and data analysis. Personal hobbies include simulation gaming and watch collecting.