JavaScript is single-threaded, so how does it handle asynchronous code without blocking the main thread while it waits for an action to complete? The key to understanding the asynchronous nature of JavaScript is understanding the event loop. In the browser, the coordinates the execution of code between the call stack, web APIs, and the callback queue. Node.js, however, implements its own " ," which is different from the regular "JavaScript event loop." How confusing! event loop Node.js event loop The Node.js event loop follows many of the same patterns as the JavaScript event loop but works slightly differently, as it doesn't interact with the DOM but does deal with things like input and output (I/O). In this article, we'll dive into the theory behind the Node.js event loop and then look at a few examples using , , and . We'll even deploy some working code to (an easy way to quickly deploy apps) to see it all in action. setTimeout setImmediate process.nextTick Heroku The Node.js Event Loop The Node.js event loop coordinates the execution of operations from timers, callbacks, and I/O events. This is how Node.js handles asynchronous behavior while still being single-threaded. Let's look at a diagram of the event loop below to get a better understanding of the order of operations: The Node.js event loop's order of operations (Source: Node.js docs ) As you can see, there are in the Node.js event loop. Let's briefly look at what happens in each phase: six main phases : callbacks scheduled by and are executed during this phase Timers setTimeout setInterval : I/O callbacks that were previously deferred to the next loop iteration are executed during this phase Pending callbacks : this phase is only used internally by Node.js Idle, prepare : new I/O events are retrieved and I/O callbacks are executed during this phase (except for callbacks scheduled by timers, callbacks scheduled by , and close callbacks, because those are all handled in different phases) Poll setImmediate : callbacks scheduled by are executed during this phase Check setImmediate : close callbacks, like when a socket connection is destroyed, are executed during this phase Close callbacks It's interesting to note that isn't mentioned anywhere in any of these phases. That's because it's a special method that's not technically part of the Node.js event loop. Instead, whenever the method is called, it places its callbacks into a queue, and those queued callbacks are then "processed after the current operation is completed, regardless of the current phase of the event loop" (Source: ). process.nextTick process.nextTick Node.js event loop docs Event Loop Example Scenarios Now, if you're like me, those explanations of each phase of the Node.js event loop may still seem a little abstract. I learn by seeing and by doing, so for running various code snippet examples. In the app, clicking on any of the example buttons sends an API request to the server. The code snippet for the selected example is then executed by Node.js on the backend, and the response is returned to the frontend via the API. You can . I created this demo app on Heroku view the full code on GitHub Node.js event loop demo app Let's look at some examples to better understand the order of operations in the Node.js event loop. Example 1 We'll start with an easy one: Example 1 - synchronous code Here we have three synchronous functions called one after the other. Because these functions are all synchronous, the code is simply executed from top to bottom. So because we call our functions in the order , , , the functions are executed in the same order: , , . first second third first second third Example 2 Next, we'll introduce the concept of with our second example: setTimeout Example 2 - setTimeout Here we call our function, then schedule our function using with a delay of 0 milliseconds, then call our function. The functions are executed in this order: , , . Why is that? Why is the function executed last? first second setTimeout third first third second second There are a couple key principles to understand here. The first principle is that using the method and providing a delay value mean that the callback function will be executed that number of milliseconds. Rather, that value represents the amount of time that needs to elapse before the callback will be executed. setTimeout doesn't exactly after minimum The second key principle to understand is that using schedules the callback to be executed at a later time, which will always be at least during the next iteration of the event loop. So during this first iteration of the event loop, the function was executed, the function was scheduled, and the function was executed. Then, during the second iteration of the event loop, the minimum delay of 0 milliseconds had been reached, so the function was executed during the "timers" phase of this second iteration. setTimeout first second third second Example 3 Next up, we'll introduce the concept of with our third example: setImmediate Example 3 - setImmediate vs. setTimeout In this example, we execute our function, schedule our function using with a delay of 0 milliseconds, and then schedule our function using . This example begs the question: Which type of scheduling takes precedence in this scenario? or ? first second setTimeout third setImmediate setTimeout setImmediate We've already discussed how works, so we should give a brief background on the method. The method executes its callback function during the "check" phase of the next iteration of the event loop. So if is called during the first iteration of the event loop, its callback method will be scheduled and then will be executed during the second iteration of the event loop. setTimeout setImmediate setImmediate setImmediate As you can see from the output, the functions in this example are executed in this order: , , . So in our case, the callback scheduled by was executed before the callback scheduled by . first third second setImmediate setTimeout It's interesting to note that the behavior you see with and may vary depending on the context in which these methods are called. When these methods are called directly from the main module in a Node.js script, , so the callbacks could actually be executed in either order each time you run the script. However, when these methods are called within an I/O cycle, the callback is always invoked before the callback. Since we are invoking these methods as part of a response in an API endpoint in our example, our callback always gets executed before our callback. setImmediate setTimeout the timing depends on the performance of the process setImmediate setTimeout setImmediate setTimeout Example 4 As a quick sanity check, let's run one more example using and . setImmediate setTimeout Example 4 - setImmediate versus setTimeout again In this example, we schedule our function using , execute our function, and then schedule our function using with a delay of 0 milliseconds. As you might have guessed, the functions are executed in this order: , , . This is because the function is scheduled, the function is immediately executed, and then the function is scheduled. During the second iteration of the event loop, the function is executed since it was scheduled by and we're in an I/O cycle, and then the function is executed now that we're in the second iteration of the event loop and the specified delay of 0 milliseconds has passed. first setImmediate second third setTimeout second first third first second third second setImmediate third Are you starting to get the hang of it? Example 5 Let's look at one last example. This time we'll introduce another method called . process.nextTick Example 5 - process.nextTick In this example, we schedule our function using , schedule our function using , schedule our function using with a delay of 0 milliseconds, and then execute our function. The functions end up being called in the following order: , , , . first setImmediate second process.nextTick third setTimeout fourth fourth second first third The fact that the function was executed first shouldn't be a surprise. This function was called directly without being scheduled by any of our other methods. The function was executed second. This is the one that was scheduled with . The function was executed third, followed by the function last, which shouldn't be a surprise to us either since we already know that callbacks scheduled by get executed before callbacks scheduled by when inside an I/O cycle. fourth second process.nextTick first third setImmediate setTimeout So why did the function scheduled by get executed before the function scheduled by ? The method names are misleading here! You would think that a callback from would get executed while a callback from would get executed on the of the event loop. However, . Confusing, right? second process.nextTick first setImmediate setImmediate immediately process.nextTick next tick it's actually the other way around It turns out that a callback from gets executed immediately during as it was scheduled. A callback from gets executed during the next iteration or tick of the event loop. So in our example, it makes sense that the function scheduled by was executed before the function scheduled by . process.nextTick the same phase setImmediate second process.nextTick first setImmediate Conclusion By now you should be a little more familiar with the Node.js event loop as well as with methods like , , and . You can certainly get by without digging into the internals of Node.js and the order of operations in which commands are processed. However, when you begin to understand the Node.js event loop, Node.js becomes a little less of a black box. setTimeout setImmediate process.nextTick If you want to see these examples live in action again, you can always or . You can even . check out the demo app view the code on GitHub deploy the code to Heroku yourself by clicking here Thanks for reading!
![An Encryption Deep Dive - Part Four [AWS Encryption Services]](https://hackernoon.imgix.net/images/tb1w30tu.jpg?auto=format&fit=max&w=3840)
