Something anyone trying out NodeJS should know up front

TL;DR – scroll down till you see the heading you’re looking for.

I really love JavaScript as a language, and there were lots of things about NodeJS that appealed to me. So when I had the opportunity to use NodeJS on a significant project about a year ago I went for it. The app pulled data from several web services, mashed them together, and posted results and commands to other services: There was a lot of async. NodeJS should be really good at this.

After two months of serious coding I found my code was littered all over with error checking code — not error handling code as in, “I can compensate for this error,” but simple error checking code: This callback gives me an `err` as first parameter. Hmm, I guess I better not ignore it. If it’s not empty I better that’s set to something, and pass it to my own callback. So I end up with this All. Over. The. Place:

function getCoolResult(x, y, callback) {
   lookupSomeXData(x, function(err, xData) {
      if(err) {
        callback(err);
        return;
      }
      combineYWithXData(y, xData, function(err, coolResult) {
        if(err) {
          callback(err);
          return;
        }
        callback(null, coolResult);
   });
}

To be clear, my beef with NodeJS was that, in order to do it right, I needed those error-checking warts (two in the example above). I found myself thinking, “This is like writing C in the 90’s,” where one is required to check return codes after every function call.

I don’t like it. I want my core business code to be really focused on business concerns, not infrastructure concerns. I want to only worry about errors that I can actually do something intelligent and contextual with.

I ran this project for two months, then decided to rewrite all the server side code in C#. I’m a consultant/contractor and the rewrite was on my own dime, so I didn’t make the decision lightly. I’m really glad I did for this project, because:

  1. Deleting all the error checking code felt great. Like StrongBad-cleaning-his-inbox great. Go ahead, watch that little video and imagine yourself cleansing your code of all these little error-checking warts.
  2. I dropped several flakey and dubious third-party NPM packages and used built-in .NET libraries or more mature Nuget packages instead, resulting in less lines of code and a more stable app.
  3. There were big chunks of code I wrote myself for node that I replaced with a third-party Nuget package. At the time I could find no NPM counter-part for some of these things.

The C# code shrunk drastically, was cleaner and more stable. Probably slower executing, but not enough to be an issue for this project.

TL;DR starts here:

So I think NodeJS is pretty cool, and it may be the right tool for certain kinds of jobs, and if you’re interested in exploring it, you should! But there’s something important that Christopher Langton distilled down for me today (in comments) that I wish I’d known a year ago:

You ultimately will need to conform to the handling of known errors or pass them on, as this has become the only implementation that all modules apply.

My translation: every callback will have a little error checking fragment up front. Yeah, it’s kinda annoying, but just do it and move on. You can live with that.

(Promises can help, but they’re not ubiquitous in NodeJS.)

This entry was posted in JavaScript, Programming. Bookmark the permalink.