Understand the Node.js process object
In this lesson, we introduce the process object, part of the node.js global namespace. The process object is extremely useful for identifying information about the runtime environment of your node app such as the version of node, the arguments passed to the node executable, the current working directory, and the nextTick function. All of these are discussed and illustrated with examples in this lesson.
[00:01] The next global object we want to talk about is the Process object. As the name implies, the Process object exposes many of the functions and properties about the specific process running your instance of Node.
[00:15] So, if we go back into our Node REPL interface, we can actually type global.process and see everything that's contained within the global process. We can narrow that down further to take a look at the specific version of Node that you're running. Or you can use the plural versions and see not only version of Node that's running, but the versions of all the dependencies in the Node stack.
[00:45] You can take a look at the current working directory. You can also read and write to the standard IO streams, such as standard in, standard out, and standard error.
[01:01] We can make an example here to show how that works. If we type "var logger" to create a function that accepts a single parameter and that parameter's just going to get written out to the standard out using the process.stdout.write. Then we'll just add a new line on to the end of that.
[01:33] So then, we can execute that. If that looks familiar, it should, because it's actually the exact same thing that happens when you do a console.log.
[01:53] One of the most common things that you're probably going to use the Process object for is picking up on the arguments that were passed along the command line to your Node app.
[02:02] To demonstrate how that works, we can exit the REPL interface. Let's create a file called arguments.js. Inside of arguments.js, we're just going to call the process.argv, which is an array, so we're going to use a foreach. And then we're just going to log out the individual components of that array along with their index.
[02:51] Now we can execute that and watch it action by calling the Node command, passing in the name of our arguments.js file, and then just some random strings here at the end to watch it work. You get an idea here of the argv array and how it works.
[03:11] The thing to note here is that index zero of that array is the Node executable itself. Index one is name of the JavaScript file we passed to node. And so realistically the first index item in the array that you're going to be interested in is going to be starting at index position two and moving on from there.
[03:34] If we want to look at the process.nexttick function, we can do so by creating a file. We're just going to create tick.js. Inside of there, let's write console.log, and we'll say start. And then we'll call the process.nexttick function. We're going to pass it a callback. That's just going to write out to the console.
[04:16] And then we're going to do one more console statement here, and we're going to use the word scheduled there. You're going to see in a just a minute why I chose to use that word.
[04:24] So now if we run that with our node command, you see what happens is first the start console log statement was run. Then it jumped all the way down to the bottom and ran scheduled, before coming back around to run the nexttick callback.
[04:43] So let's go in and take a looking inside our tick.js file and look at the code. Remember, the first thing we saw was start, ran. Then it went all the way down and ran scheduled before it came back around and ran the nexttick callback console log statement.
[05:04] The key to understanding why it worked that way and how it worked that way is to remember that Node is an event loop processor. Meaning, it just runs through in a loop looking for events that it can execute. What the nexttick function does is it doesn't do anything the first pass through, other than say the next time through, execute this callback.
[05:29] So functionally, you might think this is very similar to settimeout, where you have a function that you call, and then you supply a zero length or a zero time for the time out of the function. Operationally, both of those are going to execute the same way.
[05:50] The difference being is that settimeout requires IO from your system in managing that time out function. Even though the time is set to zero, it still introduces IO overhead. Whereas the nexttick has no additional IO overhead associated with it.
[06:07] On a small scale, you're not going to see any difference. But as your app grows, either in complexity or in scale, that additional IO is going to start to have an impact on your server. That's the reason you're going to want to lean towards using nexttick versus a zero length time out function.
here is the compare between setTimeout and nextTick
https://gist.github.com/wyvernnot/f406b3276f667f989ac984b61034058e
at 4:22 there is a ')' missing in the tick.js file to close the process.nextTick( -> SyntaxError: missing ) after argument list
Could you explain the I/O overhead part? We gloss over that but this is a fundamentals course, that seems pretty fundamental to me. Thanks!
Could you explain the I/O overhead part? We gloss over that but this is a fundamentals course, that seems pretty fundamental to me. Thanks!
I second this!
Could you explain the I/O overhead part? We gloss over that but this is a fundamentals course, that seems pretty fundamental to me. Thanks!
I second this!
I third this!
From what I understood after reading the docs https://nodejs.org/es/docs/guides/event-loop-timers-and-nexttick what he meant by "I/O overhead" is that the time we use as threshold for timers is not guaranteed since node's event loop could be in poll phase checking and executing callbacks related to I/O (reading files, api calls, etc.) which by then have higher priority and could take longer than the time we expect our timer's callbacks to run. Only after the poll queue is empty the event loop will check for timers whose time thresholds have been reached and if one or more timers are ready, the event loop will wrap back to the timers phase to execute those timers' callbacks.
On the other side callbacks passed to process.nextTick() will be added to the nextTickQueue which will be processed after the current operation is completed regardless of the current phase of the event loop and every time before it continues to the next phase.
The key to get this is to know each phase has a queue of callbacks and timer's queue have their turn (phase) on node's event loop priorities but since the nextTickQueue is evaluated more often (on each phase before proceeding to the next one) callbacks passed to process.nextTick() will have higher priority.
Nice tutorial. But it's a bit tricky with non native English user like me. So I have to read the transcript several times to understand. I suggest that we should have diagram or some graphs to make concept/idea clearer