Here we will look at Node.js event loops and callbacks in a much more detailed way. JavaScript is a single threaded programming language, with a single threaded Runtime, it has a single call stack. And it can do one thing at a time, that’s what a single thread means, the program can run one piece of code at a time.
let’s try and visualize that just to get our heads around what that mean, so if we have some code like this –
function printMessageOnScreen(message){
console.log(message)
}
function inBetweenMessage(inputSentence){
return printMessageOnScreen(inputSentence)
}
function mainFunction(messageToPrint){
messageToPrint = (“This is events loop in node.js”)
inBetweenMessage(messageToPrint)
}
we’ve got 3 functions, a function printMessageOnScreen which takes arguments as message that was passed to it via the function inBetweenMessage to which the inputSentence was passed by the mainFunction.
So, if we run this, well, I should back up a step, so the call stack is basically it’s a data structure which records where in the program we are, if we step into
a function, we put something on to the stack, if we return from a function, we pop off the top of the stack, that’s all the stack can do, so if you run this file, there’s a main function, , like the file itself, so, we push that on to the stack. Then we have some function definitions, they’re just like defining the state of the world, and finally we get the message “This is events loop in node.js” printed on the screen, so we push that on to the stack, and immediately inside the function “mainFunction” , we push on to the stack, which calls the “inBetweenMessage” function, so now we have a return statement, which calls the function “printMessageOnScreen” which is the last function in this 3 step funnel.
when we return we pop something off the stack, so we pop another function inside the main and this goes on for 3 times and finally prints the message.
So although I may be representing a new side of the call stack you have some sense of it in your development practice already.
So, the big question then comes is like what happens when things are slow?
So, we talk about blocking and blocking behavior and blocking, there’s no strict definition of what is and didn’t blocking, really it’s just code that’s slow.
So console.log isn’t slow, doing a while loop from one to ten billion is slow, network requests are slow. Image requests are slow.
Things which are slow and on that stack are what is the term blocking means. See this post to know about the semantics behind a RESTFUL API
So heres a little example, so let’s say we have a code, get output in synchronous way, for example an AJAX or a jQuery request. What would happen if those were synchronous requests
var callAServer = $.getSync(‘https://example.com’)
var callAServer2 = $.getSync(‘https://example1.com’)
var callAServer3 = $.getSync(‘https://example2.com’)
console.log(callAServer)
console.log(callAServer2)
console.log(callAServer3)If we go through it like we have, we call getSync example.com, example2.com then example3.com and just call and then we wait, because then we’re
doing network request, network is relative to computers, network requests might be slow, we hopefully wait so that the network requests completes, we can move on, wait, move on. Wait, and, I mean, this network request might never finish.
Finally those three calls, are completely blocking behaviors and we cant clear the stack. See this post about node.js and how it is the most advanced backend solution
So in a programming language is single threaded we’re not using threads, suppose we make a network request, we have to just wait till it’s done, because we have no way of handling that. The problem is because we’re running code in browsers.
So in Chrome which gives us synchronous AJAX request, so while a particular function is running to fetch data from 1 particular server we can’t do anything, even the run button hasn’t finished rendering yet that’s because The browser is blocked, it’s stuck, it can’t do anything until those requests complete.
That’s because if that call stack has things on it, it’s still going and the stack is blocked. Know about the semantics behind node.js filesystem
We’ve got the synchronous request, the browser can’t do anything else.
It can’t render, it can’t run any other code, it’s stuck.
Not ideal, if we want people to have nice fluid UIs, we can’t block the stack.
So, how do we handle this?
Well the simplest solution we’re provided with is asynchronous callbacks, there’s almost
no blocking functions in the browser, equally in node, they’re all made asynchronous, which basically means we run some code, give it a callback, and run that later, if you’ve
seen JavaScript you’ve seen asynchronous callbacks, what does this actually look like.
console.log(“Sentence 1”);
setTimeout(function(), {
console.log(“sentence 2”);
}, 7000);
console.log(“Sentence 3”);first we log “sentence 1” then there’s a setTimeout function, we run the setTimeout, but that queue’s the console.log to print sentence 2 for future so we skip on to
sentence 3 and then 7 seconds later we log the sentence 2.
Basically till the 7 seconds of time the function setTimeout is doing something.
So, asynchronous callbacks with regards to the stacks we saw before … how does this
work?
We know that the setTimeout function doesn’t run immediately, we know it’s going to run in 7 seconds of time ahead, we can’t push it on to the stack, somehow it just disappears.
We log sentence 3 and after 7 seconds later somehow the sentence 2 appears on the stack.
How does that happen?
And that’s this is basically where the event loop comes in on concurrency. Check this post for node.js http server implementation
Right, so I’ve been kind of partially lying do you and telling you that JavaScript can
only do one thing at one time. That’s true the JavaScript Runtime can only do one thing at one time.
It can’t make an AJAX request while you’re doing other code. It can’t do a setTimeout while you’re doing another code. See this post about Client Server Architecture and how all the devices we use today is based on this method discovered in 1960’s
The reason we can do things concurrently is that the browser is more than just the Runtime. So, by looking at this diagram, the JavaScript Runtime can do one thing at a time, but the browser gives us these other things, some of these APIs, these are effectively threads, you can just make calls to, and those pieces of the browser are aware of this concurrency. If you’re back end person this diagram looks basically identical for node, instead of web APIs we have C++ APIs and the threading is being hidden from you by C++.
Now we have this picture let’s see how this code runs in a more full picture of what a browser looks like.
So, same as before, run code, console.log logs sentence 1.
now we can see what happens when we call setTimeout.
we pass this callback function and a delay to the setTimeout call.
Now setTimeout is an API provided to us by the browser, it doesn’t live in the V8 source,
it’s an extra feature we get in that we’re running the JavaScript runtime right now. Check this post about callbacks in node.js and its asynchronous features
The browser kicks off a timer for you. And now it’s going to handle the count down for you, right, so that means our setTimeout call, itself is now complete, so we can pop off the stack.
Now sentence 3 gets in clear, so, now we’ve got this timer in the web API, which 7 seconds later is going to complete. Now the web API can’t just start modifying your code, it can’t push stuff onto the stack when it’s ready if it did it would appear randomly in the middle of your code so this is where the task queue or callback queue kicks in.
Any of the web APIs pushes the callback on to the task queue when it’s done.
Finally we get to the event loop, and it has one very simple job.
The event loops job is to look at the stack and look at the task queue. If the stack is empty it takes the first thing on the queue and pushes it on to the stack which effectively run it.
So here we can see that now the stack is clear, there’s a callback on the task queue, the event loop runs as it sees a task in the stack, pushes the callback on to the stack.
The process that’s happened here is first we have logged sentence 1, then it sees a callback function which takes 7 seconds to print the sentence 2. So this function of setTimeout for 7 seconds of time is pushed inside the task queue and looks for the next available function which is the console.log message to print the sentence 3. But back in the task queue the 7 seconds of time is being passed and the event loop keeps looking if any callback has completed, if so then immediately push it back into the stack so now after sentence 2 printed and while the time it took to print the sentence 2 the task queue was in parallel running the 7 seconds function in a background thread. Check this post about HTTP status codes and response request cycle
So suppose if there is a more advanced example –
console.log(“Sentence 1”);
setTimeout(function(), {
console.log(“sentence 2”);
}, 7000);
console.log(“Sentence 3”);
setTimeout(function(), {
console.log(“sentence 4”);
}, 5000);
setTimeout(function(), {
console.log(“sentence 5”);
}, 500);
So in this case what will happen is this –
Printed sentence 1
Got a callback -> pushed it into the task queue and the event loop waits for it to finish after 7 seconds. (Sentence 2)
Printed sentence 3
Got another callback -> pushed it into the task queue and the event loop waits for it to finish after 5 seconds (sentence 4) in concurrent to the 7 seconds task . (sentence 2)
But now its got a callback of 500milliseconds
Now if we can guess what will happen sentence 5 will appear before 2 and 4. Know about the node.js core modules with examples in concise
Something like this
Sentence 1 less than 0.5 seconds
Sentence 3 less than 0.5 seconds
Sentence 5 (callback sentence) 0.5 seconds
Sentence 4 (callback sentence) 5 seconds
Sentence 2 (callback sentence) 7 seconds
That is because while sentence 1 and 3 was getting printed which didn’t had a callback and was no- blocking in nature, and the time which took to print sentence1 & 3,then the sentence 5 which just takes half of a second to print appears so this happens
concurrently the event loop has pushed these sentences 2,4,5 in task queue and as soon as they finish its pushed into the stack. See this post about the Express framework in node.js
The event loop, it has to wait till the stack is clear before it can push the callback on to the stack
setTimeout, is deferring that execution of code, for whatever reason to the end of the stack. Or until stack is clear.
So, all these web APIs work the same way, if we have AJAX request, we make an AJAX request to the URL with a callback, works the same way, make
an AJAX request, the code for running that AJAX request does not live in JavaScript Runtime but in the browser as a web API, so we spin it up with a callback in the URL, your codecan continue to run. Check this post about importing modules in node.js
Until that AJAX request completes, or it may never complete, it’s okay, the stack can continue to run, assuming it completes, gets pushed to the queue, picked up by the event loop and it’s run.
That’s all that happens when an Async call happens.