DEV Community: vikas mishra

Exploring Node.js: The Core Concept Behind its Asynchronous Magic

vikas mishra — Fri, 28 Jul 2023 09:38:48 +0000

In recent times, Node.js has emerged as the most popular language among developers. Its reputation is largely owed to its asynchronous nature and non-blocking IO capabilities. Having personally utilized Node.js for the past four years, I can attest to its exceptional speed and scalability. However, what many people fail to grasp is how Node.js works internally to handle these IO operations and CPU-intensive tasks.

In this blog post, we will delve into the patterns employed by Node.js to handle incoming requests and explore why it outperforms other languages. We will cover the following topics in this journey:

Blocking I/O
Non-Blocking I/O
Event Demultiplexing
Node.js Core Pattern

Blocking I/O:
Traditionally, in programming languages, when a call corresponding to an IO operation is made, it blocks the execution of the thread until the data is available. Consequently, the thread remains idle, awaiting the data and serving no other purpose during this time. This scenario can be visualized in the diagram below (Image1).

The problem becomes evident when we consider that various IO operations, such as interacting with databases or the filesystem, can potentially block a request. As a result, threads may frequently block to wait for the results of IO operations, leading to increased memory consumption, higher context switching overhead, and excessive CPU usage. Such idle times are detrimental to a thread’s efficiency.

Non-Blocking IO:
The concept of non-blocking IO involves not waiting for any data or response while executing IO operations. If a response is not immediately available, the system call must return immediately to the engine. This way, the thread does not get blocked for a response, making it available to handle other requests. Consequently, the thread’s idle time is significantly reduced compared to blocking IO, as illustrated in Image2.

Event Demultiplexing:
Event demultiplexing is an advanced technique used in Node.js. In telecommunications, multiplexing is the process of combining multiple signals into one to facilitate transmission over a limited capacity medium. Demultiplexing, on the other hand, splits the combined signal back into its original components. Similar concepts apply in various fields, including video processing.

In Node.js, a synchronous event demultiplexer watches multiple resources simultaneously. When any operation on any resource is completed, it returns a new event. Please note that it returns a new event. The synchronous event demultiplexer blocks until new events are available to process. Below is a pseudocode representation of a synchronous event demultiplexer.
watchedList.add(socketA, FOR_READ) // (1) watchedList.add(fileB, FOR_READ) while (events = demultiplexer.watch(watchedList)) { // (2) // event loop for (event of events) { // (3) // This read will never block and will always return data data = event.resource.read() if (data === RESOURCE_CLOSED) { // the resource was closed, remove it from the watched list demultiplexer.unwatch(event.resource) } else { // some actual data was received, process it consumeData(data) } } }

The process works as follows:

Resources (IO events) are added to the data structure associated with an operation.
The demultiplexer is set to watch these events, and each call is synchronous, blocking until the resources are ready for the specified operation (e.g., read).
When the operation is completed, the demultiplexer creates a new event, which is further processed or executed.
Each event returned by the event demultiplexer is processed. At this point, the associated resource is guaranteed to be ready to read and not block during the operation. Once all events are processed, the flow blocks again on the event demultiplexer until new events are available to be processed. This cycle is known as the event loop.
The diagram below demonstrates how a server utilizes a synchronous event demultiplexer and a single thread to handle multiple concurrent connections.

Node.js Core Pattern:
The core pattern employed by Node.js is called the reactor pattern. It revolves around associating a handler with each IO operation, represented by a callback in Node.js. Below is a representation of a the reactor pattern:

The following steps elucidate the application’s behavior using the reactor pattern:

The application generates a new IO operation by submitting a request to the Event Demultiplexer. Simultaneously, the application specifies a handler, which will be invoked when the operation completes. This submission is a non-blocking call, and control is immediately returned to the application.
When a set of IO operations completes, the Event Demultiplexer pushes corresponding events into the Event Queue.
The Event Loop iterates over the items in the Event Queue.
For each event, the associated handler is invoked.
The handler, being part of the application code, relinquishes control back to the Event Loop once its execution is complete (5a). During execution, the handler can request new asynchronous operations (5b), leading to new items being added to the Event Demultiplexer (1).
Once all items in the Event Queue are processed, the Event Loop blocks on the Event Demultiplexer, triggering another cycle when a new event is available.
The asynchronous behavior emerges clearly. The application expresses its interest in accessing a resource without blocking, and it provides a handler, which will be invoked when the operation is complete.

Node.js capitalizes on this asynchronous pattern, contributing to its remarkable speed and efficiency.

In Conclusion:
Node.js has rightfully earned its popularity by leveraging its asynchronous nature and non-blocking IO capabilities to achieve unparalleled speed and scalability. The combination of event demultiplexing and the reactor pattern forms the core of Node.js, enabling it to handle multiple concurrent requests with remarkable efficiency.

I hope you found this article enlightening. Please consider sharing it and showing your appreciation with a clap!

resource-Node.js Design Patterns — Third Edition Mario Casciaro, Luciano Mammino

Everything You Need To Know About Node.js Modules

vikas mishra — Mon, 01 May 2023 05:41:07 +0000

Modules are small chunks of code or we can say — “ Module divides the codebase into small units, which can be used everywhere in the application”. Other programming languages also have their own module system like Java, Go, and PHP; it’s called Package; in Ruby it’s Unit.

Node.js currently comes with 2 different modules systems

1.Commonjs (CJS)

2.ECMAScript modules (ESM or ES modules)

The need for modules :

1.Having a way to split the codebase into multiple files.

Allowing code reuse across different projects.
Encapsulation (or information hiding). It is generally a good idea to hide implementation complexity and only expose simple interfaces with clear responsibilities.
Managing dependencies. A good module system should make it easy for module developers to build on top of existing modules, including third-party ones.

We can discuss more the 2 types of modules in Node.js, but for now, let’s see how we can use the module system.

There are 2 main concepts of module system —

“require” is a function that allows you to import a module from the local filesystem
“exports” and “module.exports” are special variables that can be used to export public functionality from the current module

Note — At this point, we are not comparing the 2 modules. We just trying to understand the basic things.

There are some popular patterns for defining the modules and exporting them. By exporting a module, it is available throughout the application.

Let’s have a look at these patterns —

Named Exports:

The most basic concept is to expose a public API is using name export. Let’s take a look on the below code.

exports.info = (message) => { console.log(info: ${message}) } exports.verbose = (message) => { console.log(verbose: ${message}) }

Here we can see, we are exporting a function by giving it one name like info and verbose. The exported function is now available. We can use them like-

const logger = require(‘./logger’) logger.info(‘This is an informational message’) logger.verbose(‘This is a verbose message’)

This method allows us to export everything from the module. It makes API as public so everyone can all methods. So we can conclude, It should be used when we want all methods public. Now let’s move on to the next pattern.

Exporting a Function:

One of the most popular module definition patterns consists of reassigning the whole module.exports variable to a function. The main strength of this pattern is the fact that it allows you to expose only a single functionality, which provides a clear entry point for the module, making it simpler to understand and use; it also honors the principle of a small surface area very well. This way of defining modules is also known in the community as the substack pattern.

module.exports = (message) => { console.log(info: ${message}) }

This is a very powerful combination because it still gives the module the clarity of a single entry point (the main exported function) and at the same time it allows us to expose other functionalities that have secondary or more advanced use cases.

module.exports.verbose = (message) => { console.log(verbose: ${message}) }

This code demonstrates how to use the module that we just defined:

const logger = require('./logger') logger('This is an informational message') logger.verbose('This is a verbose message')

Exporting a Class:

A module that exports a class is a specialization of a module that exports a function. A module that exports a class is a specialization of a module that exports a function.

class Logger { constructor (name) { this.name = name } log (message) { console.log([${this.name}] ${message}) } info (message) { this.log(info: ${message}) } verbose (message) { this.log(verbose: ${message}) } } module.exports = Logger

And, we can use the preceding module as follows:

const Logger = require('./logger') const dbLogger = new Logger('DB') dbLogger.info('This is an informational message') const accessLogger = new Logger('ACCESS') accessLogger.verbose('This is a verbose message')
Exporting a class still provides a single entry point for the module, but compared to the substack pattern, it exposes a lot more of the module internals. On the other hand, it allows much more power when it comes to extending its functionality.

Exporting an instance:
Instead of exporting a new class, we can expose its instance also.

class Logger { constructor (name) { this.count = 0 this.name = name } log (message) { this.count++ console.log('[' + this.name + '] ' + message) } } module.exports = new Logger('DEFAULT')

This newly defined module can then be used as follows:

const logger = require('./logger') logger.log('This is an informational message')

One interesting detail of this pattern is that it does not preclude the opportunity to create new instances, even if we are not explicitly exporting the class. In fact, we can rely on the constructor property of the exported instance to construct a new instance of the same type:

const customLogger = new logger.constructor('CUSTOM') customLogger.log('This is an informational message')

As you can see, by using logger.constructor(), we can instantiate new Logger objects. Note that this technique must be used with caution or avoided altogether. Consider that, if the module author decided not to export the class explicitly, they probably wanted to keep this class private.

Conclusion:

We have covered all types of exporting patterns provided by Node.js. The best one we can use all depends on our requirements and application architecture.

I hope you will find these article useful. Give it some claps to make others find it too!

Node.js: Promise In Depth

vikas mishra — Thu, 27 Apr 2023 05:51:34 +0000

All of us know about promises. They are improvements to lower-level building blocks of Node.js and are widely used by programmers. As programmers, we should think about the readability of our code. This is the most important feature of a promise. They made the code more readable.

In this article, we will learn more about the features of the Promise library and their advantages. Let’s start with the callbacks-

Callbacks:
We have seen many definitions of callbacks, like “A callback is a function that is passed to another function “. In Node.js, a callback's definition is based on its asynchronous nature.

“The most basic mechanism to notify the completion of asynchronous function is called callback”.

There are certain disadvantages of callback like-

Callback hell
Pyramid Problem
Closure and Parameters Renaming
Error Handling

Let’s have a look at the callback hell problem first. At times, we want to execute our code after the completion of another task. In programming, this is called the sequential execution (asynchronous) of tasks.

At this stage, I assume we are familiar with the basic structure of the callback function. Let’s check the below example -

async1((err,data) =>{
    async2((err,data)=> {
      async3((err,data)=> {  
    //...     })  
 }) 
})

Here we are passing the execution result of one function to another function, like the sequential execution of tasks. This leads our code into an unreadable and unmanageable blob known as callback hell. You can see how code written in this way assumes the shape of a pyramid due to deep nesting, and that’s why it is also colloquially known as the "pyramid of doom."

Another very important part is to check if we get an error in any of the results; it needs to be passed further in the application. A serial execution flow seems needlessly complicated and error-prone. If we forget to forward an error, then it just gets lost, and if we forget to catch any exception thrown by some synchronous code, then the program crashes. This is called a major error handling problem with callbacks.

Promises:
As you can see, the most basic problem here is the readability of the code. Now to solve this problem, the JavaScript developers came up with a library that they called Promise A+.

Promises are part of the ECMAScript 2015 standard (or ES6, which is why they are also called ES6 promises) and have been natively available in Node.js since version 4. But the history of promises goes back a few years earlier, when there were dozens of implementations around, initially with different features and behavior. Eventually, the majority of those implementations settled on a standard called Promises/A+.

In simple words, we can say “The first step toward a better asynchronous code experience is the promise, an object that “carries” the status and the eventual result of an asynchronous operation ”.

We will go into more details about Promise from here-

To get an idea of how promises can transform our code, let’s consider the following callback-based code:

asyncOperation(arg, (err, result) => {
   if(err) 
    {     
      // handle the error   
    } 
  // do stuff with the result 
})

Promises allow us to transform this typical continuation-passing style code into a better structured and more elegant one, such as the following:

asyncOperationPromise(arg)   
.then(result => {     
   // do stuff with result 
 },
 err => {    
   // handle the error  
 })

In the code above, asyncOperationPromise() is returningPromise, which we can then use to receive the fulfillment value or the rejection reason of the eventual result of the function. The most impotent part of the promise is, we can pass the result of one operation to another one like -


asyncOperationPromise(arg)  
 .then(result1 => {
     // returns another promise
    return asyncOperationPromise(arg2) 
  })
   .then(result2 => {
     // returns a value   
    return 'done'   
   })
   .then(undefined, err => { 
    // any error in the chain is caught here 
  })

We can see the above code is more readable as compared to the nested callback. We are doing the same sequential execution of tasks here also. This is the simplest form of writing a promise in Node.js, but to do it better, JavaScript provides a native solution, which they call the Promise API.

The promise API:

new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve(new Date())
    }, milliseconds)
  })

This is just an overview to give you an idea of what we can do with promises.

The promise constructor (new Promise((resolve, reject) => )) creates a new promise instance that fulfills or rejects based on the behavior of the function provided as an argument. The function provided to the constructor will receive two arguments:

resolve(obj): This is a function that, when invoked, will fulfill the promise with the provided fulfillment value, which will be obj if obj is a value. It will be the fulfillment value of obj if obj is a promise or a thenable.
reject(err): This rejects the promise with the reason err. It is a convention for err to be an instance of Error.
Creating a promise:
Let’s now see how we can create a promise using its constructor. Creating a promise from scratch is a low-level operation, and it's usually required when we need to convert an API that uses another asynchronous style (such as a callback-based style). Most of the time, we—as developers—are consumers of promises produced by other libraries, and most of the promises we create will come from the then() method. Nonetheless, in some advanced scenarios, we need to manually create a Promise using its constructor.

To demonstrate how to use the Promise constructor, let's create a function that returns a Promise that fulfills with the current date after a specified number of milliseconds. Let's take a look at it:

function delay (milliseconds) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve(new Date())
    }, milliseconds)
  })
}

As you probably already guessed, we used setTimeout to invoke the resolve function of the Promise constructor. We can notice how the entire body of the function is wrapped by the Promise constructor; this is a frequent code pattern you will see when creating a Promise from scratch.

The delay() function we just created can then be used with some code like the following:

console.log(`Delaying...${new Date().getSeconds()}s`)
delay(1000)
  .then(newDate => {
    console.log(`Done ${newDate.getSeconds()}s`)
  })

If any error is thrown by code or the system, we need to catch them, but it is much simpler than what we did in the callback pattern.

Now comes the best part. If an exception is thrown (using the throw statement), the promise returned by the then() method will automatically be rejected, with the exception that was thrown being provided as the rejection reason. This is a tremendous advantage over the callback error handling we saw earlier, as it means that with promises, exceptions will propagate automatically across the chain.

Promises with Async/await:

The promises are the best way to solve problems like callback hell and the pyramid of doom, but they are still the suboptimal solution when it comes to writing sequential asynchronous code. We need to invoke then() and create a new function for each task in the chain. This is still too much for a control flow that is definitely the most commonly used in everyday programming. JavaScript needed a proper way to deal with the ubiquitous asynchronous sequential execution flow, and the answer arrived with the introduction in the ECMAScript standard of async functions and the await expression (async/await for short)

The async/await dichotomy allows us to write functions that appear to block at each asynchronous operation, waiting for the results before continuing with the following statement. As we will see, any asynchronous code using async/await has a readability comparable to traditional synchronous code.

Today, async/await is the recommended construct for dealing with asynchronous code in both Node.js and JavaScript. However, async/await does not replace all that we have learned so far about asynchronous control flow patterns; on the contrary, as we will see, async/await piggybacks heavily onto promise

Now lets take a example of the async/await-

function delay (milliseconds) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve(new Date())
    }, milliseconds)
  })
} 
async function playingWithDelays () { 
  console.log('Delaying...', new Date())  
  const dateAfterOneSecond = await delay(1000)
  console.log(dateAfterOneSecond)  
  const dateAfterThreeSeconds = await delay(3000)
  console.log(dateAfterThreeSeconds)   return 'done' 
}

As we can see from the previous function, async/await seems to work like magic. The code doesn’t even look like it contains any asynchronous operations. However, don’t be mistaken; this function does not run synchronously (they are called async functions for a reason!). At each await expression, the execution of the function is put on hold, its state is saved, and control is returned to the event loop. Once the promise that has been awaited resolves, control is given back to the async function, returning the fulfillment value of the promise.

Error handling with async/await:
Async/await doesn’t just improve the readability of asynchronous code under standard conditions, but it also helps when handling errors. In fact, one of the biggest gains of async/await is the ability to normalize the behavior of the try/catch block and make it work seamlessly with both synchronous throws and asynchronous Promise rejections. Let's demonstrate that with an example.

A unified try…catch experience
Let’s define a function that returns a Promise that rejects with an error after a given number of milliseconds. This is very similar to the delay() function that we already know very well:

function delayError (milliseconds) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      reject(new Error(`Error after ${milliseconds}ms`))
    }, milliseconds)
  })
}

Next, let’s implement an async function that can throw an error synchronously or await a Promise that will reject. This function demonstrates how both the synchronous throw and the promise rejection are caught by the same catch block:


async function playingWithErrors (throwSyncError) {
  try {
    if (throwSyncError) {
      throw new Error('This is a synchronous error')
    }
    await delayError(1000)
  } catch (err) {
    console.error(`We have an error: ${err.message}`)
  } finally {
    console.log('Done')
  }
}

Now, error handling is just as it should be: simple, readable, and, most importantly, supporting both synchronous and asynchronous errors.

Above, we have covered all the important scenarios related to the promise. I hope you will find these articles useful. Give it some claps to make others find it too!

If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇