Monthly Archives: April 2016

Callback Hell, Express, and Koa

I would like to start off by saying that I love Node because it was enables me to write full-stack web applications built entirely in JavaScript.  A lot of applications only use JavaScript for the front-end of the app because that is what it was originally intended for, but with Node we can build entire applications!  Yay!  *raucous applause*

However, using Node on its own can be tricky.  When I was first learning how to set up my server-side using Node, my friend gave me this advice: “First lesson in using Node – use Express. ”  I was curious about what he meant, but forged forward, only to soon find myself in callback hell with a series of other issues.

Callback Hell

Callback functions are functions that are executed at a later point in time.  Because JavaScript allows for asynchronous behavior, Node uses callbacks a lot to help deal with this. Instead of having functions just return a value, they will wrap that result in a callback function.  Since functions can’t execute until all the parameters are evaluated, the callback will only fire once the asynchronous job it needs to do is complete.  Once you get used to callbacks they aren’t so bad, but your code can get complicated and hard to read if you don’t take steps to keep your code modular and clean.  Callback hell happens when you end up having callbacks within callbacks within callbacks.

Additionally, when using Node on its own, you have to worry about parsing POST requests in a certain way.  Frameworks have many different modules you can choose from to simplify this process.

Solution: Frameworks


Express is a popular framework to use with Node.  Honestly, once I started using Express I have never gone back to creating an app using just Node by itself – there are just too many benefits.  Express makes routing, serving up your static files, and a host of other things super simple.  For instance, you can require body-parser, a middleware that helps you take care of parsing data easily.


Koa differs from Express because it uses generator functions, a feature in ES6 that I happen to like a lot!  Interestingly, the people who are behind Koa are the same people that made Express, and they set out to make a tool that would make creating the server side your app even easier.  Anything you can do with Express you can do with Koa, but getting used to generator functions their syntax can take a little time.


I’m realizing as I’m writing this that this blog post should/could actually be turned into about three or four posts specifically introducing Express and Koa specifics.

TL;DR: Simplify your life by using Express or Koa when using NodeJS.


Event Loop in JavaScript

Last week, I wrote about blocking vs. non-blocking code and the asynchronous nature of JavaScript.  This week I wanted to deep dive into the event loop to explain one way JavaScript is able to deal with asynchronous functions and enables it to have non-blocking behavior.

Runtime Environment

Many people use JavaScript for the client-side of their app, but it can also be used on the server-side while using NodeJS.  No matter where the code is being executed, i.e. its runtime environment, the event loop impacts the order that functions are called.

The JS engine goes through every line of code in your application and has to make decisions about when that code should be run.

The Infamous Call Stack


A stack!  Okay, so not a call stack, but delicious nonetheless.

A stack is a common data structure.  It functions exactly the stack of pancakes my dad makes for the whole family during the holidays – one at a time, people are able to remove a pancake from the top of the stack and to their plate.  A stack works the same way – data on top of the stack can be removed, as well as added to the top of the stack until it needs to be processed.

The call stack is a special kind of stack in the JS engine.  It processes one line of code at a time, and it executes whatever is on top of the stack.  As soon as that function is finished executing, it is removed from the stack, and the line that was previously second in line is pushed to the top and executed.

Callbacks and Event Queues

Say we arrive at a line of code that needs this asynchronous behavior.  Maybe you wrote a setTimeOut in your code to invoke a function at a later time, or perhaps a function that needs to get data from the database.  These are called callback functions and the JS engine has a special way of handling them.

Instead of putting them directly into the call stack, the JS engine puts them into an event queue where it waits to be executed.  Once the call stack is empty, it checks out the event queue and moves any function that is next in line to the call stack where it is executed.

Event Loop

The event loop is this process the JavaScript engine uses to execute functions on the call stack while also checking and eventually executing the next function in line in the event queue.  As the user interacts with an application, the call stack and event queues are constantly moving and cycling through the code and reacting in response to user behavior.  This keeps your program running smoothly!

While this is a very simplified version of what happens inside of a JavaScript engine, it is important information to keep in mind when writing code.


Blocking and Non-blocking Code

A Tale of Two Burger Joints

Restaurant #1

You wait in line so the cashier can take your order. There’s about 4 guests ahead of you, and an ever increasing line of people behind you. Once you place your order, they give you a pager that lights up and vibrates when your food is ready. You step off the line and wait with the other people who placed their order before you. Eventually your buzzer goes off, you take your tray of deliciousness from the counter, and squeeze past the lines of people waiting to find a table. This whole process takes about 20-30 minutes.

Restaurant #2

There are about 3 people in ahead of you in line. The cashier takes the order of the person in front. Then, after about 15 minutes, the customer’s food is ready and they take it and leave. Now there are only 2 people in front of you in line, and the same process happens: no other orders can be taken until the transaction is complete. You have to wait until everyone in front of you places their order, pays, and gets their food. The whole process takes a really long time.

So What?

You may be thinking that Restaurant #1 sounds like any fast food place, and that you would never see a place like Restaurant #2 in business.

What does this have to do with code? Code can be blocking, like Restaurant #2. Code can also be non-blocking, like Restaurant #1. Javascript by nature is non-blocking and allows asynchronous functions to exist. From what I’ve gathered, it can take a little getting used to if you are used to writing blocking code that has to go in a certain sequence.

Some actions that need to take place in a program are asynchronous by nature.  For example, say you need to retrieve data from a database – it takes time for your program to go to the database, get the data, and return it to the client side of your app.  Meanwhile, the rest of the page still needs to load.  It would not make for a good user experience for them to look at a blank screen while the database was accessed.  Usually, you might see most of the page loaded, and maybe a spinner or message that lets the user know they are waiting for the data.  When writing code in Javascript, it’s important to keep asynchronous operations in mind so that your application functions the way you want it to.

Walk-through of Feature using React and Redux

In my previous post, I described my thought process when planning to implement the delete jobs feature.  In this post, I want to walk through the complete code from the front to the back of the app.  I hope it helps your understanding of how React, Redux, and the back-end of your app go together – I know it will certainly help me remember this process for my next React project.  


When a user clicks on the job, they see a page with all of the information about that particular job being pulled in from the API.  I also created a “Delete” button on that page, which I put into its own component file.  You can see here that I’ve imported the “raised button” component for styling from Material-UI, and that the component itself (written in JSX) has a label that says “Delete Job.”  In the Material-UI documentation for Raised Buttons, OnMouseDown is a property on the button itself that initiates a callback function when the button is pressed.  In this component, the callback is called “props.handleDelete” which we will get to see in action in the JobViewContainer where the component actually goes.


This a snippet of code for the JobViewContainer, where handleDelete is actually called. The props.handleDelete in the DeleteJobComponent from above can be seen here as a property of this container: this.handleDelete.   You can also see that the ‘this’ keyword is bound to it in the constructor of the component so that it knows exactly which job is being viewed in the container.


Below the constructor, here is the actual code for handleDelete, which will be called when the delete button component from above is clicked.  Basically, the dispatch function here initiates the deleteJob function inside of the Redux store, which starts the call to the database.  As you can see, we send in the specific jobID as a parameter to this function so that we can correctly identify which job we want to delete from the database.  The last line directs the user back to the dashboard after this function is called.


Into the Server and Back Again

This is where the deleteJob function being called in the JobViewContainer above lives.  Delete job makes a DELETE request to the database using axios, a promise based HTTP client.  You can see that this also dispatches other actions: dbRequest, deleteJobSuccess, and dbSuccess or dbFailure depending on the result from the call to the database.  The three functions dbRequest, dbSuccess, and dbFailure are called in any function that makes a call to the database to control spinners on the page that let the user know the application is waiting for data.


When the axios call is made, the id is passed along that particular API route and onto the deleteJob method in the jobs controller where all the other methods related to job manipulation live.


The actual deleteJob method that queries the database (using the ORM) is below.  If you’ve never seen a function like this before, it’s called a generator function and they are supported in ES6.  You can tell it’s a function generator because of the asterisk (*) next to the function declaration, as well as the ‘yield’ on the fourth line.  I love the concept of generator functions because they allow you take care of the asynchronous nature of calls to a database (as is the case with this particular method) in a different format.  Read up on them here.  Basically this function receives the id of the job the user wants to delete, and then deletes it.  It also sends back to the front-end which job has been deleted so that it can be taken out of the view.  Alternatively, errors are handled in the catch block in case there were any problems with access the database.


Reducer Time!

Above in the deleteJob function on the front-end, you might recall that inside of the call to axios, an action called “DELETE_JOB_SUCCESS” is dispatched inside of the reducer.  Remember, a reducer takes the previous state, combines it with an action, and returns the NEW state (ie – view) of the application.  In our case, it deletes any reference to the delete’s job on the user’s dashboard.  This reducer is specifically taking care of all the actions that have to do with jobs – setting a user’s saved jobs on the dashboard, adding jobs, and deleting jobs.  We are able to isolate the jobID from the job object that is returned from the database.  “DELETE_JOB_SUCCESS” then loops through all the jobs currently in the state until it finds the one with the matching id, and then deletes it from the view.


Use Value

I love using React with Redux because it helps keep your code modular and clean.  In my mind, it is super clear how the user pressing the delete button sets off the chain of events that deletes all references to the job in the database and also in the view. It takes getting used to, but is great to use once it is set up!