Skip to main content

Node.js v14 Features: Async Local Storage

Node.js 14 is out now, and with that release, it brings in Async Local Storage support. Now that might sound like "meh, okay, local storage has been around for some time", but this time, it's different.

For starters, this is the Node runtime we're talking about and not the browser. Thus, having a "localStorage" browser-like concept doesn't really make sense for Node. And the fact is, it is not the localStorage you're probably thinking of either. So what is it then?

Introducing Async Local Storage - Storage for asynchronous tasks

Consider a web server like Apache running PHP for hosting a website. When PHP receives a request from a client - your web server makes sure to spin off a new thread, and let that thread manage all the resources, local variables, function call stack, etc. for that particular request. Simple and easy. But the problem arises with JavaScript.

JavaScript is single threaded - that means you cannot have multiple threads of JS running together under a same parent process. But don't let it fool you, JS is as fast (even faster) as mature solutions like Java backend in handling web server requests. How does that happen? Well, that's something for another article, but the important thing here is that Node is single threaded, hence you do not have the benefits of thread local storage. Thread local storage is nothing but variables and functions local to a particular thread - in our case, for handling a particular user on the webpage.

Why is single thread a problem?

Single thread is a problem in this case as Node would keep executing synchronous code in one go as long as it doesn't exhaust all synchronous operations in the event loop. Then it'll keep a check on events and callbacks and execute that code whenever necessary. In Node, a simple HTTP request is nothing but an event fired by the http library to the node to handle the request - hence it is asynchronous. Now let's say you want to associate some data with this asynchronous operation. How would you do that?

Well, you can create some sort of "global" variable and assign your special data in it. Then, when another request comes from the same user, you can use the global variable to read whatever you had stored earlier. But it would spectacularly fail when you have more than 1 request on hand as now Node would not execute asynchronous code serially (of course, that's the definition of asynchronous!). Let's consider this dummy code (assume Node runtime):

server.listen(1337).on('request', (req) => {
  // some synchronous operation (save state)
  // some asynchronous operation
  // some asynchronous operation
})

Consider this sequence of events:

  1. User 1 hits the server on port 1337
  2. Node starts running the synchronous operation code
  3. While node was running that synchronous code, another User 2 hits the server.
  4. Node would keep on executing the synchronous code, meanwhile the request to process the second HTTP request is waiting in the task queue.
  5. When Node finishes synchronous operation part, and comes to asynchronous operation part, it throws it off in the task queue and then starts processing the first task sitting in the taskqueue - the second HTTP request.
  6. This time it's running that synchronous piece of code, but on the behalf of User 2 request. When that synchronous code for User 2 is done, it resumes the asynchronous execution of User 1, and so on.

Now what if you want to persist specific data with that specific user whenever the asynchronous code specific to them is being called? Here's when you use AsyncStorage - storage for asynchronous flows in Node.

Consider this example straight from the official docs:

const http = require('http');
const { AsyncLocalStorage } = require('async_hooks');

const asyncLocalStorage = new AsyncLocalStorage();

function logWithId(msg) {
  const id = asyncLocalStorage.getStore();
  console.log(`${id !== undefined ? id : '-'}:`, msg);
}

let idSeq = 0;
http.createServer((req, res) => {
  asyncLocalStorage.run(idSeq++, () => {
    logWithId('start');
    // Imagine any chain of async operations here
    setImmediate(() => {
      logWithId('finish');
      res.end();
    });
  });
}).listen(8080);

http.get('http://localhost:8080');
http.get('http://localhost:8080');
// Prints:
//   0: start
//   1: start
//   0: finish
//   1: finish

This example is showing nothing but the "stickyness" of the idSeq with the respective request. You can imagine how express populates "req.session" object with correct user everytime, in a similar fasion, this is a low level API using a lower level construct in Node called async_hooks which is still experimental, but is pretty cool to know!

Performance

Before you jump on to roll this out in production, beware that this is not something which I would really recommend anybody out there if not absolutely crazily needed. This is because it comes with a non-negligible performance hit on your application. This is primarily because the underlying API of async_hooks is still a WIP, and the situation should improve gradually.

Conclusion

That's basically it! A very simple brief introduction to what AsyncStorage is in Node 14 and what's the high level overall idea for it.

Peace!

Comments

Popular posts from this blog

4 Ways to Communicate Across Browser Tabs in Realtime

1. Local Storage Events You might have already used LocalStorage, which is accessible across Tabs within the same application origin. But do you know that it also supports events? You can use this feature to communicate across Browser Tabs, where other Tabs will receive the event once the storage is updated. For example, let’s say in one Tab, we execute the following JavaScript code. window.localStorage.setItem("loggedIn", "true"); The other Tabs which listen to the event will receive it, as shown below. window.addEventListener('storage', (event) => { if (event.storageArea != localStorage) return; if (event.key === 'loggedIn') { // Do something with event.newValue } }); 2. Broadcast Channel API The Broadcast Channel API allows communication between Tabs, Windows, Frames, Iframes, and  Web Workers . One Tab can create and post to a channel as follows. const channel = new BroadcastChannel('app-data'); channel.postMessage(data); And oth...

Certbot SSL configuration in ubuntu

  Introduction Let’s Encrypt is a Certificate Authority (CA) that provides an easy way to obtain and install free  TLS/SSL certificates , thereby enabling encrypted HTTPS on web servers. It simplifies the process by providing a software client, Certbot, that attempts to automate most (if not all) of the required steps. Currently, the entire process of obtaining and installing a certificate is fully automated on both Apache and Nginx. In this tutorial, you will use Certbot to obtain a free SSL certificate for Apache on Ubuntu 18.04 and set up your certificate to renew automatically. This tutorial will use a separate Apache virtual host file instead of the default configuration file.  We recommend  creating new Apache virtual host files for each domain because it helps to avoid common mistakes and maintains the default files as a fallback configuration. Prerequisites To follow this tutorial, you will need: One Ubuntu 18.04 server set up by following this  initial ...

Working with Node.js streams

  Introduction Streams are one of the major features that most Node.js applications rely on, especially when handling HTTP requests, reading/writing files, and making socket communications. Streams are very predictable since we can always expect data, error, and end events when using streams. This article will teach Node developers how to use streams to efficiently handle large amounts of data. This is a typical real-world challenge faced by Node developers when they have to deal with a large data source, and it may not be feasible to process this data all at once. This article will cover the following topics: Types of streams When to adopt Node.js streams Batching Composing streams in Node.js Transforming data with transform streams Piping streams Error handling Node.js streams Types of streams The following are four main types of streams in Node.js: Readable streams: The readable stream is responsible for reading data from a source file Writable streams: The writable stream is re...