How Node.js natively supports asynchronous processes
Yes, native support of asynchronous goodness come with Node.js installation.
Yes, it supports async behaviour, but does not apply to your code directly.
No, we’re talking about user designed processes, not the Node’s under-the-hood I/O sorcery (more on that later!).
No, asynchronous behaviour does not equal to multi-threading per-se, especially in the context of the “non-blocking I/O” which is mentioned in the description at nodejs.org.
I guess that answered your questions which you were probably about to ask, but let’s dive deeper!
In the context of writing asynchronous JavaScript functions and features, like async XML HTTP Requests (XHR) and Event Callback Functions, we often forget to assess how are these truly synchronous or asynchronous (or simply uncertain), and whether we want them to be so or not. It thus becomes important to understand that most of the common terms used in such context fail to accurately describe the situation in a technically correct manner which may mislead one during the design process.
Let’s first disrupt, or rather de-clutter, the ideas surrounding “callback functions” and their “asynchronous behaviour”. A Callback Function is simply a JavaScript function which is called after a certain trigger has been pulled off. The function body of the same may be simply logging some stuff, or even launching rockets and spaceships, or both. Either way, the code of the body would actually determine the nature of the function execution, and that would correctly classify the Callback as Asynchronous or Synchronous, for virtually all callbacks are synchronous, as their attachment to events is a synchronous process itself, but not the execution of it, thus providing them with a pseudo-asynchronous natural behaviour.
A simpler function body which does a single task only, cannot be called truly asynchronous, for there is no second work in the same function which requires execution at some point in time. The same applies to XHR requests made inside callbacks, for the work is singular only : only the HTTP Request made through XHR is asynchronous, but not the process itself. Indeed the “asynchronous” word spread from this elusive concept only, creating a slightly misunderstood meaning of the same.
On the other hand, callback functions with more complicated body may or may not be executed synchronously or asynchronously, depending on the kind of work they hold. For example, a callback function wants to validate some form data, and then depending on the result, submit or reject the final submission of the form. This is purely synchronous behaviour of the function as it is performed in the given sequence, and it is required in that way as well. Meanwhile, if the same function had to validate the form data, and then perform intensive calculations on the same, then the second process would be blocking other processes due to the synchronous nature.
Here, we can use process.nextTick() method native to Node.js to make it truly asynchronous, that is, we can defer the execution of calculation function till the current stack is processed and cleared. This makes the callback function truly asynchronous and nonblocking to the developer’s code.
A special case may be of multiple XHR calls dependent or independent of each other. Since these are asynchronous by nature itself, they are not blocking, but multiple such calls become difficult to manage through synchronously written code, as well as the arrival of response becomes unpredictable. For such cases, it’s best to use Promises to simplify the entire XHR management. Note that the Promise chain itself is a blocking operation, so it may be used along with a process.nextTick().
Thus, the asynchronous process/function management in Node.js is supported natively by it’s Process API, and can greatly improve the performance and design of your code.