Three (3) NodeJS Lessons I Have Learned In 2021

Hello dear reader, happy second half of the year 🎉! It has been quite a year for many of us, and within the past months, we have experienced situations which we eventually learnt from and gained some wisdom.

From the tonnes of things I learnt in the earlier six (6) months of the year 2021, I would love to share some of them with the entire Dev community, that is, you inclusive. So, let's go ✈️!

1. Pass In Required Variables Directly In An Object

When it comes to chaining object properties to get a required value, many times we can never be too sure that even the very first variable, which is supposed to be an object is even defined.

Take for example v1.r1.r2.

1. v1 could be anything including null and undefined
2. r1 might not be a defined variable of the object v1

Notice that if either 1 or 2 is true, the chained variable would throw an exception for Property of undefined.

Now, say we pass this chained variables into an object as a key-value as thus, given either of the two (2) above listed conditions

{
  p1: v1.r1.r2
}

The error will be thrown from within the scope of the object, leaving the error message and error stack behind.

Hopefully we have a logging system across the modules (.js files) in our app, all the that the log will contain sounds something like

WARNING: 😕 Hey, there was an error somewhere around, go check it, and maybe fix it!

Except you have only three (3) statements that make up your project, then you most likely do not even have an idea of what you is happening, lest even what to do.

To fix this, the right approach is to define the required variable outside the scope of the object. For example

const val = v1.r1.r2

const obj = {
  p1: val
}

This will help with logging and debugging, because the exception will be thrown and caught with the error message and stack.

NOTE: Chaining variables (property or method) on a variable that is undefined will throw an exception. Usually, NodeJS will log the error trace to the console (default) and/or wherever else specified. Therefore, these logs should contain information that is intuitive enough for easily approachable debugging.

Another way to avoid this exception is to check the defined state of each chained property, that is, property after property. For example

const obj = {
  p1: v1 && v1.r1 && v1.r1.r2
}

2. Never Pass Undefined Value To Knex where Function

Passing an undefined value to a column in a Knex where function will throw an exception. This is quite similar to lesson 1, in that, if we apply some of the principles we learnt there, we could somewhat avert the feasibility of encountering this issue.

You might expect that such query should take the default value specified in the schema; right? Which in many cases will be null. Unfortunately for that assumption, it is not so, and it is outrightly stated in the documentation.

Where Clauses

...
Important: Supplying knex with an undefined value to any of the where functions will cause knex to throw an error during sql compilation...

Ouch! Sorry, you did not see that coming. But well, exceptions are errors you do not expect, nor do you specifically write code for, although we should always prepare our projects (codebases) for them.

3. Log Errors/Exceptions With Directives Included

Not all error logs contain enough information for instant debugging, intuitive debugging, refactors or fixes. For this to occur, the error log should include enough information, which anyone can use to streamline the issue.

For this reason, it will be more effective to construct the error log in such a way that anyone including you and anyone with authorized access to the logs, can determine what the exact issue is, and the next cause of action, in the case that any issue arises.

Properties such as source and action in addition to a log will be very helpful in this regard. For example:

{
  "message": "Specified column does not exist", // Optional
  "source": "database",
  "action": "Update User Password",
  "error": "\"the entire error stack\""  // Could represent both error message and stack
}

Conclusion

For the meantime, these are few of the things I learnt while working on NodeJS projects this year, which I have been eager to share. Kindly share your thoughts on the three (3) lessons noted above.

I would gladly appreciate that you share your own discoveries likewise in the comment section, as I look to feature them in future iterations of this article.

Thanks for having me! 👍