Fire and Fury of Node.js callback

Aelafseged
Sep 3, 2018 · 4 min read

Handling asynchronous tasks comes in many shapes and sizes, and callbacks had been the traditional way of handling it since the dawn of node.js civilization… but they had a reputation of fire, hell and fury. We will be dealing with it’s concept and practicality.

My First encounter with node.js was with a tag word of “callback hell and how to avoid it”.

As a first timer… you can imagine the feelings as with every turn of googling there were this call backs hells and all it’s fire and fury and how to avoid it with promises, the usage of ES6 syntax and plenty of npm libraries dedicated for such situations. Honestly it was really energy consuming, as I am a java developer all I wanted was practical examples and solutions, as it was out of professional necessity of choosing to build a scale-able and requirement fitting web server in node.js. For some weeks I was struggling to take routes that can avoid callbacks even before what it was in first place[a horrible mistake!!!]. It’s like you traveled to a country in hope of taking a perfect sunset picture with the rest of enjoyment but then you keep coming up to a police homicide report of the neighborhood. I hope this article will help you to avoid such energy draining experience and spear head the concept and practicality of callbacks and hopefully enjoy sunset.

Whether we are working procedural or object oriented programming, in a Synchronous execution there is one line of execution flow, meaning one line of code is executed after the other. When a line of code is taking too long to execute(could be math calculation or requesting a network resource) it becomes a blocking code(or humorously we can say code blocker ). In java we use a thread, a separate line of execution can be used. I have a tutorial dedicated to multithreading in java.

But in node.js when we chose asynchronous( we can have synchronous functions, there are times when we can use those) functions it happened as follows, you called a function for some task and that function says I will call you back when i’m done just go do your thing. And you continue your task, that called function can take fractions of seconds or a solid few seconds to finish it’s task, and calls you back with a result, that result can be an error code, or any data. My fellow coding comrades, that is async function calling using callback. It’s similar to Java’s lambda expression, sending a function as a parameter!

Here is a bare bone with an inch of layered meat structure of callback code snippet.

/**
asynchronous function call named doCallBack
*/
doCallBack(param1, param2, function(err,result){
//with two parameters and a callback function that expects two parameters
//when a result arrived it's called back with “err” and “result” value
});
//execution continues...

// in another file a function lays still to embark on execution
exports.doCallBack = function(param1,param2,callback){
//receives the two parameters do the execution( can call another async or sync function)and
//use the "callback parameter" as a method and send back result and error values as it's parameters
//do an operation like network or database call based on the two parameters then
//callback(“err value”,”result value”);
};

All the comments can explain

adding all the organs into the code gives us the following.

//asynchronous function call
doCallBack(param1, param2, function(err,result){
if(err!=null)
console.log('oh no, err arrived'+err);
else if(result!=null){
//your callback fallout reaching here
console.log("result arrived.." + result);
}
});
exports.doCallBack = function(param1,param2,callback){
// do an operation like network or database call based on the two parameters
var result = operation(param1,param2);
if(result==null)
callback("no result",result);
else
callback(null,result);
};

Then you may ask where the hell does that “Hell” exist? Bare with me… the alleged or criminally indicted “callback hell” come to existence when there are chains of asynchronous callback functions that you must write within the else if blocks, then the next function within the inner else if function frankly I don’t see no hell in such coding, yes it’s not pleasing to the eye nor is not walking in a park when navigating around( a a french royal palace maize garden perhaps?) my point is let’s digest this concept for a while try it out, test it on server and if we can find better solutions like a promise, we can switch but what’s the trade-offs learning the concept, development time, execution time or debugging time if all that out-weigh by new methods escaping the Fire and fury of callbacks hell should be a serious thought to be considered else stay in the high way to hell, I mean callbacks.

Have a blazing coding time, I will call you back.

compute and beyond

A sancturary for destined software Jedi, mastering the Force to create exciting software products.

Aelafseged

Written by

Light skinned African Software Developer; Excited to share ideas from cutting edge tech to chasing butterfly Blogs @ htttp://codemyeritrea.blogsopt.com

compute and beyond

A sancturary for destined software Jedi, mastering the Force to create exciting software products.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade