Today we continued work on the back end API. Engineering.com is going to hand over credentials to limited access to their Amazon Web Services account soon so we can begin testing it on there, so our goal is to have a simple version of the back end API created by Tuesday, preferably also with some client side code Engineering.com can put into their CMS system to call the back end API.

I had to get accustomed to a new Node.js concept today. I was vaguely aware so far of the concept of “middleware”, where functions are executed asynchronously as Node.js completes an http request, but so far I didn’t have to add my own middleware. Now that we’re coding our back end API to be quicker and more efficient with data transfer, I need to get comfortable with it.

Here’s how things are done without middleware:

Normally, http requests come in from the browser to the server and the server sends a response. I’ll call this a “complete request”. If you need to do some work in the web server, during that request, you might choose to spawn a new http request, just to do that work (like getting the data). So for example, if a complete request involves getting a fruit basket, and in order to do that, that fruit basket needs an apple and a banana, the “get fruit basket” request won’t be complete until it starts and receives responses from a “get apple” request and a “get banana” request, both of which would be considered complete requests before the “get fruit basket” request is complete. The client connecting in would only be executing one “get fruit basket” request, the requests that one spawns is abstracted out.

For a more technical, web development type example, it might be like a weather webapp responding to a “get the weather” request with “the weather” in the response, but behind the scenes, it needs to start and receive responses from a “get temperature” request and a “get air pressure” request. Perhaps to get that information, it sends those http requests to weather stations located who knows where.

And here’s how we’re using middleware:

We could do that for our application, but we want to minimize the number of requests the client side sends via AJAX, for multiple reasons. So our client side code will do a “send hit” request into our back end API, which will then break that hit model into the various little models we’re storing in our MongoDB database. The middleware is those requests. Like the “get apple” example above, we have “put platform” (which refers to info about the user agent), “put session” (if they’re starting a new session of hits that we need to track), etc. The client only does a “put hit” request to accomplish this.

And this is okay for us to do because we’re not talking about reaching out to other web apps, to other APIs, to do those middleware steps. We’re staying inside our web app. So there’s no need to go through all the trouble (and added overhead) of doing http requests. We just call functions in our web app.

To implement it, we just add the JavaScript functions doing all those little things into a row of functions the main request needs to call to get it ready to response. A little care is taken to make everything happen in the right order, since it is asynchronous with callbacks, but it seems to be working well so far.



Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s