Lessons Learned Building a Pure Node Project

This is an article I’ll be adding to as I (inevitably) come across more issues working with node.js - this is a list of problems encountered and the solutions that worked for me.

I’ve been building out an API for the last few weeks whenever I get a chance - it started as a CLI to check website responses (think isitdown) but I’m now going to build out a vanilla JS front end for it. The API is in pure node - no external dependencies, no package.json file, nothing but the local modules bundled with the node.js installation package.

This was originally a project meant to teach me more about node.js itself and general basic backend work. Little did I know how much I’d gain from working on this - working with pure node.js is pretty fun. The biggest downside I’ve experienced so far is callback hell - I wanted to work without promises or async/await and thus have had no choice but to deal with callbacks. Even in a file with as few as 150 LOC, it’s difficult at first glance to understand where each callback fits in with the program flow.

Besides my index.js file which creates an instance of an HTTP and HTTPS server, I have a few other typical files - a config.js file, a data.js file which contains my local file storage methods using the fs module, and most importantly, a handler.js file which is just a layer over the data.js functions and routes requests to the appropriate data.js function (with a little extra code in there).

The First Problem

One thing I spent far too much time on was an undefined object value in JavaScript - this could be due to a million different things, so combing through the source code was necessary. Was I performing an asynchronous operation somewhere (either setting or getting the object property/value pair) and accessing it before the operation completed? No. This was the most likely culprit to me, but it didn’t seem to be happening anywhere.

Essentially I was trying to access a configuration property value - it was my HMAC secret key. The config file had it right there in front of my face so I knew I wasn’t trying to access something that just didn’t exist. Additionally, and THIS was the confusing part - I could get the value of any other config object property. The only one that came back undefined every time was my secret key.

I was stumped. At some point I realized I was probably referencing the config file incorrectly (this was a shot in the dark). I found my answer - I had changed the directory structure of my project and had put the config.js file in a new spot. I had forgotten to change my require() statement at the top of my file referencing the config object to point to the new file location.

How was it possible that I was still able to reference PART of my original config object even though I wasn’t pointing my require statement to the correct location? Cache, cache, cache. I’ve been using VSCode and, according to what I’ve read, it makes heavy use of caching. It had cached the old file and was keeping it around in the editor - whatever changes I made to that file (adding in the HMAC key) were SHOWING that they were being made to the code, but they were saving to the NEW location that wasn’t actually being referenced.

Once I changed the require() statement, everything worked perfectly.