TGIMBA NodeJS – Part 5

Git Hub Code

NOTE: The API Git repository got scrambled and I had to start over.  The link above is correct.

I had planned to report back once I had all of the SQL queries in place. However, it dawned on me that I hadn’t passed any parameters yet using Node JS. So after researching this, it seems that to do post parameters in Node JS, you need a library. I looked through a number of articles and the one that worked first for me using Postman (the greatest test tool ever!) was using a library called ‘body-parser’. To install (as with all Node Js libraries), you use NPM. The command is – npm install body-parser –save.

Another thing about Node JS that I am having some trouble adapting to is the complete lack of synchronous calls. Everything is asynchronous. While in theory this is a good thing, it can make returning a result that depends on a couple of other calls a little difficult. In my C#/NET world, you can ‘await’ an asynchronous method. I have not found an easy way around this yet with Node JS.

I dealt with this in the last blog post by passing the response object to the call back method. It works and I suppose I could do this with everything, but I have created a common JavaScript file for the SQL Server/tedious calls. It seems silly (not to mention a bad practice) to copy the same code into each call. So, using the previous method of passing the response object is probably not the best. So, I have done some research and it seems like ‘Promises’ are one of the recommended way to handle multiple asynchronous calls before returning a combined result. I will work promises into the The Globe In My Bucket Application (TGIMBA) Node JS Application Program Interface (API) at some point, but I am trying an intermediate step which has worked so far.

This ‘work around’ is to expand on just passing the response object to the call back method.  More specifically, it is to create a common return method (i.e. function returnResults(res, result, resultType)) which passes the result back to the javascript file containing the relevant code (i.e. getUserCount.js, processUser.js, etc). Essentially, passing object forward until it is returned.

The only issue I see with this (so far) is that my list of arguments to the common SQL method will be very long. I suspect I will write overloads to handle this until I decide to add the Promise and/or some other asynchronous/synchronous solution.

Today’s blog entry is dealing with one of the existing methods called processUser. In this method in the .NET API version, I take two arguments – encodedUser and encodedPass. These are both Base64 encoded.  I convert them to regular strings, calculate the salt/hash version of the supplied password, compare it to the existing one and then return a token if they match.  I was planning on replacing all of the encryption I do in the .NET API, but this may be more difficult than I thought. It seems like encryption is not as quick and easy as .NET makes it (good thing or bad thing?).  Given that my goal is to learn as much of Node JS as fast as possible, I am going to defer that til later. I am going to plan on leaving the encryption/decryption within the .NET API and pass the user name and salted hash for comparison in this version of the TGIMBA Node JS API.

After getting it to work locally, I deployed to the AWS bean stock and it seems to work…mostly!  Upon testing, the getUserCount() method returns as does a good user.  However, I think I need to handle a null SQL Server result differently.  Next blog entry 🙂

Get User Count



‘Good User’


‘Bad User’


Stay tuned!



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s