Perhaps you've heard something about writable streams or even used them. But there is always a fine line between "I kind of understand how they work" and "I understand how they work".

After reading this article, you should be confident enough to use writable streams confidently.

What are Writable Streams?

As the name suggests, writable streams are meant to write some data to the destination. There is a lot to unpack in this statement.

First, what data do we pass to the writable stream and, where does it come from? It can be anything that JavaScript has access to. For example, if you create a string in a JavaScript application and save it as a variable, you can access it directly.

const name = 'John';

// We can get the name value right away
console.log(name);

However, the data that you want to work with is not always accessible right away. You must make the data accessible for JavaScript first, and only then can you use it.

import { createReadStream } from 'node:fs';

const stream = createReadStream('file-name.txt');

stream.on('data', (chunk) => {

    // Now we have access to the data from the file
});

In this example, the data we want to work with is inside the file-name.txt file. This file resides on the file system and, JavaScript doesn't have direct access to it. That's why we first need to make the file data available in JavaScript using the createReadStream function.

If you're not comfortable with the readable streams yet, check out the previous article to better understand the readable streams.

Okay, the part about data we write into the stream should be clear now. The next question is, what is the destination, and what does it mean that stream writes data into the destination?

The destination can be anything:

• Database

• Network socket

• File

• S3 cloud storage

• Standard output

• Other streams

• JavaScript structures like arrays and objects

The last point doesn't make much sense, but you get the idea. The destination can be virtually anything.

This model looks similar to readable streams in the sense that we have 3 main parts involved:

• The data

• The stream

• The destination

The difference is that readable streams can get data from anywhere into your JavaScript application, and writable streams can write data anywhere from the data that is available in your application.

Writing data to the destination of Writable Stream

We use the write method to write data to the destination.

Here is how it works:

import { createWriteStream } from 'node:fs';

const writableStream = createWriteStream('input.txt');

writableStream.write('Hello World!');

In this example, we create a writable stream with the destination input.txt file. Whenever we try to write something inside that stream, it gets transferred into the input.txt file.

After calling the write method, we can go to the input.txt file and see that it now contains Hello World! text.

Note: When writing data to a stream, you have to be aware of the backpressure mechanism. It prevents memory overflow by controlling the rate at which data is written into the stream. You'll learn more about it in the upcoming article where we dive deep into how backpressure works in writable streams.

While it might look OK to work with the write method manually, imagine if we were to have a bit more complicated setup.

import { createReadStream, createWriteStream } from 'node:fs';
import { S3WritableStream } from 'utils/s3-writable-stream';

const s3WritableStream = new S3WritableStream('s3-destination-url');
const readableStream = createReadStream('input.txt');

readableStream.on('data', (chunk) => {
    s3WritableStream.write(chunk);
});

Doesn't look too bad so far, right? Now, let's factor in that we have to handle errors and cleanups for each stream properly.

import { createReadStream, createWriteStream } from 'node:fs';
import { S3WritableStream } from 'utils/s3-writable-stream';

const s3WritableStream = new S3WritableStream('s3-destination-url');
const readableStream = createReadStream('input.txt');

readableStream.on('data', (chunk) => {
    s3WritableStream.write(chunk);
});

s3WritableStream.on('error', () => {
    // Clean up the resources related to the stream.
    // Perhaps you want to close the other streams at this point.
});

readableStream.on('error', () => {
    // Clean up the resources related to the stream.
    // Perhaps you want to close the other streams at this point.
});

As you can see, if we start building more-or-less production-grade applications, we have to think about proper error handling and resource cleanups.

When it comes to this, working with multiple streams by calling the write method becomes way too verbose and repetitive. There is a better way to do it, and it is by building data flows using functions like pipeline and pipe.

But before diving into the data flows, I want to address the strange-looking writable stream that is used in the code examples named S3WritableStream.

Creating a custom writable stream

This strange-looking stream is a custom writable stream. It is created to handle a specific pattern of using a writable stream.

In our case, the S3WritableStream is designed to handle the write operation into the S3 bucket.

We don't need to write all of the connection and authentication logic. The custom stream handles all of it. The only thing we need to specify is a URL where we want to store the data.

The benefit of such custom streams is the same as creating a function, class, or any other reusable unit - we encapsulate the complex logic of handling S3 workflow inside of the stream and can reuse it across the project later on.

Here is what pseudo implementation of S3WritableStream might look like:

import { Writable } from 'node:stream';

class S3WritableStream extends Writable {
    #url

    constructor(url) {
        super();

        this.#url = url;
    }

    _write(chunk, encoding, callback) {
        // Logic to write data into the S3 bucket
    }

    _final(callback) {
        // Logic to finalize the stream workflow
    }

    _destroy(error, callback) {
        // Handle the destroy even by cleaning up resources
        // and the error.
    }
}

We can encapsulate a lot of low-level details in a custom stream abstraction.

While custom streams can significantly simplify a particular type of workflow, we still have to think about combining multiple streams properly to build a data flow.

Building data flows with Writable Streams

Writable streams are powerful, but they get to the next level when we start building data flows(aka pipelines) using them.

For example, we can combine readable and writable streams into a single pipeline. By doing that, data from the readable stream gets automatically transferred into a writable stream.

Here is a simple example of piping two streams.

import { createReadStream, createWriteStream } from 'node:fs';

const readableStream = createReadStream('input.txt');
const writableStream = createWriteStream('output.txt');

readableStream.pipe(writableStream);

Here, we call the pipe method of a readable stream and pass the writable stream as the destination where the data should be forwarded.

No need to listen for data events on the readable stream and call write in a callback.

We can achieve almost the same result using the pipeline function.

import { createReadStream, createWriteStream } from 'node:fs';
import { pipeline } from 'node:stream';


const readableStream = createReadStream('input.txt');
const writableStream = createWriteStream('output.txt');

pipeline(readableStream, writableStream);

What is the difference between them? Why do we need to have multiple functions that are doing the same thing? While they might look similar there is huge difference, let's get into more details.

pipe doesn't have a promise-base API

At this point, promises are the standard for working with asynchronous operations in Node.js.

It is way more convenient to use async/away syntax whenever possible. Thanks to it, we can read async code as a series of synchronous operations.

Because of that it is way easier to track the logic flow compared to events.

import { createReadStream, createWriteStream } from 'node:fs';

const readableStream = createReadStream('input.txt');
const writableStream = createWriteStream('output.txt');

readableStream.pipe(writableStream);

console.log('Operation finished');

In the case of using, pipe we'll see the console log output first, and only then the operation will finish.

Compare it to using the pipeline function with promises API.

import { createReadStream, createWriteStream } from 'node:fs';
import { pipeline } from 'node:stream/promises';

const readableStream = createReadStream('input.txt');
const writableStream = createWriteStream('output.txt');

await pipeline(readableStream, writableStream);

console.log('Operation finished');

Poor error handling by pipe method

When working with streams, you shouldn't forget about proper error handling.

Both pipe and pipeline can handle errors, but the way they do it differs significantly.

readableStream
    .pipe(transformStream)
    .pipe(writableStream)
    .on('error', (e) => {
        // Handle the error
    });

The biggest catch here is that on('error') it only catches errors from the writableStream (the last one on the chain).

If you want to handle errors properly for each of the streams, you have to add error listeners for each of the streams involved in the pipeline.

readableStream
    .on('error', (e) => {
        // Handle error
    })
    .pipe(transformStream)
    .on('error', (e) => {
        // Handle error
    })
    .pipe(writableStream)
    .on('error', (e) => {
        // Handle the error
    });

Doesn't look too nice. Now let's compare it with pipeline API.

try {
    await pipeline(
        readableStream,
        transformStream,
        writableStream
    )
} catch (error) {
    // Handle error
}

Unlike pipe the pipeline function is able to handle errors for each of the streams involved in the pipeline. How cool is that?

The pipe method doesn't clean up resources properly

You probably noticed that we're here to roast the pipe method.

The next problem it has is the absence of a proper mechanism to clean up resources.

It means that if we have a stream involved in a pipeline and some other stream in the pipeline errors out, the pipe method doesn't close other streams automatically leaving them and their resources handing in the memory.

// Using pipe() - resources aren't properly cleaned up
const transform = new Transform({
  transform(chunk, encoding, callback) {
    if (someCondition) {
      callback(new Error('Something went wrong'));
      // Other streams in the pipeline stay open!
      return;
    }
    callback(null, chunk);
  }
});

transform.on('error', (error) => {

    // Have to manually clean up streams.
    writableStream.destroy();
    readableStream.destroy();
})

readableStream
  .pipe(transform)
  .pipe(writableStream);

You need to track suck cases when working with pipe and always clean up resources involved in the pipeline manually for every possible error inside of the pipeline.

On the other hand, pipeline the function handles it automatically.

// Using pipeline() - automatic cleanup of all resources
try {
  await pipeline(
    readableStream,
    transform,
    writableStream
  );
} catch (error) {
  console.error('Error:', error);
  // All streams are automatically destroyed
  // No memory leaks or hanging resources
}

Conclusion

Writable streams are responsible for getting data from your Node.js application and transferring it to a destination that often lies outside of your application.

We have several ways of writing data into the writable stream. The most fundamental one is write method that we call in a writable stream and pass the data to be written as an argument.

We can customize the behavior of how exactly write and other methods of a writable stream works by creating a custom stream and extending it from the Writable class.

But even having a custom writable stream won't help us to solve the problem of building complex data flows where we want to transfer data from one source to another without much hustle. That's where pipe and pipeline functions come in handy.

While both pipe and pipeline functions have the same end goal to build pipelines of data, the implementation details are quite different when using them.

In general, pipeline has a much simpler API and handles errors and resources cleanup way better compared to pipe. Most of the time, you should stick with the pipeline.

But do you know how to use it effectively? This question of efficiency comes when we're dealing with cases that go beyond basics. In such cases, a deeper understanding of the underlying mechanisms is important for making informed decisions.

This article explores the core concepts of Node.js Readable streams. After reading it you'll deepen your understanding how they work and when they can be used. As a bonus point, we'll see why you should be careful when playing with the highWaterMark property of readable streams.

Use cases of readable streams

Here are few examples of of readable streams can be used.

Streaming data from database

If we have a large dataset in a database or each single document is large by itself, we might want to stream documents from the database, instead of trying to load all them into memory at once.

Here is an example of we can do so by using `Readable` stream and MongoDB.

import { Readable } from 'node:stream'; 

// Leaving behind the scene all MongoDB configuration and connection setup
// before getting the actual reference to `db` object.

// Collection cursor
const cursor = db.collection('documents').cursor();
const collectionStream = new Readable({
  objectMode: true,

  // We're streaming objects, not buffers
  async read(size) {
    try {
      const result = await cursor.next();
      if (result) {
        this.push(result);
      } else {
        this.push(null); // Signal the end of the stream
        await client.close();
      }
    } catch (err) {
      this.destroy(err); // Handle errors by destroying the stream
    }
  },
});

And after that we can use it in the following way:

collectionStream.on('data', (doc) => {
  // Process the document
});

Diagram of the workflow.

sequenceDiagram
    Client->>Readable Stream: Subscribes to the stream
    Readable Stream->>Database: Reads data from the cursor
    Database->>Readable Stream: Cursor returns document
    Readable Stream->>Client: Returns document recieved from the cursor

Streaming file from S3 bucket directly into the application

Most of applications have some kind of workflow that involves files. Often, it is made by leveraging cloud storage services like AWS S3.

If at some point you need to download a file from S3 and process it in your application, Readable streams are one of the best options to do so.

import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3';

// Configure AWS credentials and region
const s3Client = new S3Client({
  region: 'YOUR_AWS_REGION',
  credentials: {
    accessKeyId: 'YOUR_ACCESS_KEY_ID',
    secretAccessKey: 'YOUR_SECRET_ACCESS_KEY',
  },
});

const command = new GetObjectCommand({
  Bucket: 'my-bucket',
  Key: 'path/to/file.txt',
});
const response = await s3Client.send(command);
const s3Stream = response.Body;

s3Stream.on('data', (chunk) => {
  // Process the data chunk
});

This approach makes the process of downloading files from S3 more efficient since we're not waiting for the whole file to be transferred through the network.

sequenceDiagram
    Client->>Readable Stream: Subscribes to the stream
    Readable Stream->>S3 bucket: Reads a file from the bucket
    S3 bucket->>Readable Stream: Start transferring the file
    Readable Stream->>Client: Returns file chuncks as soon as they are available

Zlib compression and decompression

As Node.js documentation states:

Compression and decompression are built around the Node.js Streams API.

Meaning that by using zlib API, you're working with streams. You can find the following example in the official Node.js documentation.

import { createGzip } from 'node:zlib';
import { pipeline } from 'node:stream';
import { createReadStream, createWriteStream } from 'node:stream';

const gzip = createGzip();
const source = createReadStream('input.txt');
const destination = createWriteStream('input.txt.gz');

pipeline(source, gzip, destination, (err) => {
  // Handle the error
});

There are other Node.js APIs and modules that leverage the readable streams:

• TCP Socket

• HTTP request and response

• Process sdtin and stderr

Now that we've explored some common use cases, let's dive deeper in how readable streams work under the hood and learn about different reading modes and flowing states.

Reading modes and flowing states

Every readable stream in Node.js operates in one of two modes: flowing or paused. These modes dictate how you receive data from a readable stream, much like how you might control water flow in a plumbing system.

P.S. If you're not familiar with the analogy of pipes and plumbing system, check out the previous article where we build a mental model of how streams work in Node.js using the pipe analogy.

Flowing mode: The automatic approach

In flowing mode, data is read from the underlying system automatically and provided to your application as quickly as possible. This is similar to water flowing freely through an open pipe. One way to turn the flowing mode on is to attach the `data` event listener to the stream:

import { createReadStream } from 'node:fs';

const filePath = 'path/to/a/file.txt';
const stream = createReadStream(filePath);

// Once we attach this listener, data starts flowing automatically
stream.on('data', (chunk) => {
  // Process the data chunk
});

This approach is perfect for scenarios where you want to process data as quickly as possible, such as streaming log files or processing real-time data.

Paused mode: The manual approach

In paused mode, you control the flow of data. One way to explicitly request each chunk of data is by using the `stream.read()` method. Think of paused mode like a water dispenser with a button; you press the button only when you want water.

import { createReadStream } from 'node:fs';

const filePath = 'path/to/a/file.txt';
const stream = createReadStream(filePath);

// Later in your code, when you need to read data
const chunk = stream.read();

if (chunk !== null) {
  // Process the data chunk
}

Warning, don't try to mix these two modes. It will lead to unexpected behavior that is hard to debug.

Readable flowing states

These two reading modes are a simplified view of the underlying abstraction that Node.js operates with, called the readable flowing state. This state is represented by the readableFlowing property of the readable stream.

The readableFlowing state can contain one of three values: `null`, `false`, and `true`.

Null: The initial state of a newly created stream. No consumers are attached to the stream, so it's not actively reading data.

import { Readable } from 'node:stream';
const stream = new Readable({ read(size) {} });

console.log(stream.readableFlowing); // null

False (Paused): The stream has consumers but is temporarily paused. Data might be available but won't be delivered until the stream is resumed. This is common when using pause() or switching to manual mode.

stream.on('data', (chunk) => {
  // Handle data
});

stream.pause(); // Enters paused state

console.log(stream.readableFlowing); // false

True (Flowing): The stream is actively delivering data to consumers. Data events are being emitted automatically. This is common when using event-based consumption.

stream.on('data', chunk => {
  // Handle data
});
// Enters flowing state

console.log(stream.readableFlowing); // true

Warning, don't try to mix these three states. It will lead to unexpected behavior that is hard to debug.

Consuming readable streams data

The sole purpose of a readable stream is to deliver data to consumers. In Node.js, there are several ways to consume data from a readable stream, each with its own characteristics and use cases.

In this article we'll review only methods that we can use when dealing with a single readable stream such as data event, readable event, and async iterators. In later articles we'll get familiar with pipe and pipeline functions.

Using the `data` event

This is probably the most common approach of consuming data from a readable stream. All we have to do is to attach an event listener to `data` event.

import { createReadStream } from 'node:fs';

const stream = createReadStream(
  'path/to/a/file/text.txt',
  { encoding: 'utf8' },
);

stream.on('data', (chunk) => {
  // Process the data chunk
});

Whenever the internal buffer is filled with data the readable stream offloads this data into the chunk and you receive it in the callback.

And it happens no matter what. For example, if you have some asynchronous processing of the data chunks it might not be ideal for you.

import { createReadStream } from 'node:fs';

const stream = createReadStream(
  'path/to/a/file/text.txt',
  { encoding: 'utf8' },
);

stream.on('data', async (chunk) => {

  // Imitation of data processing.
  await new Promise((resolve) => setTimeout(resolve, 3000));
  console.log('Data chunk: ', chunk);
});

In this example you'll see most of the console logs pretty much at the same time. The reason is after the buffer gets empty streams starts reading a new chunk of data and it doesn't matter if a processing of a previous hasn't been finished yet.

Using the readable event

The `readable` event is somewhat similar to `data` event in a way that it invoked when the internal buffer of the readable stream is filled with the data.

However, the handler of the `readable` doesn't offload the buffer automatically. It only gives a signal to a listener that internal buffer is loaded and ready to be ridden. To explicitly read from an internal buffer you can use the `read` method.

import { createReadStream } from 'node:fs';

const stream = createReadStream(
  'path/to/a/file/text.txt',
  { encoding: 'utf8' },
);

// When stream emits the event it means that the internal buffer is filled with the data
stream.on('readable', () => {

  // We have to read the data manually using the `read` method
  const chunk = stream.read();

  // Process data chunk;
});

Here is a diagram to better show you how data flows to buffer and from buffer when dealing with the `readable` event.

As you can see, the buffer is still filled with data after event fired.

Such manual handling of when we read the data can be quite handy when you want to control the data flow explicitly. For example, you can read the stream data only after some asynchronous processing has finished the work.

import { createReadStream } from 'node:fs';

const stream = createReadStream(
  'path/to/a/file/text.txt',
  { encoding: 'utf8' },
);

stream.on('readable', async () => {
  await new Promise((resolve) => setTimeout(resolve, 3000));
  const chunk = stream.read();
  console.log('Readable chunk: ', chunk);
});

In this example you'll see console logs print one by one with an interval of approximately 3 seconds.

Using async iterator

Readable streams implement async iterator interface. It is the most recent API for consuming streams and you can find that members of the core Node.js team recommend using it over `data` or `readable` events most of the time.

The benefit of working with async iterator is that you don't have to deal with any events by yourself. Everything is handled internally.

import { createReadStream } from 'node:fs';

const stream = createReadStream(
  `${import.meta.dirname}/new-text.txt`,
  { encoding: 'utf8' },
);

for await (const chunk of stream) {
  // Process the data chunk
}

We're using `for...await` loop to iterate over the data that stream emits.

This approach has the best from both `data` and `readable` events combined into a single API. We receive the chunk of data whenever it is ready and don't have to call the `read` method manually as we do it with the `readable` event.

At the same time, we can perform some asynchronous handling of each chunk and async iterator won't be rushing to read all of the data as `data` event do. It will wait until the processing on a single chunk is finished and only then move forward.

You know at least 3 different ways to consume data from a readable stream now. The other thing that can affect how fast you're getting data from a stream is `highWaterMark` property.

Impact of ‘highWaterMark’ on readable streams performance

While the Node.js documentation states that streams in flowing mode emit data as quickly as possible, there's a nuance to this behavior. Data is emitted only after an internal buffer is filled. This buffer size is controlled by the `highWaterMark` property of the stream.

If you set a smaller `highWaterMark` value, the first chunk will be emitted faster because the buffer fills up more quickly. However, this doesn't necessarily mean the overall execution time will be faster. In fact, for larger files, a smaller `highWaterMark` can lead to slower processing time.

import { createReadStream } from 'node:fs';

const filePath = 'data.txt';

// Stream with a small highWaterMark
const stream1 = createReadStream(filePath, { highWaterMark: 16 });

// The first chunk is emitted faster, but the overall processing is slower
stream1.on('data', (chunk) => {
  // Process the data
});

// Stream with the default highWaterMark (64KB)
const stream2 = createReadStream(filePath);

// The first chunk is emitted slightly slower, but the overall processing is faster
stream2.on('data', (chunk) => {
  // Process the data
});

Here are the reasons why:

• Increased overhead: With a smaller buffer, the stream needs to process and emit chunks more frequently, resulting in increased overhead.

• Reduced throughput: The constant filling and emptying of a small buffer can limit the overall data throughput compared to a larger buffer.

Therefore, while a smaller `highWaterMark` might provide a quicker initial response, the default `highWaterMark` is generally optimized for efficient processing of larger data streams.

Conclusion

Node.js readable streams are not as simple as you might’ve thought initially. Especially when it comes to understanding of how they work in a certain use cases under highload or complex manipulation. Of course, we haven’t touched on all points but those should be enough for you to improve the overall understanding of the readable steams and start your own researched.

When I first tried to work with streams, I was confused, to say the least. The concept was completely new to me. I thought I could just ignore them, but it turns out they're everywhere in Node.js. Even core modules like fs and http use streams under the hood. So, I had to learn them and understand how they work.

What helped me was building a strong mental model that consists of multiple concepts. In this article, we'll explore these concepts and build a mental model of Node.js streams together.

What are Node.js Streams?

The main idea behind streams is that they take pieces of data from one place and transfer them to another. There are 4 important parts that I want to highlight based on this definition:

• Streams transfer data in pieces, not as a whole

• Streams transfer pieces of data in a specific size

• Streams aren't interested in the transferred data

• Streams simply provide a mechanism for data transfer

A common analogy used to describe streams is a pipe. However, this analogy often misses 2 crucial parts: the producer and the consumer. Let's use the same analogy but make it more complete.

Imagine a huge reservoir of water, and you have a house nearby. To supply water to your house, you need to build a pipe from the reservoir to your home.

P.S. I'm not a plumber, so don't take this drawing too seriously.

This analogy illustrates the three key parts of a stream:

• The water reservoir is a producer of water

• The pipe is a stream that transfers water from the reservoir to your home

• Your home is a consumer of water

Coming back to Node.js streams. Let's compare the pipe analogy to how they behave:

• The pipe doesn't transfer the entire reservoir of water all at once

• The pipe transfers water in pieces, each of a specific size that it can handle

• The pipe is not interested in the water itself, and it's just a way to transfer it

• The pipe is just a mechanism to transfer water from one place to another

Looks pretty similar to Node.js streams, right?

When are Node.js streams used?

Before going into the specific details of what streams are and how they work, let's first understand when they’re used.

Real-time data processing

Streams work great for processing when we deal with data that is partial or generated incrementally over time. Streams are highly effective for processing data that is generated incrementally or received in parts over time.

An ideal example of this is a WebSocket protocol. In short, it's a protocol that allows you to establish a two-way communication channel between the client and the server.

We'll get into more details on this protocol in the upcoming articles. We'll take the WS library as an example. It uses streams heavily. Here is an example where the abstraction called Sender implements a backpressure mechanism.

We'll talk about the backpressure in the upcoming section. And it is just one example. You can explore the library further and see other use-cases.

Network interactions

Every time you create a server using Node.js API, you're creating a duplex stream. HTTP module in Node.js uses the abstraction called Scoket to create a connection with a network socket. This Socket abstraction extends from the Duplex stream.

ObjectSetPrototypeOf(Socket.prototype, stream.Duplex.prototype);
ObjectSetPrototypeOf(Socket, stream.Duplex);

Whenever you see a construction like the following:

import { createServer } from 'http';

const server = createServer();

Know that under the hood, you're creating a duplex stream.

Working with large datasets

Imagine that you have a file that is 100GB in size. You need to parse it and process some data. How would you do it?

If you try to read the file using API, like readFileSync or readFile you'll crash your program.

import { readFileSync, readFile } from 'fs';

const largeFilePath = 'path/to/large/file.txt';

// Both of these will crash your program
const data = readFileSync(largeFilePath);
const asyncData = await readFile(largeFilePath);

The problem is that you're trying to load the whole file content into memory using these read APIs. Doesn't sound efficient at all. What we can do instead is to process the file's content in chunks.

import { createReadStream } from 'fs';

const largeFilePath = 'path/to/large/file.txt';
const stream = createReadStream(largeFilePath);

stream.on('data', (chunk) => {
  // Process the chunk here
});

With this approach, we're not waiting for the whole file to be loaded into memory. Whenever a chunk of data is ready, we're processing it.

Data transformation

All previous examples were about the cases where we either read data from somewhere or write data to somewhere. But we can also use streams to transform data that we already have in memory.

A good example of this is data compression/decompression. Here is an example taken from the zlib module in Node.js documentation.

async function do_gzip(input, output) {
  const gzip = createGzip();

  // Create a read stream to read data from the input
  const source = createReadStream(input);

  // Create a write stream to write data to the output
  const destination = createWriteStream(output);

  // Pipe the source stream to the gzip stream,
  // then to the destination stream
  await pipe(source, gzip, destination); }
}

In this code snippet, we're creating a read stream, and whenever data comes from this read stream, we pass it down to the gzip. When the gzip stream compresses the data, we pass it down to the write stream.

You don't have to understand how this code works just yet. Just understand that streams can be used to transform different data.

Don't use streams in this case

You don't want to use streams when the data you're working with is already in memory. There is just little to no benefit you can gain from using streams.

So please, try to avoid using streams when all pieces of data that you need are already in memory. Don't make your life harder.

Core concepts on Node.js streams

You understand what streams are, when to use them, and when not to. Now, you're ready to dive deeper into some of the core concepts of streams in Node.js.

Event-driven architecture

You know that streams are like pipes. But what exactly makes them work this way? It is all thanks to even-driven concepts that streams are built upon. In particular, all streams in Node.js are extended from the EventEmitter class.

The way EventEmitter works is very simple. It has some internal state where it stores all events and listeners of these events.

class EventEmitter {
  // Map of events and their listeners
  // Each event can have multiple listeners
  #events = new Map<string, (() => void)[]>();

  // Register a new listener for the event
  on(eventName: string, callback: () => void) {
    if (!this.#events.has(eventName)) {
      this.#events.set(eventName, [callback]);
    }

    this.#events.get(eventName).push(callback);
  }

  // Triggers all listeners related to the event.
  emit(eventName: string) {
    const listeners = this.#events.get(eventName);

    if (!listeners) {
      return;
    }

    listeners.forEach((listener) => listener());
  }
}

It is a very simplified version, but it gives you an idea of how EventEmitter works. You can read the full implementation in the Node.js source code.

When you work with streams, you can add a listener to some predefined set of events.

stream.on('data', () => {});

In this example, we add a listener to the data event. Whenever a chunk of data is ready, the stream calls the emit with the data event name, and all listeners are called.

It's the exact mechanism that makes streams work like pipes, where we get data from one end and pass it through to the other end.

Backpressure

Streams can be used to process large datasets efficiently. But there is a catch: what if the rate of data production is so high that at some point in time, we have more data in our program than allocated memory can handle? Right, the program will crash.

This means that just the abstraction of a stream is not enough to prevent such cases from happening. Streams have a backpressure mechanism in place for such cases.

Backpressure might sound like a fancy term, but in reality, it is quite simple. The main idea of backpressure is that we have some limit on how much data we can process at a time.

Let's get back to the example with reading a large file. There are 2 parts of this process that we're interested in: the producer of data and the consumer of data. The producer of data is the underlying OS mechanism that reads the file and produces the data.

If the producer tries to push too much data, a stream can signal to the producer that it needs to slow down because it can't take any more data at the moment. But how does the stream know when it's full?

Each stream has an internal buffer, and whenever new data comes in and the old one comes out, the "buffering" mechanism comes into play.

Buffering

Each stream has an internal buffer. If we work with API that enables backpressure mechanism, then this buffer is used to store data that comes into the stream.

If data comes into the stream but doesn't come out of the stream, the buffer steadily gets filled until it reaches the cap. The cap, in this case, is highWaterMark property set for each individual stream.

Here is an example of how we can set highWaterMark property when reading a file.

import { createReadStream } from 'node:fs';

const filePath = 'path/to/file.txt';

const writeStream = createReadStream(filePath, { highWaterMark: 1024 });

The highWaterMark is set to 64KB for createReadStream function by default. When the internal buffer frees up some space, the stream can start reading more data from the source.

Piping and chaining

In more or less complex Node.js applications you'll need to transform data that comes from a stream or send this data to some other destination. In cases like this, a concept called as "piping" comes useful.

You can create a chain of streams where one stream is connected to another stream and whenever data comes into the first stream in the chain it goes through the whole chain of streams. If you're familiar with reactive programming and things like RxJS, then this concept should be familiar to you.

import { createReadStream, createWriteStream } from 'node:fs';
import { createGzip } from 'node:zlib';
import { pipeline } from 'node:stream';

const source = createReadStream('path/to/file.txt');
const destination = createWriteStream('path/to/file.txt.gz');
const gzip = createGzip();

await pipeline(source, gzip, destination);

In this example the source stream triggers the whole pipeline. It goes like this:

1. source stream reads data from the file

2. source stream passes this data to the gzip stream

3. gzip stream compresses the data

4. gzip stream passes the compressed data to the destination stream

5. destination stream writes the compressed data to the file

6. The whole pipeline is finished

Every stage of the pipeline has its own internal buffer and backpressure mechanism. It means that if the gzip stream can't handle the data that comes from the source stream, it can signal to the source stream to slow down. The same thing goes for the destination stream.

Conclusion

Streams are at the heart of any Node.js application, whether you use them explicitly or not. It is also one of the most powerful features existing in Node.js. Streams are used in many different places in Node.js, from network interactions to file processing.

They are especially useful when you need to process large datasets or work with real-time data. The core mental model of streams is built around the following concepts:

1. Data over time

2. Event-driven architecture

3. Backpressure

4. Buffering

5. Piping and chaining

By understanding these concepts and having a clear picture of how streams operate at a conceptual level, you can build more efficient Node.js apps.

The constant switching of contexts can kill your productivity.

What if I tell you that it doesn't have to be that way? What if you could perform all the necessary profiling routine within the same workspace you're already using for coding?

In this article, we'll explore how to use the VS Code built-in debugger to profile and troubleshoot common performance issues in your Node.js application.

You'll be surprised how much you can do in terms of profiling by just using VS Code.

Setup

To illustrate the profiling process, we'll need some code. I've created a GitHub repository that contains common performance issues you might encounter in your Node.js application.

The repository contains a simple Node.js application with three routes, each designed to demonstrate a specific performance issue.

• A CPU-intensive task that blocks the main thread.

• An asynchronous operation with the waterfall problem, where execution goes sequentially instead of in parallel.

• A memory leak.

Each route has two implementations: one with the problem that can be spotted using the VS Code profiler, and the other is an optimized version offering with the same functionality.

I encourage you to clone the repository and explore the code to better understand the topics we're about to discuss.

Profiling

Now that we've set up the project let's explore how profiling in VS Code works.

Before diving into the specific problems, I want to mention that VS Code generates a profiling report after each profiling session. This profiling report can be viewed in 2 different ways:

• Table

• Flamegraph

While the table view is built-in, the flamegraph view requires a separate flamegrap extension to enable it.

Having multiple ways to visualize your data leads to better understanding. You can catch insights using one type of view that are hard to notice using the other type.

CPU-intensive endpoint

We start with the CPU-intensive endpoint. The main problem behind every CPU-intensive operation in JavaScript is that it blocks the execution thread. Other tasks can hardly make any progress while a CPU-intensive operation is running.

Sure, it can be solved by moving this task into a dedicated thread, but more often than not, you can avoid it by using a more efficient algorithm or data structure.

In our case, there are two implementations of this endpoint: one with a high CPU load and the other without it.

Let's look at implementation with high CPU consumption first.

function runCpuIntensiveTask(cb) {
  function fibonacciRecursive(n) {
    if (n <= 1) {
      return n;
    }
    return fibonacciRecursive(n - 1) + fibonacciRecursive(n - 2);
   }
  fibonacciRecursive(45);
  cb();
}

Here is the code that does the same thing in terms of functionality but consumes way less CPU resources.

function runSmartCpuIntensiveTask(cb) {
  function fibonacciIterative(n) {
    if (n <= 1) {
      return n;
    }
    let prev = 0, curr = 1;
    for (let i = 2; i <= n; i++) {
      const next = prev + curr;
      prev = curr;
      curr = next;
    }
    return curr;
  }
  fibonacciIterative(45)
  cb();
}

Both versions calculate the 45th Fibonacci number. The first implementation uses a recursive, CPU-intensive approach, while the second one employs an iterative, more efficient approach.

To start the profiling session in VS Code, you should follow these steps:

1. Open the Debugger tab, typically located on the left panel.

2. Choose the script you want to execute in the "Run and Debug" section.

   

3. Choose the appropriate profiling option. For CPU-intensive endpoint, we select "CPU profile".

   

4. Navigate to the "Call stack" section and click the "Take performance profile" button.

   

5. Choose the run option. For simplicity, we'll use the "Manual" option.

   

After going through all these steps, we're ready to start profiling.

Since the Node.js server is already running we only have to send a request to the CPU-intensive endpoint. We'll start with the implementation that consumes a lot of CPU resources and see if we can identify the problem just by looking at the profiling report.

Here are the profiler entries after sending the request:

As you can see, it is pretty easy to identify the bottleneck, it is the fibonacci function.

The results are presented in the table view. If you prefer a visual representation, you can switch to the flamegraph by clicking the flame button.

Remember, this button is only available after installing the flamegrap extension.

After clicking this button, you will see a picture similar to the timeline and entries.

Now that we've identified the problem, let's replace the recursive implementation with an iterative one and profile the improved version of the CPU-intensive endpoint.

After sending the request to the endpoint with the improved fibonacci function we see the following results:

The fibonacci function is not even close to the top 10 profiling entries. If we open the same profiling report in the flamegrap view you'll see that now it takes less than 10ms to execute.

Compare this 10ms of execution time to the previous 6.5sec. We can clearly see performance gains.

Async endpoint

Next, let's explore how to use VS Code's profiler to identify and resolve issues with asynchronous code execution.

Here's an asynchronous function that simulates a time-consuming operation:

function generateAsyncOperation() {
 return new Promise(resolve => {
   setTimeout(() => {
     // Simulate a time-consuming asynchronous operation
     for (let i = 0; i < 50000000; i++) { }
       resolve();
   }, 1000);
  });
}

For the sake of the example, we're running the for loop inside of the setTimeout callback just to make things easier to see in the profiler report.

First implementation of the asynchronous endpoint suffer from the waterfall problem where independent asynchronous functions are executed sequentially, causing details as each function waits for the previous one to complete.

export async function runAsyncTask(cb) {
 await generateAsyncOperation();
 await generateAsyncOperation();
 await generateAsyncOperation();
 cb();
}

Since these asynchronous functions are independent, we don't need to run them sequentially. Instead, we can run them concurrently.

export async function runSmartAsyncTask(cb) {
 await Promise.all(new Array(3).fill().map(() => generateAsyncOperation()));
 cb();
}

By using Promise.all we can run all 3 functions simultaneously.

Now that we've explored the code let's see how profiling can help us identify and address the waterfall problem. You start the debugging session in the same way as we did it for the CPU-intensive endpoint:

1. Open the Debugger tab

2. In the "Run and Debug" section, choose the script you want to execute.

3. Navigate to the "Call stack" section and click the "Take performance profile" button.

4. Select the "CPU profile" as a profiling option.

5. Choose the "Manual" run option.

Let's start by profiling the asynchronous endpoint with the sequential implementation. After sending a request and generating the profiling report, we see the following picture:

Notice those 3 pink entries on the flamegraph. Each one of those entries represents the execution of the generateAsyncOperation function.

The time span from the first entry to the last one is almost 2 seconds.

It takes almost 2 seconds from the first entry to the last one. Only after the last entry completes its executed we can get the response from the server.

After identifying the problem we can replace the sequential implementation with the optimized parallel version.

When you finish profiling the new endpoint implementation, the generated profiling report will surprise you.

Instead of 3 distinct entries there is only 1 representing the concurrent execution of all three asynchronous operations. It takes less than 100ms to complete the requests and return the result.

Memory leak endpoint

The last type of problems that we'll look into is memory leaks.

Here is how code containing memory leak looks like:

const memoryLeak = new Map();

// Function with a memory leak
export function runMemoryLeakTask(cb) {
 for (let i = 0; i < 10000; i++) {
   const person = {
     name: `Person number ${i}`,
     age: i,
   };
   memoryLeak.set(person, `I am a person number ${i}`);
 }
 cb();
}

In this case we assume that data from one request is not required for subsequent requests. Therefore, if any data persists between requests we consider it a memory leak.

Here's a modified version of the code without the memory leak:

const smartMemoryLeak = new WeakMap();

// Function without a memory leak
export function runSmartMemoryLeakTask(cb) {
 for (let i = 0; i < 10000; i++) {
   const person = {
     name: `Person number ${i}`,
     age: i,
   };
   smartMemoryLeak.set(person, `I am a person number ${i}`);
 }
 cb();
}

The main difference between these 2 implementations is the type of data used to store the objects. The Map in the first example keeps strong references to the object preventing garbage collection even when the object are no longer needed.

In contrast, the WeakMap in the second example uses weak references making objects available for garbage collection if the objects themselves are no longer referenced anywhere except the WeakMap itself.

We're ready to start profiling. The steps are the same except for the type of profiling we're running. The only difference is that instead of "CPU profile" we use "Heap Profile" option.

To clearly demonstrate the memory leak, let's send 4 requests to both endpoint implementations and compare the results.

Here is the profiling report after sending 4 requests to the endpoint that uses Map to store objects.

After the 4 requests, the program using Map occupies around 6mb of memory. While it might not seem like much, let's compare it to the implementation which uses WeakMap.

The program that uses WeakMap occupies only 350kb of memory after 4 requests. This is less than half a megabyte. The result is that the program occupies 16 times less memory space.

Conclusion

While VS Code might not have all the advanced features of dedicated profiling tools like DevTools or is not as smart as Clinic.js, it is still a solid option for profiling your Node.js applications.

Especially because you don't need to download any external libraries or connect to external tools and systems. Everything just works within your coding environment, so you stay focused on the goal.

If you want to learn more about other profiling options, I highly recommend reading the previous articles about how to profile Node.js apps using Chrome DevTools and how smart Clinic.js can help you understand profiling reports better.

Other programming languages like Golang have higher-level synchronization primitives built into their standard libraries to control access to shared resources between multiple threads.

Although JavaScript doesn't have any of such primitives except Atomics, we can build them from scratch based on what we see in other languages.

In this article, we'll do exactly that. We'll implement two of the most popular synchronization primitives: Semaphore and Mutex. We'll explore the differences between these primitives and discuss when to use each one.

Understanding what critical section is

One of the main problems in multithreaded programs is shared resources that can be directly accessed from multiple threads. This is where the concept of a critical section becomes increasingly important.

Any code that accesses the shared resources is considered a critical section. Note that not only write operations but even read operations can be considered as a part of a critical section.

It is important to clearly identify a critical section to write code that runs safely in a multithreaded environment.

Let's look at a code example from the previous article about Atomics in Node.js.

import { isMainThread, Worker, workerData, threadId } from 'node:worker_threads';

if (isMainThread) {
  const buffer = new SharedArrayBuffer(10);
  new Worker(import.meta.filename, { workerData: buffer });
  new Worker(import.meta.filename, { workerData: buffer });
} else {

  // Critical section
  const typedArray = new Int8Array(workerData);
  const value = Atomics.store(typedArray, 0, threadId);
  console.dir({ threadId, value });
  // End of critical section
}

In this example, we can consider the whole else block as a critical section, and here is why:

1. We create a view into the shared resources, which is basically an indicator of intention to interact with the shared resources. If you're not familiar with views, I recommend reading one of the previous articles about what buffer views are and how to use them in JavaScript.

2. We directly mutate the shared buffer using Atomics.store function.

3. We read from the buffer and print this value into the console.

If we're not modifying the shared buffer inside of a worker thread, then it is not considered a critical section simply because there is no way we can run into race conditions based on such logic.

I think you'll agree with me that it is kind of hard to track such critical sections simply by the type of operations we perform on a specific set of resources.

In other languages, it is fairly easy to mark some sections as critical using thread locks. Let's see how it works and compare it to Node.js.

Compare thread locks from Golang with Node.js

The problem of access to shared resources across multiple execution contexts is not new, and other languages and platforms have their own way of dealing with this problem. Let's look at an example of how we can do it in Golang.

Thread locks in Golang

Here's an example of how Golang uses a mutex to protect shared resources:

type SafeCounter struct {
    mu sync.Mutex
    v  map[string]int
}

func (c *SafeCounter) Inc(key string) {
    c.mu.Lock()
    // Lock so only one goroutine at a time can access the map c.v.
    c.v[key]++
    c.mu.Unlock()
}

Even if you're not familiar with Golang, the logic should be pretty clear:

1. c.mu.Lock() marks the beginning of a critical section

2. c.v[key]++ is the actual operation over the shared resources

3. c.mu.Unlock() marks the end of a critical section

When you look at this code, it is fairly easy to identify where operations over shared resources are taking place. You don't have to think about what kind of operations you're running and over what resources.

Atomics in Node.js

It is possible to create such locks in Node.js simply because of how JavaScript and Node.js as a is designed. The closest thing we can get is to mark such sections with Atomics.

import { isMainThread, Worker, workerData, threadId } from 'node:worker_threads';

if (isMainThread) {
  const buffer = new SharedArrayBuffer(12);
  new Worker(import.meta.filename, { workerData: buffer });
  new Worker(import.meta.filename, { workerData: buffer });
} else {
  const typedArray = new Int32Array(workerData);
  const itemIndex = 0;

  if (threadId !== 1) {
    Atomics.wait(typedArray, itemIndex, 0);
  }

  const value = Atomics.store(typedArray, itemIndex, threadId);

  Atomics.notify(typedArray, itemIndex);
  console.dir({ threadId, value });
}

As you can see, it is not even close to Golang. There are simply too many things you have to be aware of to make things work properly in a very basic use case.

1. Use Atomics.wait everytime to stop a thread execution until some condition has been met.

2. Create Int32Array to manage concurrent access to shared resources.

3. Call Atomics.notify to let other sleeping threads know they can proceed with execution.

From one side, it might look like a reasonable limitation for high-level language that runs in an end-user environment such as browser.

However, when comparing such API with what Golang or other languages have to offer, it is not nearly as convenient as it could be.

We can fix that by creating similar abstractions from other languages ourselves. While they still may not be 100% perfect because of the language and the platform limitations, we can get pretty close to what we see in other languages.

That said, let's move forward and implement 2 of the most popular synchronization primitives: Semaphore and Mutex.

Building Semaphore and Mutex

Both semaphores and mutexes are meant to solve the same problem - limit access to shared resources. At the same time, there are nuances in how they are doing so which we'll dive into next.

Semaphore

In simple words, semaphore is an abstraction that allows multiple threads to work with the same shared resources. Semaphores are based on a counting mechanism. You can specify how many threads you're willing to have access to the shared resources.

It could be as little as 1 or as many as you want. Semaphore where only 1 thread is allowed to access the resources is called a binary semaphore.

Let's walk through the creation of semaphore step by step to better understand how it works. First, we create the class.

class Semaphore {
  constructor(buffer, maxCount) {
    this.typedArray = new Int32Array(buffer);
  }
}

We want to pass only 2 arguments: an instance of SharedArrayBuffer and the number which sets the limit to the number of threads that can access the buffer at the same time.

Here is how we'll use the Semaphore class:

import { Worker, isMainThread, workerData, threadId } from 'node:worker_threads';

if (isMainThread) {
  const buffer = new SharedArrayBuffer(12);
  const semaphore = new Semaphore(buffer, 5);
  new Worker(import.meta.filename, { workerData: buffer });
  new Worker(import.meta.filename, { workerData: buffer });
} else {
  const semaphore = new Semaphore(workerData);

  // Rest of the code
}

We create Semaphore instance in every thread simply because there is no way to share the same object reference across multiple threads by design.

The difference here is how we create Semaphore instance. We only want to pass the maxCount argument in the main thread because only the main thread must dictate how many threads can access the underlying buffer.

The next step is to set up the shared counter:

class Semaphore {
  constructor(buffer, maxCount) {
    this.typedArray = new Int32Array(buffer);

    if (maxCount !== undefined) {
      Atomics.store(this.typedArray, 0, maxCount);
    }
  }
}

The idea here is to have the first element of the array as some sort of counter. Whenever a new thread comes in, we want to decrement this counter. When this thread releases the semaphore, we want to increment this counter.

It is important to have this counter as the first element of the buffer because the buffer is the only thing that is shared between all threads and changes made in one thread are visible in the other.

It is time to implement the acquire method. When using this method, the shared counter should be decremented. If the number of threads that can access the shared resources has reached the limit, we want to completely stop the thread execution until the semaphore signals that we can move forward.

class Semaphore {
  constructor(buffer, maxCount) {
    this.typedArray = new Int32Array(buffer);

    if (maxCount !== undefined) {
      Atomics.store(this.typedArray, 0, maxCount);
    }
  }

  acquire() {
    while (true) {
      const value = Atomics.load(this.typedArray, 0);
      if (value === 0) {
        Atomics.wait(this.typedArray, 0, 0);
        continue;
      }
      if (Atomics.compareExchange(this.typedArray, 0, value, value - 1) === value) {
        return;
      }
    }
  }
}

Let's walk through the implementation step by step and understand how it works.

We'll leave the while loop at the end.

After we enter the loop, the first thing we do is load the current counter using Atomics.load function.

If the counter is 0 it means that there is no room for one more thread to access the resources. Therefore, we want to wait until the counter has a value higher than 0. We're doing so by using Atomics.wait function.

If the value is not 0, we want to ensure that the value we've loaded with Atomics.load function is indeed the previous value that the counter contains.

Using Atomics.compareExchange we only replace a new value value - 1 at a given index if the expected value value is equal to the value stored in the counter at the moment of calling this function.

The reason why we're doing so is because multiple threads can go through the same steps at the same time. They can enter the function at the same time, load the value at the same time, and start the compareExchange function at the same time.

  function acquire() {
    while (true) {

      // Multiple threads can load the
      // current counter at the same time

      const value = Atomics.load(this.typedArray, 0);

      // Those multiple threads can then run
      // this check at the same time and pass it

      if (value === 0) {
        Atomics.wait(this.typedArray, 0, 0);
        continue;
      }

      // However, only one of those threads can actually set
      // the value using `compareExchange` at a time

      if (Atomics.compareExchange(this.typedArray, 0, value, value - 1) === value) {
        return;
      }
    }
  }

Even when multiple threads are running compareExchange, only one of them can actually write the value. After the first thread is done writing the value, all the others will fail to match the condition in the if block.

After that, the while loop comes into play. We want to repeat this action until all the cases match the if block condition and exit the acquire function.

It might sound a bit strange that we need to run an infinite loop to keep things working, but threads spend most of the time in sleep mode, so there is no heavy load on the CPU.

Coming back to implementation. The last step would be to implement the release method.

export class Semaphore {
  constructor({ buffer, maxCount }) {
    this.typedArray = new Int32Array(buffer);

    if (maxCount != null ) {
      this.maxCount = maxCount;
      Atomics.store(this.typedArray, 0, this.maxCount);
    }
  }

  acquire() {
    while (true) {
      const value = Atomics.load(this.typedArray, 0);
      if (value === 0) {
        Atomics.wait(this.typedArray, 0, 0);
        continue;
      }
      if (Atomics.compareExchange(this.typedArray, 0, value, value - 1) === value) {
        return;
      }
    }
  }

  release() {
    Atomics.add(this.typedArray, 0, 1);
    Atomics.notify(this.typedArray, 0, 1);
  }
}

Whenever the release method is called we increment the shared counter by 1 and notify only a single sleeping thread that the value has been changed, and it can try to access the shared resources.

The semaphore is completed, and we can now use it.

import { isMainThread, Worker, workerData, threadId } from 'node:worker_threads';

if (isMainThread) {
  const buffer = new SharedArrayBuffer(10);
  const semaphore = new Semaphore(buffer, 1);
  new Worker(import.meta.filename, { workerData: buffer });
  new Worker(import.meta.filename, { workerData: buffer });
} else {
  const typedArray = new Int8Array(workerData);
  const semaphore = new Semaphore(workerData);

  // Critical section
  semaphore.acquire();
  typedArray[4] = threadId;
  console.dir({ threadId, value: typedArray[4] });
  semaphore.release();
  // End of critical section
}

Notice how we're using it. It is almost the same API as we've seen in Golang. Just by calling acquire and release functions, we can clearly mark the boundaries of a critical section.

And the best part is that we don't even need to explicitly use Atomics. Semaphore guarantees a thread-safe environment in between acquire and release calls.

Of course, if we increase the number of maximum threads that can operate over the resources from one to 2 or more, then we're still prone to race conditions.

Mutex

Mutex stands for "mutual exclusion". It is a synchronization mechanism that allows only one thread to access shared resources at a time, unlike semaphore, where we can configure a number of threads that have access to the shared resources.

Another feature of mutex is ownership. If a thread locks a mutex, it means that this thread becomes the owner of the shared resources, and only this thread can unblock other threads and make the shared resources available.

When working with semaphores, it is not important who is unblocking the locked resources.

The last thing to mention is that mutex is generally easier to manage, because it is always about binary state. On the other hand, the more threads we allow semaphore to have the more complexity we introduce into a system.

Since mutex and semaphore share a similar goal - to limit access to the shared resources, their implementation would be quite similar except for some details that we just mentioned.

We'll start with the constructor.

class Mutex {

  constructor(buffer) {
    this.typedArray = new Int32Array(buffer);
    this.isOwner = false;
  }
}

We're not passing the maxCount argument because mutex is always binary. We're also adding a new property isOwner to keep track of the mutex ownership.

The next step is to implement the lock method.

const unlocked = 0;
const locked = 1;

class Mutex {

  constructor(buffer) {
    this.typedArray = new Int32Array(buffer);
    this.isOwner = false;
  }

  lock() {
    while (true) {
      const value = Atomics.load(this.typedArray, 0);
      if (value === locked) {
        Atomics.wait(this.typedArray, 0, locked);
        continue;
      }
      if (Atomics.compareExchange(this.typedArray, 0, unlocked, locked) === unlocked) {
        this.isOwner = true;
        return;
      }
    }
  }
}

It is pretty similar to the semaphore's implementation of acquire method. Except we're setting the isOwner property to true and implementing our logic in a way where only 2 possible states are allowed: locked and unlocked.

The final step is to implement the unlock method.

const unlocked = 0;
const locked = 1;

class Mutex {

  constructor(buffer) {
    this.typedArray = new Int32Array(buffer);
    this.isOwner = false;
  }

  lock() {
    while (true) {
      const value = Atomics.load(this.typedArray, 0);
      if (value === locked) {
        Atomics.wait(this.typedArray, 0, locked);
        continue;
      }
      if (Atomics.compareExchange(this.typedArray, 0, unlocked, locked) === unlocked) {
        this.isOwner = true;
        return;
      }
    }
  }

  unlock() {
    if (!this.isOwner) {
      throw new Error('Thread that tries to unlock the mutex is not the owner of the mutex');
    }
    Atomics.store(this.typedArray, 0, unlocked);
    Atomics.notify(this.typedArray, 0, 1);
    this.isOwner = false;
  }
}

The crucial part here is to check whether the current thread is the owner of the mutex before unlocking it. We're throwing an error if that's not the case, because thread is not allowed to unlock the mutex it doesn't own.

Here is how you use it:

import { isMainThread, Worker, workerData, threadId } from 'node:worker_threads';

if (isMainThread) {
  const buffer = new SharedArrayBuffer(10);
  new Worker(import.meta.filename, { workerData: buffer });
  new Worker(import.meta.filename, { workerData: buffer });
} else {
  const typedArray = new Int8Array(workerData);
  const mutex = new Mutex(workerData);

  // Critical section start
  mutex.lock();
  typedArray[4] = threadId;
  console.dir({ threadId, value: typedArray[4] });
  mutex.unlock();
  // End of critical section
}

Notice that we're not creating a mutex inside of the main thread as we did with semaphore.

Conclusion

We've covered a lot in this article:

• What is the critical section, and how does it look like Node.js

• How other programming languages work with critical sections and shared resources across multiple threads

• Implemented custom Semaphore and Mutex classes in Node.js to abstract from low-level Atomics API work

While things like Semaphore and Mutex definitely makes our lives easier, but they also create new problems like deadlocks and livelocks.

In the upcoming article, we'll see how we can run into common multithreading problems in Node.js and how to solve them.

However, things change when you add shared resources to multiple threads. In fact, it is one of the most challenging topics in all software engineering. I'm talking about multithreading programming.

Thankfully, JavaScript provides a built-in abstraction to mitigate the problem of shared resources across multiple threads. This mechanism is called Atomics.

In this article, you'll learn what shared resources look like in Node.js and how Atomics API helps us to prevent wild race conditions.

Shared memory between multiple threads

Let's start with understanding what transferable objects are.

Transferable objects are the objects that can be transferred from one execution context to another without holding to resources from the original context.

An execution context is a place where JavaScript code can be executed. To make it easier to understand, let's assume that an execution context is equal to a worker thread because each thread is indeed a separate execution context.

For example, ArrayBuffer is a transferable object. It consists of 2 parts: raw allocated memory and JavaScript handle to this memory. You can read the article about Buffers in JavaScript to learn more about this topic.

Whenever we transfer ArrayBuffer from the main thread to a worker thread, both components, the raw memory and JavaScript objects are recreated in the worker thread. There is no way you can access the same object reference or underlying memory of ArrayBuffer inside of the worker thread.

The only way to share resources between different threads is to use SharedArrayBuffer.

As the name suggests, it is designed to be shared. We consider this buffer to be a non-transferable object. If you try to pass SharedArrayBuffer from the main thread to a worker thread, only the JavaScript object gets recreated, but the memory region that it refers to is the same

While SharedArrayBuffer is a unique and powerful API it comes with a cost.

As Uncle Ben told us:

When we share resources between multiple threads, we expose ourselves to a whole new world of nasty race conditions.

Race conditions for shared resources

It would be easier to understand what I'm talking about with a particular example.

import { Worker, isMainThread } from 'node:worker_threads';

if (isMainThread) {
  new Worker(import.meta.filename);
  new Worker(import.meta.filename);
} else {
  // worker code
}

We're using the same file to run the main thread and worker threads. The block under isMainThread condition is executed only for the main thread. You might also notice import.meta.filename, it is ES6 alternative to __filename variable available since Node 20.11.0. Next, we introduce a shared resource and an operation over the shared resource.

import { Worker, isMainThread, workerData, threadId } from 'node:worker_threads';

if (isMainThread) {
  const buffer = new SharedArrayBuffer(1);
  new Worker(import.meta.filename, { workerData: buffer });
  new Worker(import.meta.filename, { workerData: buffer });
} else {
  const typedArray = new Int8Array(workerData);
  typedArray[0] = threadId;
  console.dir({ threadId, value: typedArray[0] });
}

We pass SharedArrayBuffer to each of the workers as workerData. Both workers change the first element of the buffer to its ID. Then, we log the first buffer element.

One of the workers will have ID equals to 1 and the other one to 2. Without reading any further, what are you expecting to see in the output when this code runs?

Here is the result.

# 1 type of results
{ threadId: 1, value: 2 }
{ threadId: 2: value: 2 }

# 2 type of results
{ threadId: 1, value: 1 }
{ threadId: 2: value: 1 }

# 3 type of results
{ threadId: 1, value: 1 }
{ threadId: 2: value: 2 }

Did you notice it? Why on earth do we have cases where the value is the same for both threads? If you think about it from the standpoint of a single-threaded program, we should see different values printed every time.

Even if we run this code asynchronously in a single thread, the only thing that could be possibly different is the order in which a result is printed, but not such a drastic difference in the final value.

What happens here is one of the threads assigns value right between these two lines:

  typedArray[0] = threadId;

  // one of the threads sneaks right in here and assign value

  console.dir({ threadId, value: typedArray[0] });

It goes like this:

1. The First thread assigns a value to the shared buffer

2. The second thread assigns a value to the shared buffer

3. The first thread prints the result to the console

4. The second thread prints the result to the console.

As you can see, it is easy to run into a race condition with as little as 10 lines of code when we have shared resources and multiple threads. That's why we need a mechanism that can make sure that one worker is not interrupting the workflow of another worker. The Atomics API was created exactly for this purpose.

Atomics

I want to emphasize that using Atomics is the only possible way to be 100% sure that you're not running into race conditions when dealing with multiple threads and shared resources between them.

The main purpose of Atomics is to make sure that a single operation is performed as a single, uninterruptible unit. In other words, it ensures that no other workers can get in the middle of currently executable operation and do their stuff, like we've seen before.

Let's rewrite the example with race conditions using Atomics.

import { Worker, isMainThread, workerData, threadId } from 'node:worker_threads';

if (isMainThread) {
  const buffer = new SharedArrayBuffer(1);
  new Worker(import.meta.filename, { workerData: buffer });
  new Worker(import.meta.filename, { workerData: buffer });
} else {
  const typedArray = new Int8Array(workerData);
  const value = Atomics.store(typedArray, 0, threadId);
  console.dir({ threadId, value });
}

We changed two things: how we save the value and how we read the saved value. Using Atomics, we can do both operations at the same time using the store function.

When you run this code, you won't see a case where both threads have the same value. They are always different.

[1, 1]
[2, 2]

[2, 2]
[1, 1]

We could use 2 operations instead of 1: store and load.

const typedArray = new Int8Array(workerData);
Atomics.store(typedArray, 0, threadId);
const value = Atomics.load(typedArray, 0);
console.dir({ threadId, value });

However, this approach is still prone to race conditions. The whole point of using Atomics is to make our operations atomic.

In this case, we want 2 operations to be executed as a single atomic operation: to save a value and to read this value. When we use store and load functions, we're actually doing 2 separate atomics operations, not 1.

That's why it is still possible to run into a race condition where code from one worker gets in between store and load calls from the other threads.

There are more than just 2 functions to Atomics, in the following article, we'll cover how to use more of its functions to build our own semaphore and mutex to make the work with shared resources even more convenient.

Conclusion

Node.js is all fun and good when there is only a single thread. If you introduce multiple threads and shared resources on top of it, you get an environment where race conditions are inevitable.

There is only one mechanism in JavaScript that allows you to mitigate these problems and avoid race conditions, it is called Atomics.

The idea of Atomics is to have operations that execute as a single unit that cannot be interrupted from the outside.

Thanks to such a design, we can be sure that whenever we use Atomics functions, there is no way for other threads to get somewhere inside of such operations.

Don't get me wrong, I'm not against paying for products and services, but sometimes you don't make the decision on whether to pay or not.

People using Linux are fine. However, it is not that easy for people using Mac and Windows to drop Docker Desktop. That's exactly the situation where I found myself recently. This article will show you what alternatives you might use to keep working with Docker on Mac and Windows without using Docker Desktop.

Docker Desktop is more than just UI

First, I want to address a common misconception.

Even if you're not using UI, you might very well be using Docker Desktop. You see, the desktop bundle is more than just UI, and you start using it from the moment you accept the license agreement.

The catch is that without accepting the agreement, you won't be able to work with Docker at all. You still have CLI, which comes with the desktop bundle, but to make things work, you have to have the Docker daemon running.

If you try to run any command that somehow interacts with the daemon, you'll get the following error.

Cannot connect to the Docker daemon at unix://path/top/docker/socket.
Is the Docker daemon running?

If you are running Docker containers without installing any extra tools and don't see such an error, it means you've accepted the service agreement. You're using Docker Desktop, even if you're not touching the UI.

How does Docker Desktop work

Before diving into Docker Desktop alternatives, let's first understand what Docker Desktop is and how it works.

On the official Docker website, you can find every piece of software that comes with the desktop bundle.

In this article, we'll mostly focus on Docker Engine.

Docker Engine is the heart of Docker. It keeps the system up and running. The engine consists of 3 pieces:

• A long-running daemon process called dockerd

• API that other programs can use to interact with programs running in dockerd

• A command line interface (CLI) called docker

Notice that Docker Engine only supports particular Linux distributions. But how does it work on Mac and Windows then?

To make things work, Docker Desktop creates a virtual machine (VM) on your Mac or Windows machine. This VM is running a Linux distribution that Docker Engine supports. Inside this VM, Docker Engine runs the dockerd daemon.

It is important to understand the part on how things get running with Docker Desktop because all the alternatives that we're about to look at are doing exactly the same.

They all create a VM and run things inside this VM. It is the universal approach to make Docker work on unsupported Linux distributions or non-Linux systems.

Now that you have some idea of how Docker Desktop works behind the scene, we can move forward to its alternatives.

Colima for Mac

The first alternative on the list is Colima. It is a minimalistic container runtime for Mac and Linux. To install Colima on your Mac, run the following brew command.

brew install colima

To start running Colima, use the start command.

colima start

This command creates a Linux VM and makes it possible to run the dockerd daemon. The default configuration of the VM is as following:

• Disk space 60GB

• CPU 2

• Memory 2

If you want to change any of these, pass a dedicated option with the number that suites your needs.

colima start --disk 100 --cpu 4 --memory 6

This command creates a machine with 100GB of disk space, 4 CPU cores, and 6GB of RAM.

It was the hardest part. Now, you only need to install the Docker CLI and Docker credentials helper packages using brew.

brew install docker docker-credentials-helper

Now you're ready to go.

Podman for Mac and Windows

Podman is developed by Red Hat and the open source community.

Podman is different from Colima:

• It works across all major operating systems: Windows, Mac, Linux

• It is not only about containers. It goes beyond and provides a way to work with Kubernetes

• Podman itself implements the Open Container Initiative (OCI)

At the same time, Podman is similar to Colima in terms of how it makes things work. When running Podman on Windows or Mac, it creates VM that allows it to run dockerd inside.

If you like to work with GUI (I personally do), then you can install a dedicated desktop client. It is super convenient to create VM using it.

Since it implements OPC itself, is it possible to use it with Docker? The answer is sound yes. Podman is listening to Docker API clients supporting direct usage of Docker-based tools.

Overall, Podman looks like a solid alternative to Docker. It is backed by the big company and an open-source community. It has a dedicated desktop client that is easy to work with. It implements OPC, which makes it possible to ignore Docker completely and move to Podman.

Conclusion

Some people think that if they are not using the UI provided by the desktop app, they are not using Docker Desktop, but this is far from true. The moment you accept the license agreement, you're using the desktop application.

There might be different reasons why you can't use Docker Desktop, but it doesn't mean you have no options. There are great tools that can replace Docker Desktop without any problems and make your experience with Docker seamless.

For Mac users, Colima is one option. It is lightweight, easy to install, and impressively easy to manage.

For Mac and Windows users, Podman is another great option. It is not only compatible with Docker and its API, but unlike Colima, it also provides a dedicated desktop client with GUI where you can manage images, containers, and everything that comes with it.

Node.js provides a dedicated buffer abstraction called Buffer. Why do we need more buffers when we already have ArrayBuffer and the different views that come with it?

In this article, we'll answer this question and understand the difference between Node.js buffer and all the others. In the end, you'll learn what problems the Node.js buffer has and why some people avoid using it at all costs.

Difference between Node.js buffer and typed arrays

In short, the Node.js buffer is basically Uint8Array spiced up with some extra logic. It automatically means two things:

1. Node.js buffer is not "actually" a buffer but a view into an underlying buffer.

2. Wherever you use Uint8Array, you can also use Node.js buffer, with minor exceptions that we'll discuss later in this article.

One of the core abstractions responsible for buffers in Node.js is called FastBuffer. It is a class that extends Uint8Array. You can see it for yourself.

class FastBuffer extends Uint8Array {
  // Using an explicit constructor here is necessary to avoid relying on
  // `Array.prototype[Symbol.iterator]`, which can be mutated by users.
  // eslint-disable-next-line no-useless-constructor
  constructor(bufferOrLength, byteOffset, length) {
    super(bufferOrLength, byteOffset, length);
  }
}

Functions that create Node.js buffer such as Buffer.from always return the FastBuffer. But what is the point of having such a dumb class without any logic? Moreover, whenever we call Buffer.from it actually returns Buffer, not FastBuffer.

import { Buffer } from 'node:buffer';

const buffer = Buffer.from('hello');
console.log (buffer); // Prints <Buffer 68 65 6c 6c 6f>

Am I misleading you? Not really. The reason you see Buffer instead of FastBuffer in the console and why FastBuffer doesn't contain any additional logic itself because of the prototype manipulations.

FastBuffer.prototype.constructor = Buffer;
Buffer.prototype = FastBuffer.prototype;
addBufferPrototypeMethods(Buffer.prototype);

What is the point of such a manipulation? One of the reasons is backward compatibility. Many Node.js APIs have been using Buffer for a long time, and changing code to FastBuffer might result in big problems. That's why it is easier just to swap prototypes and keep the same interfaces for the existing code.

The Buffer prototype is where all methods like from, alloc, and others reside.

Node.js buffer memory allocation

I want to bring your attention to how Node.js allocates the memory for its buffer.

That's one of the most important differences between Buffer and Uint8Array, which you should be aware of.

The first thing you have to understand is that typed arrays have separate memory pools.

const array1 = new Uint8Array('hello');
const array2 = new Uint8Array('world');

console.log(array1.byteOffset); // Prints 0
console.log(array2.byteOffset); // Prints 0

By memory pool, I mean the buffer where data is stored. Every time you create a new typed array, you create a dedicated instance of ArrayBuffer with it. At the same time, Node.js buffers share the same memory pool.

import { Buffer } from 'node:buffer';

const buffer1 = Buffer.from('hello');
const buffer2 = Buffer.from('world');

console.log(buffer1.byteOffset); // Prints 16
console.log(buffer2.byteOffset); // Prints 24

If you save anything less than 8 kilobytes in a buffer, then you end up with multiple data chunks in the same shared memory pool.

You see 16 in the console because there was already some pre-allocated data inside of a buffer pool. The bytes offset of the second buffer directly depends on how much space the first buffer takes.

import { Buffer } from 'node:buffer';

const buffer1 = Buffer.from('controversial');
const buffer2 = Buffer.from('opinion');

console.log(buffer1.byteOffset); // Prints 16
console.log(buffer2.byteOffset); // Prints 32

The word hello is 5 characters long, and the word controversial is 13 characters long. The difference between them is 8 characters, and it is the exact difference in the offset of a second buffer between two examples.

I must say that there is a safer way to create a buffer. You can do so by using alloc function. However, it doesn't change the fact that the buffer has a shared memory pool.

Node.js Buffer problems

Now, that you understand how Node.js Buffer looks like it is time to discuss some of its problems. It's been an ongoing discussion since typed arrays became available. The main question is, "Why do we need to have the Buffer at all?"

It is not compatible with other platforms

Imagine you developing a library that you want to be available anywhere: browsers, Node.js, or Deno. If you try to write code using Buffer it will break in any other non-Node.js platform. The reason is simple, it is Node.js specific API.

Instead, you can use typed arrays like Uint8Array or Int8Array. They are part of ECMAScript standard, and all big platforms that are running JavaScript support them.

It violates Liskov substitution principle

Liskov substitution principle (LSP) is one of the SOLID principles that state that a subclass should be able to substitute for its parent class without causing unexpected behaviors.

While Node.js Buffer extends Uint8Array, it overrides slice method, which leads to violation of LSP because they behave differently.

When you use slice with typed arrays like Uint8Array instances, a new typed array with a new underlying buffer is created.

const array1 = new Uint8Array([1, 2, 3]);
const array2 = array1.slice(0, 2);

array2[0] = 4;

// Prints Uint8Array {0: 4, 1: 2}
console.log(array2);

// Prints Uint8Array {0: 1, 1: 2, 2: 3}
console.log(array1);

After we mutate the first element of array2, it only affects the underlying buffer of array2. We don't see any changes to the first element in array1. slice method of Node.js Buffer is different. Instead of creating a copy, it creates a view into the same buffer.

import { Buffer } from 'node:buffer';

const buffer1 = Buffer.from([1, 2, 3]);
const buffer2 = buffer1.slice(0, 2);

buffer2[0] = 4;

// Prints <Buffer 04 02>
console.log(buffer2);

// Prints <Buffer 04 02 03>
console.log(buffer1);

You can see that buffer2 has 4 as its first element, which is expected because we directly mutated this buffer. What is not expected is that the first element of buffer1 has also changed to 4. slice method is officially marked as deprecated. However, as long as it is available as Buffer method it violates LSP.

Buffer has more security implications

The last but not least part is Buffer security. As we've mentioned before, Node.js buffer has a shared memory pool.

If we have some data stored in this shared memory pool, any code that runs in your application can access this memory. Imagine a scenario where you store sensitive data in the buffer, like a person's address, and I, as a bad actor, can access this data.

import { Buffer } from 'node:buffer';

const addressBuffer = Buffer.from('Person personal addres');

Here we have a buffer with personal information that we don't want to leak anywhere. We can gain access to it through the shared memory pool.

const hackyBuffer = Buffer.from('1');

// Prints the full underlying buffer
console.log(hackyBuffer.buffer);

Assuming we don't have access to the initial buffer object itself, we create hackyBuffer. The underlying buffer of hackyBuffer contains the persons' private data. The only thing left is to interpret the hexadecimal data stored in the buffer into a human-readable format.

const hackyBuffer = Buffer.from('1');

const typedArray = new Uint8Array(hackyBuffer.buffer)
  .filter(value => value !== 0);
const charCodes = Array.from(typedArray);

// Prints "//Person personal addres"
console.log(String.fromCodePoint(...charCodes));

We created a view into the underlying buffer to be able to work with its content. Then, we filtered all empty values and created an array of character codes. At this point, it was automatically converted from a hexadecimal to a decimal numeric system.

The only thing left is to convert those numbers into a string. Since all of these numbers are basically a number representation of Unicode characters, we can use fromCodePoint to convert them back to characters.

If you're not comfortable with all these manipulations with character and numeric systems, I highly recommend reading the article about different encoding schemes in JavaScript.

And that's how you "hack" Node.js buffer.

Why do we need to use Node.js buffer at all

After seeing all of these problems, it is reasonable to ask the purpose of using of Node.js buffer.

It is a valid question, and it has been raised in Node.js community before. We can notice that the question of giving more preference to Uint8Array instead of Buffer having more and more attention which is a good sign. Despite all the problems, Buffer has useful functions that haven't been shipped with typed arrays yet. For example, we can convert buffer to hex or base64 string.

import { Buffer } from 'node:buffer';

const buffer = Buffer.from('hello');

// Prints 68656c6c6f
console.log(buffer.toString('hex'));

There are libraries that make it work with Uint8Array, but it is one more dependency in your project that is not always worth it.

Conclusion

Buffer is Node.js abstraction that enables you to create and manage buffers through a common interface. The Buffer extends Uint8Array and essentially not a buffer, but view into the underlying ArrayBuffer.

While Buffer extends Uint8Array, it provides extra methods on top of the typed array, which makes it unique.

Unlike regular typed arrays, Node.js buffer has a shared memory pool. It means that if you create two small buffers, they share the same memory space. This design with a shared memory pool leads to potential vulnerabilities because it is possible to get data from one buffer through a completely unrelated buffer.

Other problems of Buffer include limited distribution across other platforms because it is Node.js-specific API, and violation of LSP principle from SOLID where superclass method behavior and subclass method behavior are different.

Despite all of these problems, the Node.js Buffer still might be useful because it provides the functionality that typed arrays simply don't have.

To change buffer content, we have two options: data views and typed arrays. In this article, we'll talk about data views, typed arrays, and their differences.

Data views

Data view is the abstraction that allows you to change the content of a buffer. It acts like a key to a locked door. You can't go inside without having a key, but once you have it, feel free to come in.

The same is true for the relation between buffer and data view. Data view is like a key that allows you to write data inside a buffer. Data view is represented by the DataView class in JavaScript.

It holds the key to the underlying ArrayBuffer instance where data is stored.

You can see example in the code snippet below.

const buffer = new ArrayBuffer(8);
const view = new DataView(buffer);

console.log(view.buffer.byteLength); // Prints 8

view.buffer.resize(5);

console.log(buffer.byteLength); // Prints 5

Notice that the buffer size changed after the buffer that view references was resized. This means that the view references the same buffer that we passed into the DataView class constructor.

When we want to write into a buffer using data view, we call one of the methods that set different types of values.

const buffer = new ArrayBuffer(16);
const view = new DataView(buffer);

view.setUint8(0, 0x0F);

console.log(view.getUint8(0)); // Prints 15

When we call the setUnit8(0, 0xF) method, it writes the value of 0x0F inside the buffer using 1 byte for it.

Typed arrays

The second option to change buffer data is typed arrays. Don't be confused by the array part. Typed arrays aren't arrays but array-like structures.

What it means is when you use Array.isArray function and pass a typed array inside it returns false. At the same time, typed arrays provide many array-like methods: at, fill, map, reduce, etc. That's why typed arrays are called array-like structures.

In JavaScript, we have many different typed arrays such as:

• Uint8Array

• Int8Array

• Uint16Array

• Int16Array

• Float32Array

• Float64Array

And others. Every typed array provides the ability to modify the underlying buffer. But what is the difference between all those typed arrays and when to use which?

To understand this topic better, I highly recommend reading the article about different types of text encoding schemes in JavaScript. Knowing text encoding schemes makes it much easier to understand the topic of typed arrays.

There are 3 main characteristics of the typed arrays you should know about:

• Signed and unsigned typed arrays

• Number of bytes required to store a single value inside a typed array

• Type of value that a typed array can store

Let's look at each of them in more detail.

Signed and unsigned typed arrays

The meaning of the data that the buffer contains heavily depends on the context in which it is interpreted.

const signedArray = new Int8Array([0xFF, 0x75, 0x6E]);
const unsignedArray = new Uint8Array([0xFF, 0x75, 0x6E]);

// Prints Int8Array {0: -1, 1: 117, 2: 110}
console.log(signedArray);

// Prints Uint8Array {0: 255, 1: 117, 2: 110}
console.log(unsignedArray);

Quick note, if you're not comfortable with those 0xFF and other hexadecimal values, check out the article in which we dive into the hexadecimal numeric system in JavaScript.

You see that both structures are almost identical. The only difference is that the first element with a value of OxFF in signed arrays is treated as -1, and in unsigned arrays, it is 255. That's the whole point of signed vs. unsigned, the range of possible values is different.

Signed arrays can contain both negative and positive values. Unsigned array can only contain positive values. The specific range of values is dictated by how many bytes are used to store a single item.

Number of bytes required to store a value

Typed arrays store values differently. To be more precise, each typed array allocates a different number of bytes to store a single item.

For the same piece of data, different typed arrays allocate different number of bytes.

To better understand when to use which typed array, you have to understand the data you're working with.

If the data is not expected to exceed the range from 0 to 255, then it is better to use Uint8Array. It operates in this exact range, and it is one of the most memory-efficient type arrays.

If you expect to work with data where some elements can have a value higher than 255 it is better to use Uint16Array or Uint32Array. If you try to write a value higher than 255 into an 8-bit unsigned array, the value will be cut at 255.

const u8Array = new Uint8Array([0xFFF]);
const u16Array = new Uint16Array([0xFFF]);

console.log(u8Array) // Prints Uint8Array {0: 255}
console.log(u16Array) // Prints Uint16Array {0: 4095}

Different value types

Different typed arrays are meant to store different datatypes. So far, we've talked only about integer typed arrays. The integer, in this case, is a number without any floating point numbers like 3 or 120. But what if you want to store values with floating point numbers like 3.14?

const u8array = new Uint8Array([3.14]);

// Prints Uint8Array {0: 3}
console.log(u8Array);

The part after the floating point gets cut, and you only see 3. To store floating point numbers, you have to use specific typed arrays Float32Array or Float64Array.

const float32array = new Float32Array([3.14]);

// Prints Float32Array {0: 3.140000104904175}
console.log(float32array);

Now you can see the numbers after the floating point.

What is the difference between a data view and a typed array

It looks like we have 2 things that are doing basically the same. Well, it is partially true because both DataView and TypedArray are buffer views.

As you can see, using both abstractions gives you the same power to edit buffers' content. At the same time, there are differences in how they're editing buffer content.

Scope of manipulated data

When dealing with typed arrays, we always work with a specific type of data. For example, using Uint8Array means that we only work with data range between 0 and 255.

Typed arrays are quite convenient when we work only with a single type of data per buffer. However, this is not the case if we want to write different types of data inside a buffer. It is still possible to use typed arrays for it, but the code becomes more tedious.

const buffer = new ArrayBuffer(10);
const u8Array = new Uint8Array(buffer, 0, 3);
const u16Array = new Uint16Array(buffer, 3, 3);

u8Array.fill(0xFF);
u16Array.fill(0xFFF);

// Prints Uint8Array {0: 255, 1: 255, 2: 255}
console.log(u8Array);

// Prints Uint16Array {0: 4095, 1: 4095, 2: 4095}
console.log(u16Array);

Using DataView is more convenient in such cases because you're not constrained by any particular type of data.

const buffer = new ArrayBuffer(10);
const view = new DataView(buffer);

view.setUint8(0, 0xFF);
view.setUint16(1, 0xFFFF);

You don't need to work with many abstractions and variables. ArrayBuffer and DataView are enough for this task.

The difference in how a data view and a typed array treat Endianness

If you're not familiar with Endianness, check out this section of the article on bits and bytes in JavaScript.

By default, typed arrays only work with the native Endianness of your platform. For example, if you have little-endian hardware, then typed arrays use little-endian byte order when working with typed arrays.

Most modern machines use little-endian bytes order. However, it doesn't mean there is no place for big-endian.

In this StackOverflow question user faces the problem where a big-endian WebGL file is interpreted in little-endian using typed arrays. It happens because the native system byte order is little-endian.

To solve the issues, we can use DataView. Data views allow you to change the way how the view treats the buffer byte order.

const buffer = new ArrayBuffer(10);
const view = new DataView(buffer);

view.setUint16(0, 0xFFF, true);

When we pass true as the third argument to DataView instance methods, it means that we intend to store the data in little-endian byte order. By default, DataView uses big-endian byte order to store the data.

Notice that methods which set 8-bit values like setUint8 and setInt8 don't have this flag. The reason is simple, there is only 1 byte, and the byte order is irrelevant in this case.

Conclusion

Views allow you to change the content of a buffer. There are two types of views: typed arrays and data views.

Data view is represented by the DataView class in JavaScript. There is only one class when it comes to data view, and through this class, we can set many different values for the buffer.

On the other hand, typed arrays are represented by multiple different class that differs by:

• Signed and unsigned type

• Number of bytes required to store a single buffer item

• Type of data stored like integers, floats, big integers

The difference between data view and typed array lies in how flexible you want to be when working with buffers. If you want to primarily work with a single type of data and ok without having much flexibility, then typed arrays are your choice.

On the other hand, if you need a more flexible solution or you want to work with different types of data inside a single buffer, then data views are the way to go.

It is a low-level abstraction that makes it possible to tap into efficient algorithms and direct memory management. There are no tools in JavaScript that offer the same level of low-level programming as buffers.

This article gives you the answer to the question, "Why do I need to learn buffers?" It walks you through how buffer works on a conceptual level and then goes into detail on how to use it in JavaScript.

Why you need to understand buffers

Buffers became an irreplaceable part of modern JavaScript. Some tasks simply can't be done without using them. Here are just a few areas where buffers play a crucial part.

Working with files

You might not realize it yet, but when you work with files in JavaScript, you work with buffers. Any file on your computer is just a set of 0s and 1s. In other words, it is a raw binary.

The File JavaScript class is just an abstraction over this raw binary to make things easier to deal with. Don't believe me? Let's create a file from absolute zero using ArrayBuffer as a raw binary base for a file.

const buffer = new ArrayBuffer(8);
const file = new File([buffer], 'new-file');

// File size - 8 bytes, File name - new-file
console.log(file.size, file.name);

You can even save this file on your computer.

Image, video, and audio processing

Buffers are irreplaceable when it comes to media file processing because you have access to the raw binary of a file. A raw binary contains a bunch of different information like compression method, color depth, metadata, etc.

The music-metadata library is a JavaScript for Node.js that allows you to get so much additional information from an audio file.

• Codec

• Bitrate

• Frame headers

And so much more. There is simply no ready-to-use API to get all this info except for the raw binary itself.

There is also the AudioBuffer class provided by the Web Platform. All audio data in the audio buffer is stored in the same old ArrayBuffer. How do we know that? Instances of the AudioBuffer class have a method called getChannelData , and it returns the underlying data as a typed array.

Network protocols

On the Internet, we communicate using different network protocols:

• Transmission Control Protocol (TCP)

• File transfer protocol (FTP)

• Hypertext transfer protocol (HTTP)

Notice that all mentioned protocols have a word related to transfer. But what do we transfer? The answer is raw binary. And you already know when there is a raw binary, there is a buffer.

One of the most popular WebSocket libraries, Socket.io, uses buffers heavily across the library. It also makes it possible to send a raw binary. There is no way to support such features without using buffers.

3D and 2D graphics, game development

3D and 2D graphics are never easy to get right. There are many things that you have to be aware of to make a good graphic or game. One of such is the texture. The texture is simply a surface of a model.

Source: https://3d-ace.com/3d-modeling/

You can clearly see the difference between a plain model on the left and a model with texture on the right. There are dedicated 3D libraries in JavaScript that make it possible to work with all the complexity of 3D graphics, and of course, they use buffers for it.

Here is an example of the DDS file format decompression abstraction provided by the BabylonJS library. It is a special file format for model textures. You can instantly notice one thing—it uses buffers a lot. The reason is simple: we're working with decompression of the raw binary.

Cryptography

One of the main requirements in the cryptography industry for code is speed and efficiency. Buffers in JavaScript offer exactly that:

• Buffers provide a way to represent fixed-length binary data, which is perfect for crypto keys, hashes, or encrypted data.

• It is possible to allocate memory more precisely and in smaller amounts for the same data using buffers.

• Working with the raw binary makes it easier to use bit-wise operators, which are faster than regular ones.

In the previous article about bits and bytes in JavaScript, we talked about how much space the V8 JavaScript engine allocates for numbers.

In short, it is either 31 or 64 bits. For numbers without a floating point number, the engine allocates 31 bits. But what if we only work with numbers from 0 to 255? It'll still use 31 bits per each number.

We can do it with almost 4 times less memory using a buffer.

// 92 bits for numbers + array.
const numbers = [1, 2, 3];

// 24 bits for numbers + typed array.
const u8Array = new Uint8Array([1, 2, 3]);

The Uint8Array uses ArrayBuffer under the hood to store the data. We'll talk about it in more detail in the upcoming article on buffer views.

JavaScript buffer is an abstraction

Buffer is an abstraction. This abstraction consists of two specific parts: memory chunk and handle to this memory.

Buffer can allocate a specific amount of memory and store the reference to this memory in JavaScript.

We're talking about direct memory allocation from a high-level language perspective that is supposed to abstract us from direct interaction from memory. Turns out it is not always possible.

The memory handle is the buffer JavaScript object we can directly interact with in our applications. If you're familiar with lower-level programming languages like C or C++, it looks pretty much like a safe version of a memory pointer.

JavaScript buffer representation—ArrayBuffer

We've talked about buffer structure and how it works in theory. The next step is to look at the particular buffer implementation in JavaScript. It is called ArrayBuffer.

The ArrayBuffer is a class that we use to create a buffer.

const buffer = new ArrayBuffer(4);

The number 4 we passed to the constructor indicates how many bytes you want to allocate in memory for this buffer. You can use the byteLength property to check if the buffer is of the right size.

const buffer = new ArrayBuffer(4);

console.log(buffer.byteLength); // Prints 4

By default, ArrayBuffer instances are immutable. We can't directly write any data inside the buffer. But what is the point of having a chunk of memory and not being able to work with it? That's why we have views.

A view is a mechanism that makes it possible to modify a buffer content. We'll talk about views in more detail in the upcoming article.

The only thing we can change when working with ArrayBuffer is the size. To do so, we have to specify the maxByteLength option. The option tells the buffer that it can't grow further than this number.

const buffer = new ArrayBuffer(4, { maxByteLength: 8 });

console.log(buffer.byteLength); // Prints 4

buffer.resize(8);

console.log(buffer.byteLength); // Prints 8

If you try to resize the buffer to more than 8 bytes, the resize function throws a RangeError saying that the value is invalid.

const buffer = new ArrayBuffer(4, { maxByteLength: 8 });

// RangeError: ArrayBuffer.prototype.resize: Invalid length parameter
buffer.resize(10);

Conclusion

Buffers are essential when it comes to low-level things like:

• Video, image, and audio processing

• 3D and 2D graphics and game development

• Cryptography

• Network protocols

• General work with files

A buffer is an abstraction that consists of 2 main parts: memory allocated for this particular buffer and JavaScript handle to the memory. Allocated memory for the buffer is not subject to garbage collection, but the JavaScript handle is. Whenever the JavaScript handle gets destroyed, it frees the allocated memory.

In JavaScript, the lowest possible abstraction of a buffer is called ArrayBuffer. It is an immutable structure that can't be directly modified. That's why we use views to modify a buffer.

Most of the time, you pay little attention to it because it doesn't directly affect your work. What if I tell you that it is the opposite that understanding what exactly UTF-8 and other UTFs mean directly impacts your job?

Just imagine that simply changing UTF-8 to UTF-16 increases your file size 2 times. Do you want to know why?

In this article, we'll dive into what the ASCII and UTFs are, how we're using them on a daily basis, and what problems misusing an encoding scheme can cause.

Bytes and characters

When you look at any text on modern devices, you see words. Each of those words consists of individual characters. Have you ever thought about what character is?

There are at least two major parts of it. The first one is "how" the character looks like. It could be the same character "A" but in different fonts or in the same font but in regular, bold, or italic variants.

The thing we see is called a glyph. Different fonts have different glyphs for the same character. You can compare a glyph to an application frontend. We can display the same value that comes from a backend in different shapes and forms. The same is true for a glyph.

But what is a backend in this case? Let's call it a character code. The character code is a unit of information that allows different glyphs to represent the same character.

In the previous article, we discussed bits and bytes, and how understanding them can help you write better JavaScript code.

We can apply this knowledge directly to characters to understand them better. Each character you see on the internet has the actual size in bytes. Knowing how many characters a file contains makes it easy to calculate file size. If there are 1,000,000 characters and each character takes 1 byte to store, then the file size is 1,000,000 bytes or 1 megabyte.

Another application of this knowledge is related to the binary numeric system and how bytes can be represented in binary. Here is an example of how a single byte is represented in a binary numeric system - 11111111. Any eight binary numbers represent a single byte value.

A character code can be represented in a binary numeric system as well. Here is how the popular "Hello world" phrase looks in binary.

01101000 01100101 01101100 01101100 01101111 00100000 01110111 01101111 01110010 01101100 01100100

You can tell how many bytes are there by counting groups of 8 characters. In this case, there are 11 groups, which means there are 11 bytes.

When dealing with binary, context is the king. Context is what makes the difference between just 0s and 1s and commands of some programming language or a file. An encoding scheme is a context that allows us to turn a set of binary numbers into a human-readable phrase.

The encoding example of the “Hello world” phrase into its binary representation actually uses one of those schemes called American Standard Code for Information Interchange (ASCII).

From ASCII to Unicode

ASCII is an encoding scheme formalized in 1967. It remains one of the most significant, if not the most significant, standards in the tech industry. The reason is simple: it is the first widespread encoding standard specifically developed for the tech industry.

ASCII has two versions: the base version, which contains 128 characters, and the extended version, which contains 255 characters. Both nicely fit in 8 bits or one byte of information.

This is how you encode “A”, “9”, and “/” characters in ASCII.

As the name suggests, the encoding was developed in the US and designed specifically for English. 255 characters are enough to encode most English words and sentences.

In fact, ASCII became so popular that people from other countries started using it. But you can’t use English-based standards for other languages encoding that easily because of the limited characters set.

Trying to solve the problem of limited ASCII characters set, people have created supersets of ASCII like Japanese Industrial Standard (JIS) to be able to use the popular format with customizations for their needs.

However, the problem was clear: ASCII is too limited. In 1988, the successor of ASCII was created, called Unicode.

Unlike ASCII, Unicode was initially developed as a 2-byte encoding. In the extended version, 1-byte ASCII can encode up to 255 characters, while 2-byte Unicode can encode 65,536 characters.

That’s a decent leap. This version of Unicode allows the encoding of most of the widely used characters in the most popular languages.

A unique feature of Unicode is its extendability. It is not a fixed standard, and adding new languages can be easily achieved if there is a demand.

Unicode

Unicode is an engineering masterpiece. Let’s look closely at what makes it so unique and why it became so important.

Backward compatibility with ASCII

One of the main goals of creating Unicode was to create a standard for encoding a vast amount of different information. The goal has been achieved.

At the time of Unicode's creation, a lot of information was produced using ASCII. It wasn’t an option to just drop support of everything people had created so far and adopt a new standard.

That’s why the first 128 characters of Unicode are the same as ASCII characters. This makes Unicode backward compatible with ASCII, and the transition from ASCII to Unicode is seamless.

Unicode's transformation format

Unicode was initially developed as a 16-bit or 2-byte encoding standard. This amount of information was enough to encode most of the popular languages.

However, it is not enough to encode all possible information. Old scriptures, dead languages, and emojis are just a few examples of information missing from the initial standard. That’s why it is now not a 16-bit encoding but a 21-bit encoding and has more room for growth if needed.

What it means is that every character in a text is encoded using 21-bit.

But what if your text is in plain English, contains no special characters, and can be encoded using the first 128 characters of Unicode? It would be nicer to encode it in ASCII, where each character takes only 8 bits and 2.5 times less space to store.

Unicode is a flexible encoding, and thanks to different Unicode transformation formats, or UTFs, you can encode text using different numbers of bits. There are three major formats: UTF-8, UTF-16, and UTF-32. The number indicates how many bits are used to encode and store a single character.

You can use UTF-8 for plain English text. It takes exactly 8 bits to store every character in this encoding. But what if your text contains some character beyond the scope of the first 128? You can still use UTF-8 because it is a flexible standard, and depending on the character, it allocates a dedicated space to store the character.

In this example, we use UTF-8 to encode all characters. Each character in the word “Hello” is encoded using only 1 byte. However, the Thai Ko Kai (ก) character is encoded with 3 bytes using the same encoding scheme.

However, Thai characters don't always occupy 3 bytes of memory to store. When using UTF-16, each character takes only 2 bytes to store.

That’s why UTF-16 and UTF-32 transformation formats are still valuable and not going anywhere despite vast UTF-8 adaptation.

If you know that the text you’re dealing with is fully written in Thai, it doesn’t make sense to use UTF-8 as encoding. It will work, but it also takes ~30% more space than using UTF-16.

It works in another direction as well. Using UTF-16 for text in plain English makes It is two times larger in byte size than using UTF-8 because each character is encoded with at least 2 bytes.

Code point and Code unit

Each character in Unicode has a unique numerical identifier. Such a unique identifier is called a code point.

Every code point is unique, despite the UTF you’re working with. Every code point is written in the following format: U+XXXX where XXXX is a hexadecimal number. The range of unique code points goes from U+XXXX to U+10XXXX. For example, the code point for the character “A” has code U+0041.

While a code point is related to all Unicode characters despite their UTF, a code unit is specific to a particular UTF. Depending on the encoding, a code point may be represented by one or more code units.

Unicode planes

When Unicode was first introduced in the 1980s, its creators believed that 65,536 code points would be enough to encode all the world's popular writing systems.

This initial set of code points is now known as the Basic Multilingual Plane (BMP). BPM contains characters you use every day, including Latin letters, common symbols, and characters from widely used non-Latin scripts.

However, as the standard progressed, it became clear that more space would be needed. In Unicode 2.0 (1996), supplementary planes were introduced, expanding from one multilingual plane to 17.

Each plain contains 65,536, which extends the initial capacity to 1,114,112. This expansion was crucial for several reasons:

• Accommodating complex writing systems: Scripts like Han (used in Chinese, Japanese, and Korean) required far more characters than initially anticipated.

• Future-proofing: The additional planes provided room for newly discovered historical scripts and potential future writing systems.

• Special-purpose characters: Planes were allocated for technical symbols, emoji, and private-use characters.

The introduction of supplementary planes marked a significant milestone in Unicode's development, transforming it from a limited character encoding system to a comprehensive standard capable of representing virtually all known writing systems.

UTF encoding and JavaScript

Now, it is time to look at encodings in the context of JavaScript.

JavaScript internally uses UTF-16 encoding for strings. I mean for any string, even if the string came from a file, network, or anywhere else. If the string somehow comes into the JavaScript world, be sure that it is always encoded using UTF-16.

It is just a specification requirement, and we can do little about it. The positive side is that things just get simpler. We work with one encoding and one encoding only.

If we decide to create a variable that represents an error message and the error message text is 20 characters long, you can be sure that the size it takes to store this string is precisely 40 bytes.

// The variable string content occupies 40 bytes of memory
const errorMessages = 'Something went wrong';

At the same time, there is a way to encode a string in JavaScript using less memory. It is possible to do so only using buffers.

// "Sun" string encoded in hexadecimal numeric system
const buffer = new Uint8Array([0x53, 0x75, 0x6f, 0x6e]);

// The default decoding scheme is UTF-8
const decoder = new TextDecoder();

console.log(decoder.decode(buffer)) // Prints "Sun";

You don't need to understand the whole buffer workflow just yet. We'll talk about it in a future article.

The string that we get from the decoder.decode() function is in UTF-8 encoding before it gets to JavaScript, after that it gets UTF-16 encoded again. It happens because of how the API and the whole buffer thing work.

The interesting thing is if we mismatch the type of encoding and decoding schemes, we'll get completely unexpected results.

The data we save in the buffer is the same, and the type of buffer is the same, but the decoding scheme is different. Because of that, we're getting a completely unexpected result.

Conclusion

ASCII and UTFs are encoding schemes that allow text information to be shared across different machines and the Internet without losing any information.

With Unicode, we can encode up to 1,114,112 characters that are more than enough for the foreseeable future. The Unicode standard consists of multiple parts, such as Code points, code units, planes, etc.

Unicode's transformation formats (UTFs) provide the ability to encode the same exact text using different schemes.

Internally, JavaScript uses UTF-16 for all strings. However, it doesn't mean we can't use different encodings to store strings in a format that we want.

You have to be mindful when working with different encodings because using mismatching encoding and decoding schemes can lead to unexpected results.

This article will explain the basics of bits and bytes and how computers use them. After that, you'll see why it is important to understand this topic and how to apply this knowledge in JavaScript.

Bit

In the previous article, we learned about different numeric systems, how they can be used, and why we need them. One of the numeric systems was the binary numeric system.

The binary numeric system has only two numbers: 0 and 1. At its most fundamental level, everything on your computer is just 0s and 1s. Only two numbers are enough to build any software you can imagine.

This is possible because the combination of 0 and 1 is considered the smallest and fundamental unit of information, also known as bit.

For example, with only one bit, you can represent the following information:

• To conclude, whether some statement is true or not. It is either true or false.

• To answer if somebody asks you for a donation. It is either yes or no.

• To sign an agreement. You either sign—agreeing with it or don't sign.

All the above examples have only two possible outcomes, which are 0 or 1. True or false.

One of the interesting aspects of a bit is that the meaning of a particular bit is completely contextual. The same bit in different contexts means completely different things.

Let's continue with the signature example. Writing your signature on a blank piece of paper has little value because there is no context to it. If you leave your signature under the employment contract, it means that you accept all contract conditions. Leaving the same signature under a bank check makes this check valid for cashing.

You see how the information is the same in all three cases. However, the interpretation of this information is completely different and solely depends on the context.

Having said that, you can convey only a tiny amount of information using one bit. If you want to know where three of your friends donated to a charity, you can use 3 bits for it:

Notice, there are no complex decision trees or anything like that. It is a simple true or false answer.

Byte

The byte is a group of 8 bits. It was introduced to deliver more information in a standardized way. Byte simplifies the abstraction in the same way as plain numbers do. Imagine if you have one million pens. What a nice word, a million. It wouldn't be that easy to operate with it if you were to represent the number as one thousand thousand, right?

A byte has a range of possible values, starting from 00000000 to 11111111 or 256 decimal values ranging from 0 to 255.

A single byte is enough to store most English letters. We can introduce an additional byte when it is not enough, like in the case of the Chinese language. With two bytes, you have 65,536 possible options to encode a character. We'll talk more about encoding in the next article.

Another common use case of a byte is color, particularly RGB (red, green, blue) color model. A single byte represents each letter in the RGB model, or 3 bytes for the final color. Only 3 bytes make it possible to have 16,777,216 different colors.

When talking about computers, there are displays with different color models; some of them are RGB displays. Every pixel in such displays takes the exact 3 bytes for an RGB color.

Bytes and memory

Now we know that bit is the smallest unit of information possible, and a single byte is a group of 8 bits. One of the practical applications of this knowledge is related to files and file systems on a computer.

A text file? Depending on the encoding, each letter could take one, two, or three bytes.

An image? Images are composed of pixels, and every pixel is basically a set of bytes. The exact number of bytes required to store a single pixel heavily varies on a color model.

Every byte of a text file, image, video, audio, etc. is directly stored on your computer. When you download a file, it shows you its size so you can understand how much space it takes on your computer.

It is the fundamental concept, and every operating system works in the same way. What is different, though, is the order in which bytes are stored. The concept describing the byte order is called endianness.

There are two types of endianness: big-endian and little-endian. Big-endian stores the most significant byte first. The most significant byte is the one that plays the most significant role in a piece of data.

For example, ISO date (2060-10-22) follows the big-endian because the year, the most significant part of the date, is placed in the first place, followed by months, and only then the day of the month—the least significant number.

On the other hand, if you take a look at the standard European way of writing dates (24 July 2060), you'll see that it follows the little-endian. The least significant number—the day of the months—is first, followed by the number of months, and only then goes the year.

Why choose hexadecimal over binary

Here is how an encoded text looks in the binary numeric system.

01001000 01100101 01101100 01101100 01101111 00100000 01110111 01101111 01110010 01101100 01100100 00100001

The code above uses ASCII/UTF-8 encoding. When you decode the binary to a string, you'll see "Hello world!" But what if we have more than two words? The binary gets massive fast. To address this problem, you can use a hexadecimal numeric system instead.

Here is how the same text is encoded in hexadecimal:

48 65 6c 6c 6f 20 77 6f 72 6c 64 21

It is 4 times shorter, but the meaning is the same.

The other nice thing about binary-to-hexadecimal conversion is that every byte can be represented by only two hexadecimal numbers. The smallest possible value of a byte 00000000 is written in hexadecimal as 00, and the highest possible value of 11111111 is just FF.

The short alternative to binary is the exact reason why hexadecimal has become so widely used.

Why knowing bits and bytes is useful for a JavaScript developer

It is all nice and interesting, but how do you actually apply this knowledge as a JavaScript developer in your work?

Bitwise operations

Bitwise operators are common when it comes to working with:

• Cryptography

• Different kinds of 2D and 3D graphics

• High-performance operations when dealing with large datasets

They're meant for specific tasks, and you won't use them that often. At the same time, sometimes implementing a feature without using bitwise operators is hardly possible.

Understanding memory consumption by different language structures

Each structure in JavaScript language takes up a specific size in memory. Understanding the bit and byte concept allows you to write memory-efficient programs.

The actual size of any given structure depends on specific JavaScript engine implementations. We'll look at how V8, the most popular engine, allocates memory for some of the commonly used JavaScript structures.

Strings. Every character in JavaScript is encoded in UTF-16. It means that 2 bytes are required to store a single character. For example, the "hello" string consists of 5 characters and takes 10 bytes or 80 bits of memory.

Numbers. The allocated memory depends on what type of number you're dealing with. It's either 31-bit signed or 64-bit with double precision point.

Booleans. For the sake of simplicity, a boolean takes 1 byte.

Working with files, blobs, and buffers

Any file on your computer is just a set of bytes. Dealing with a file is the equivalent of dealing with a set of bytes.

It is one of the most common operations in JavaScript. We build applications where users can upload files, download files, and sometimes change files. Change their name and their encoding format, and compress or decompress them.

We usually use blobs and buffers for operations on files. Performing efficient operations over files requires a proper understanding of bits and bytes.

Conclusion

A bit is the building block of all digital information. It is the smallest unit of information possible, represented by only two numbers, 0 and 1.

A byte is an abstraction created to work with a large number of bits. A single byte is a set of 8 bits.

For JavaScript developers, understanding bits and bytes isn't just theory. It has real, practical uses:

• Bitwise operations for tasks like cryptography

• Optimizing how much memory your app uses

• Working with files, blobs, and buffers efficiently

In our next article, we'll explore different encodings, showing how bits and bytes come together in Unicode, the most widely used encoding scheme.

Why bother with different numeric systems? Different numeric systems help us operate more effectively in areas like cryptography, 3D development, and binary manipulations.

This article dives into the details of these numeric systems, explaining their purpose, usage, and how they can be used in JavaScript.

Concept of an abstract number

Before discussing the details of each numeric system, let’s first focus on what numbers are and how we use them.

Imagine that you see three oranges.

If someone asks you, “How many oranges are there?” Your answer is obvious: three.

Imagine a different scenario. You’re living in Spain and can only speak Spanish. If someone asks you, “How many oranges are there?” in Spanish, you’ll answer: tres.

The abstract concept of 'the number of oranges' remains consistent across languages, as the meaning is the same in both English and Spanish. However, this abstraction is represented differently in each language.

Different languages use different names for the same numbers. But at least we have the numbers that are common across all languages and always mean the exact same thing, right? Not really.

In addition to different languages, we have different numeric systems. A simple number 3 in a decimal system is represented differently in a binary system. In binary, it is 0011. Similar to English and Spanish, both 3 and 0011 represent the same abstract concept.

The reason people use different numeric systems is the same as why they use different words for the same number in different languages. Working and operating with them in certain cases is simply more convenient.

Notice that the previous two pictures don’t capture the essence of the abstract number behind them. A more appropriate representation of an abstract number would be something like this.

Numeric systems

Numeric systems are like different human languages. We use them in certain situations to understand and to be understood.

For example, at the lowest hardware level, computers talk in binary. Using decimals just won’t get you anywhere in the same way as using English to communicate with some Amazon forest tribe.

The good part? Numeric systems are not as complex as languages. It is quite easy to go from one numeric system to another, even using only pen and paper. With the power of a computer, you become a fluent speaker of different numeric systems.

There are a lot of different numeric systems, but the most popular are the following four:

• Binary

• Octal

• Decimal

• Hexadecimal

Likely, you won’t need to use any other numeric systems at all. That’s how popular these four systems are.

Notice, unlike human languages, which are usually tightly bound to a particular place where some group of people lives, numeric systems are all about the “base.” The base is basically how many numbers a particular system has.

For example, a binary system has a base of 2 because it uses only two numbers: 1 and 0. In decimal, we have 10 numbers starting from 0 to 9. The higher the base is, the more numbers there are.

Another interesting thing to mention is that a particular system doesn’t contain a number that is equal to or higher than the base of the system. In binary, we don’t have 2, and octal doesn’t include 9.

Next, we’ll look at each of the four numeric systems in more detail.

Binary system

The binary numeric system is the lingua Franka of computer hardware. It uses only two numbers, 1s and 0s, and surprisingly, it is enough to do the job.

Here is an example of how you count to 5 in binary:

0 0 0 1 - one

0 0 1 0 - two

0 0 1 1 - three

0 1 0 0 - four

0 1 0 1 - five

You might notice the strange zeros that go before the actual number. They are called leading zeros. We use them just to make numbers more readable. Putting any number of zeros at the start of the number does not change the actual value.

Octal system

The octal system was used in the past for computers and programming languages like PDP-8. Although there are not many use cases for it at this point, that doesn’t mean there are none. For example, the Unix file permissions mechanism is based on the octal numeric system.

Here is how you count from 6 to 10 using the octal system:

6 - six

7 - seven

10 - eight

11 - nine

12 - ten

Unlike binary, where we go to 10 straight after 1, it happens after 7 in octal. Remember, a numeric system doesn’t contain a number equal to or higher than the system base. That’s why the octal system doesn’t include the number 8.

Decimal system

The decimal numeric system is the one we all use daily. It is the most used numeric system in human-to-human interaction. Unlike other popular numeric systems, it is the only one that wasn’t the product of human-to-computer interaction but emerged in human-to-human interaction.

It is not the only one of a kind. Before that, people were using systems like the Roman numeric system or the Sexagesimal (has 60 numbers) numeric system, which was used by the ancient Sumerians, and we’re still using it (remember how many seconds in a minute).

As the name suggests, it operates with ten numbers starting from 0 and up to 9.

Hexadecimal system

The hexadecimal numeric system (hex) is widely used in software engineering. Here are just a few examples of where you can encounter it:

• CSS colors. One of the most popular color notation in CSS is the hex notation. As an example, FFFFFF represents the black color.

• Memory addresses.

• UUID.

• MAC address.

• And, of course, error codes.

The hex numeric system includes 16 digits from 0 to F. Here is how you count from 9 to 13 in hex:

9 - nine

A - ten

B - eleven

C - twelve

D - thirteen

Notice that every number from 0 to 15 has a dedicated digit, unlike decimal, where we write ten as 10 instead of A.

Working with different numeric systems in JavaScript

After getting familiar with the most popular numeric systems, the next question is, “How do we use them in JavaScript?”

JavaScript provides specific prefixes to make the interpreter understand what numeric system we want to use. Let’s look at how we can write the number 13 in different systems using JavaScript:

• Binary: 0b1101

• Octal: 0o15

• Decimal: 13

• Hexadecimal: 0xD

Notice that for all four numeric systems except decimal, we add a specific prefix starting from 0 and followed by the letter specific to that numeric system. Leading 0 tells the interpreter to treat the value as a number; otherwise, it treats the value as a variable.

If you want to work with different numeric systems, JavaScript supports up to 36 base numeric systems. Be aware that using any non-standard (not binary, octal, decimal, or hexadecimal) numeric system may limit any mathematical operations. The only way to perform math operations with other numeric systems is through conversion to decimal and back. One way to convert a 36-base number to decimal is to use the parseInt function.

parseInt(‘ZAE’, 36); // results to 45734

Here is an example of implementing a function to sum a number with a base of 36.

function base36ToDecimal(base36Number) {
  return parseInt(base36Number, 36);
}

function decimalToBase36(decimalNumber) {
  return decimalNumber.toString(36).toUpperCase(); // Ensure uppercase
}

function sumBase36(num1, num2) {
  const decimalSum = base36ToDecimal(num1) + base36ToDecimal(num2);
  return decimalToBase36(decimalSum);
}

Conclusion

Understanding different numeric systems is a valuable skill for any developer. It goes beyond how computers process numbers; it's about how we, as developers, can communicate and work with data more effectively.

Knowledge of different numeric systems is fundamental and opens a number of opportunities, such as handling specialized data formats, working with low-level programming, buffers, etc.

Next, we'll take a closer look at the building blocks of digital data—bits and bytes—and how you can directly manipulate them using JavaScript.

The experience is completely different from DevtTools. While the developer tools provide a wealth of information, it is not always presented in a comprehensible way, and it is not always clear where to start.

In this article, you’ll learn how to use Clinic to profile Node.js applications, focusing on three common problems during development: high CPU consumption, memory leaks, and unoptimized asynchronous operations.

Setup

To see profiling in action, we need some code. For this purpose, I created a GitHub repository with all the basic scenarios we run into during day-to-day development.

The repository contains an application that starts an HTTP server with three routes. Each route has one specific problem.

In this particular setup, those problems are:

• CPU-intensive task, which blocks the main thread.

• Asynchronous operation with a waterfall problem (the execution goes one by one instead of parallel).

• Memory leak.

Each route has two implementations. One contains a problem that we should be able to spot with the DevTools, and the other is an optimized version with the same functionality.

Profiling

Clinic is a dedicated profiling tool for Node.js, designed with a single goal in mind: to provide the best developer experience (DX) possible when profiling Node.js applications.

To start using Clinic, follow the getting started guide. Install it locally in your project with:

npm install clinic

Or, if you prefer to use Clinic from the CLI, install it globally:

npm install -g clinic

Clinic offers 4 profiling tools:

• Doctor: Provides a high-level overview of the application and its processes.

• Bubbleproof: Troubleshoots asynchronous issues.

• Flame: Visualizes CPU usage with flame graphs.

• Heap Profiler: Identifies memory leaks.

We’ll use all four to discover three different types of problems.

CPU-intensive endpoint

We start with the CPU-intensive endpoint. Here are the implementations:

Solution with high CPU consumption

function runCpuIntensiveTask(cb) {
 function fibonacciRecursive(n) {
   if (n <= 1) {
     return n;
   }
   return fibonacciRecursive(n - 1) + fibonacciRecursive(n - 2);
 }

 fibonacciRecursive(45);
 cb();
}

Solution with low CPU consumption

function runSmartCpuIntensiveTask(cb) {
 function fibonacciIterative(n) {
   if (n <= 1) {
     return n;
   }

   let prev = 0, curr = 1;

   for (let i = 2; i <= n; i++) {
     const next = prev + curr;
     prev = curr;
     curr = next;
   }

   return curr;
 }

 fibonacciIterative(45)
 cb();
}

Both versions calculate the 45th Fibonacci number. The first implementation uses a recursive, CPU-intensive approach, while the second one employs an iterative, more efficient approach.

The best way to start a profiling session with Clinic is to use Doctor. Doctor provides an overview of the application and its processes and can redirect you to more specific tools like Bubbleproof if needed.

Here’s how to use Doctor for profiling:

clinic doctor – node app.js

This command starts a Node.js application from the specified file (in this case, app.js). It behaves like a regular application with one exception: Doctor monitors the application and related resources.

You’ll see a similar message in the console:

Notice that in order to generate the final profiling report, you have to terminate the running process.

After calling the CPU-intensive endpoint, terminate the process. There will be a dashboard similar to this one.

It contains an alert at the very top of the page.

This message clearly shows that we have problems with the CPU and event loop. Indeed, the charts related to these two resources indicate exactly the same thing.

At the very bottom, there is a recommendations section. You can click on it to see detailed, human-readable recommendations on what this problem is about and what you can do next.

Doctor says there are some CPU-related problems. It also redirects you to Flame or Bubbleprof tools for further analysis. Let’s do as Doctor suggests and use Falme.

clinic flame – node app.js

Sending a request to the same CPU endpoint and terminating the process generates the flame graph.

From this graph, it is evident that fibonnaciRecursive takes the most time.

After changing the endpoint implementation to a more effective one, we run the same Flame tool again. The results are drastically different.

Let’s see what Doctor says.

The picture is not even close in terms of CPU usage and event loop delay.

Async endpoint

Next, let's look at the async endpoint. Here are both implementations of the endpoint:

Solution with async operations waterfall

function generateAsyncOperation() {
 return new Promise(resolve => {
   setTimeout(() => {

     // Simulate heavy async operation
     for (let i = 0; i < 50000000; i++) { }
     resolve();
   }, 1000);
 });
}

function runAsyncTask(cb) {
 await generateAsyncOperation();
 await generateAsyncOperation();
 await generateAsyncOperation();
 cb();
}

Solution without async operations waterfall

function generateAsyncOperation() {
 return new Promise(resolve => {
   setTimeout(() => {

     // Simulate heavy async operation
     for (let i = 0; i < 50000000; i++) { }
     resolve();
   }, 1000);
 });
}

async function runSmartAsyncTask(cb) {
 await Promise.all(new Array(3).fill()
   .map(() => generateAsyncOperation()));
 cb();
}

We’ll start profiling the async endpoint with Doctor.

Although the graphs look fine, an error message suggests further investigation. Let’s delve into the details.

Doctor recommends using Bubbleproof to troubleshoot async issues further. Let’s follow that advice.

clinic bubbleproof – node app.js

Running the same async endpoint generates a report showing three consecutive operations. Each purple line represents an async operation, with additional details available for exploration.

This visualization clearly illustrates the waterfall problem in async operations. Now, let's switch to the optimized route handler. We'll replace runAsyncTask with runSmartAsyncTask and rerun the workflow.

The new graph looks much better, showing only a single call to the async operation. This is exactly the result we want.

The optimized graph now contains only a single call to the async operation, eliminating the inefficiencies of the waterfall problem.

Memory leak endpoint

Here's the code for both scenarios:

Solution with memory leak

const memoryLeak = new Map();

function runMemoryLeakTask(cb) {
 for (let i = 0; i < 10000; i++) {
   const person = {
     name: `Person number ${i}`,
     age: i,
   };

   memoryLeak.set(person, `I am a person number ${i}`);
 }

 cb();
}

Solution without memory leak

const smartMemoryLeak = new WeakMap();

function runSmartMemoryLeakTask(cb) {
 for (let i = 0; i < 10000; i++) {
   const person = {
     name: `Person number ${i}`,
     age: i,
   };

   smartMemoryLeak.set(person, `I am a person number ${i}`);
 }

 cb();
}

In the first function, runMemoryLeakTask, we use a Map to store objects, which prevents them from being garbage collected, causing a memory leak.

In the second function, runSmartMemoryLeakTask, we use a WeakMap, which allows garbage collection of the keys when they are no longer referenced elsewhere.

We need a different approach for memory profiling because Clinic Doctor doesn’t provide enough information in this case. Instead, we’ll use the heap profiler right away.

Here’s how to run the heap profiler:

clinic heapprofiler – node app.js

After profiling the unoptimized memory leak endpoint, we see the following:

The function with a memory leak consumes more than half of the allocated memory. This is easy to spot due to the large space it occupies in the profiler.

Now, let’s run the optimized function and see the difference.

The result is clear: the memory leak has been resolved, as the large memory-consuming function is no longer present.

Conclusion

Clinic is a powerful tool for profiling Node.js applications, offering clear and human-readable diagnostics through Doctor.

Its dedicated tools for async, I/O, and memory profiling make it invaluable for addressing various performance issues. By using Clinic, you can efficiently identify and resolve problems, ensuring your applications run smoothly and effectively.

Why? Because both Chrome and Node.js use V8, the DevTools are designed to work with V8, its memory heap, performance metrics, and more. From this perspective, it looks like a shiny start.

In this article, you’ll learn how to use DevTools to profile Node.js applications, focusing on three common problems during development: high CPU consumption, memory leaks, and unoptimized asynchronous operations.

Setup

To see profiling in action, we need some code. For this purpose, I created a GitHub repository with all the basic scenarios we run into during day-to-day development.

The repository contains an application that starts an HTTP server with three routes. Each route has one specific problem.

In this particular setup, those problems are:

• CPU-intensive task, which blocks the main thread.

• Asynchronous operation with a waterfall problem (the execution goes one by one instead of parallel).

• Memory leak.

Each route has two implementations. One contains a problem that we should be able to spot with the DevTools, and the other is an optimized version with the same functionality.

Profiling

To start using DevTools with Node.js, we must run our server using the Node.js inspector.

node --inspect app.js

In short, the inspector provides the ability to interact with the V8 inspector.

After that, type chrome://inspect in your browser's search bar. You should see the following page:

Click the “Open dedicated DevTools for Node” button. You’ll see the DevTools connected to the node process you’re running.

To measure the performance of the connected Node.js app, you go to the “Performance” tab and click the “Record” button.

After that, you’ll see the dialog indicating profiling status. You can stop it at any time by clicking the “Stop” button.

Now, let’s see how it works with the prepared endpoints.

CPU-intensive endpoint

We start with the CPU-intensive endpoint. Here is what both implementations of the endpoint look like.

Solution with high CPU consumption.

function runCpuIntensiveTask(cb) {
 function fibonacciRecursive(n) {
   if (n <= 1) {
     return n;
   }
   return fibonacciRecursive(n - 1) + fibonacciRecursive(n - 2);
 }
 fibonacciRecursive(45);
 cb();
}

Solution with low CPU consumption.

function runSmartCpuIntensiveTask(cb) {
 function fibonacciIterative(n) {
   if (n <= 1) {
     return n;
   }
   let prev = 0, curr = 1;
   for (let i = 2; i <= n; i++) {
     const next = prev + curr;
     prev = curr;
     curr = next;
   }
   return curr;
 }
 fibonacciIterative(45)
 cb();
}

Both versions calculate the 45th Fibonacci number. The first implementation uses recursion, and the second one employs the iterative approach.

After running the CPU-intensive endpoint with the implementation that consumes a lot of CPU, you see the following picture.

The breakdown of activities.

It is clear that the fibonacciRecursive function takes more than half of the execution time. This means that more than half of the time, the application exclusively works for the single function of a single request. This should be optimized.

The picture radically differs when we use the improved version with the same functionality.

It is barely noticeable. In the activity tab, we have the following picture.

The difference is enormous. We no longer block the main thread and consume way less CPU resources than before. It's definitely a win.

Async endpoint

Next on the list in the async endpoint. Here is what both implementations of the endpoint look like.

Solution with the waterfall effect.

function generateAsyncOperation() {
 return new Promise(resolve => {
   setTimeout(() => {
     for (let i = 0; i < 50000000; i++) { }
     resolve();
   }, 1000);
 });
}

async function runAsyncTask(cb) {
 await generateAsyncOperation();
 await generateAsyncOperation();
 await generateAsyncOperation();
 cb();
}

Solution with parallel execution.

function generateAsyncOperation() {
 return new Promise(resolve => {
   setTimeout(() => {
     for (let i = 0; i < 50000000; i++) { }
     resolve();
   }, 1000);
 });
}

export async function runSmartAsyncTask(cb) {
 await Promise.all(
   new Array(3).fill().map(() => generateAsyncOperation())
 );
 cb();
}

The result of the waterfall async function is that you see three spikes with intervals around 1000ms or one second. This means a function runs only after the previous one has finished running.

Since those are all async operations, we’re interested in a total execution time rather than non-blocking behavior. Each async request took around 1 second, and because of the waterfall effect, the function took 3 seconds to finish.

With the improved version, we have the following picture.

There was only one spike. Processing those three requests took the same time, but they are now running in parallel rather than one by one.

Memory leak endpoint

Here is what the code for both cases looks like.

Solution with a memory leak.

const memoryLeak = new Map();

export function runMemoryLeakTask(cb) {
 for (let i = 0; i < 10000; i++) {
   const person = {
     name: `Person number ${i}`,
     age: i,
   };
   memoryLeak.set(person, `I am a person number ${i}`);
 }
 cb();
}

Solution without a memory leak.

const smartMemoryLeak = new WeakMap();

export function runSmartMemoryLeakTask(cb) {
 for (let i = 0; i < 10000; i++) {
   const person = {
     name: `Person number ${i}`,
     age: i,
   };
   smartMemoryLeak.set(person, `I am a person number ${i}`);
 }
 cb();
}

All previous measurements were made using the performance tab inside DevTools. The memory tab also allows us to measure memory consumption.

You can find it right next to the performance tab.

There are three different approaches to this profiling.

We’ll choose the second option, “Allocation instrumentation on timeline.” That way, you’ll be able to see the memory consumption timeline, which is similar to the performance tab.

To start the profiling session, click the profile button at the top left corner.

First, we’ll send four requests to the memory leak endpoint with unoptimized implementation and record them using the profiler. You can clearly see four memory spikes on the timeline afterward.

The total size of the program is 11.5MB.

Below the timeline, you’ll see a table representing what is taking up the space.

While it is clear we have a lot of things going on here, like ~40,000 objects, it isn’t clear where they originate from. To find this connection, we’ll go back to the timeline and click the following selection.

You’ll see the “Allocation” option in the list. Choose it. Now you see the root of the problem.

It is the runMemoryLeakTask function that occupies most of the space. Let’s change it and run the optimized version instead with the same four requests. The result is impressive.

You can barely see requests except for the first one. The overall program size is reduced from 11.6 MB to 4.8 MB. It is ~2.5x less memory consumption.

Conclusion

The DevTools are amazing. They give you a wealth of information about CPU usage, detailed memory heap allocation, network communication, and much more.

While it provides everything you need in terms of information about everything that is going on inside the application, wouldn’t it be better if someone did the initial job of interpreting those results and giving you more human-readable instructions on what to do next?

That is what Clinic.js is all about. We’ll review it in the upcoming article.

At least because it is precise. The module uses a monotonic clock that allows you, as a user, to make performance measurements and be sure that they are not corrupted.

At first, I struggled to understand how it works. It is an abstraction, and as with any abstraction, you need to put in extra effort to understand it. Existing materials didn’t help much with it.

The key to understanding performance hooks lies in understanding its underlying mental model. This article will provide an overview of the module's core concepts and a detailed explanation of how they relate to each other. By the end, you'll know how the performance hooks work.

Mental model

It’s important to understand the underlying mental model to use performance hooks well. This section will explain the basic concepts behind performance hooks. With this knowledge, you can use them more effectively.

Clocks

Let's start by exploring the different types of clocks used in performance measurement. In this context, a "clock" is an abstract representation of how we perceive time.

The first type is the wall clock. The W3C specification defines it as follows:

The wall clock's unsafe current time is always as close as possible to a user's notion of time. Since a computer sometimes runs slow or fast or loses track of time, its wall clock sometimes needs to be adjusted, which means the unsafe current time can decrease, making it unreliable for performance measurement or recording the orders of events. The web platform shares a wall clock with [ECMA-262] time.

In essence, the wall clock aligns with a user's perception of time, including system time adjustments and time zones. However, it operates independently of any specific process or user. Even if a JavaScript program using the wall clock stops, it continues to run.

The second type is the monotonic clock. The documentation describes it as:

The monotonic clock's unsafe current time never decreases, so it can't be changed by system clock adjustments. The monotonic clock only exists within a single execution of the user agent, so it can't be used to compare events that might happen in different executions.

Unlike the wall clock, the monotonic clock doesn't adjust to a current user. It exists only within a specific context, such as a single execution of a Node.js process.

The performance hooks module uses the monotonic clock. Why?

Because measurement accuracy is important, a wall clock is prone to user-specific time changes, like system time adjustments, especially during performance measurements.

Additionally, the monotonic clock offers higher precision than the wall clock, making it ideal for performance measurement.

Performance Timeline

The concept of a Performance Timeline often confuses people due to a lack of clear explanations. Let’s end it right here and clarify some things about the topic.

In this context, a timeline is simply a sequence of events occurring over a specific period of time.

It's called a "performance timeline" because these events are specifically related to performance. These performance-related events are known as performance entries, which we'll discuss later.

The performance timeline concept is a mental abstraction. No code backs it up. Some events within the timeline can be buffered (stored temporarily) for later analysis. However, not all of them can be buffered. Therefore, those buffered events are not complete representations of the timeline but some part of it.

Performance entries

Performance entries represent the events that happen during program execution. Node.js provides the following types:

• Mark

• Measure

• Resource

• Node

The first three types (Mark, Measure, and Resource) are defined by the W3C specification, which Node.js aims to adhere to closely.

The fourth type, Node, is specific to Node.js. It's an abstract type that combines net, dns, gc, http, http2, and function.

The abstract Node types include many different performance entry types for the following two reasons:

• They are all created only after some action is finished. For example, if a function finishes the execution or if we do a DNS lookup, the performance entry will be created only after the lookup is done.

• They are only available inside of the Node.js, not in the browser.

The Mark and Measure types are also called user timings because the user decides when to create an entry. For example, you can create a Mark performance entry right in the function execution process, not strictly before or after.

The fetch function is the only one responsible for creating Resource entry types. This type is special because it is compatible with W3C specifications and can be used in web browsers, but it is not as flexible as user timings.

Performance observer

We’ve discussed the performance timeline and performance entries. The next logical step is to see the performance data. The measurements. That is where performance observer comes into play.

It enables you to collect and work with the performance entries that the program generates without much sweat.

To start using performance observer, you need first to configure it:

• Create a performance observer and provide a callback function. The function is called whenever an entity you want to observe is created.

• Call the observe method and provide configuration options as the function arguments.

import { PerformanceObserver, performance } from 'node:perf_hooks';

const obs = new PerformanceObserver(list => {
 // Process the list of performance entries.
 // The list contains the test performance mark entry.
});

// Configuration of the observe method
// where we want to monitor the mark entries
obs.observe({ entryTypes: ['mark'] });

// Callback of the performance observable is triggered
// because of the observe function configuration.
performance.mark('test');

Performance entries that you’re not interested in don’t trigger the performance observer callback.

import { PerformanceObserver, performance } from 'node:perf_hooks';

const obs = new PerformanceObserver(list => {
  // Process the list of performance entries
});

// Observe function configuration
obs.observe({ entryTypes: ['function'] });

// The callback is not triggered because the entry type
// doesn’t match the observe function configuration
performance.mark('test');

Overall, this approach is a flexible way of observing different performance entry types.

When to start observing?

The next important topic is when to start observing entries with the performance observer. From this point on, it gets deep, so be ready.

There are only two options: after and before creating a performance entry. I strongly recommend creating a performance entry after the call of the observe method.

The reason is simple: it makes code predictable.

Consider the following example where we create a performance entry before calling the observe method:

import { PerformanceObserver, performance } from 'node:perf_hooks';

const obs = new PerformanceObserver(list => {
 console.log(list);
});

performance.mark('performance-mark');

obs.observe({ entryTypes: ['mark'] });

The expected behavior is to see all related performance entries in the console. However, you still won't see anything in the console despite creating a matching performance entry type (the performance observer is configured for the Mark entry types, and we’ve created exactly one).

Why? Because of the specific way the performance hooks work. Let me explain.

The performance hooks manage several “global” (scoped inside of a file) variables, including the set of observers. The observer is added to this set not when we call the constructor of PerformanceObserver but when we call the observe method.

The observer’s callback is triggered whenever a new performance entry is created. In our case, performance.mark('performance-mark') creates the Mark performance entry and calls all existing observers interested in this type of performance entry.

In summary, the performance observer's callback wasn’t invoked simply because the observer didn’t exist when the performance entry was created.

Here is a picture to better illustrate the process:

What are buffers?

Another important concept is buffers. Buffers enable you to get the historical sequence of performance entries that the program creates.

Don’t be afraid of the fancy word “buffer.” In reality, those are just arrays.

You should be aware of two types of buffers: local and global.

The local buffer is only related to the performance observer. This local buffer stores a sequence of events related to this particular observer. If the observer isn’t interested in some event types, they aren’t buffered.

Important note: those performance entries are buffered only for a period of time before creating a performance entry and calling the observer callback. After that, the buffer gets cleared. It allows us to see two events at the same in one callback call instead of having two separate ones:

const obs = new PerformanceObserver((list) => {
 // The list contains two performance mark entries.
 console.log(list);
});

obs.observe({ entryTypes: ['mark'] });

performance.mark('performance-mark-1');
performance.mark('performance-mark-2');

When it comes to global buffers, there are three of them:

• Performance mark entries buffer.

• Performance measure entries buffer.

• Performance resource entries buffer.

Let’s look at the same example as with the local buffer but slightly modify it.

import { PerformanceObserver, performance } from 'node:perf_hooks';

performance.mark('performance-mark-1');

const obs = new PerformanceObserver((list) => {
 // prints only performance mark #2
 console.log(list);

 // prints both performance marks because it works with global buffers
 console.log(performance.getEntries());
});

obs.observe({ entryTypes: ['mark'] });

performance.mark('performance-mark-2');

You’ll see only one performance mark entry in the first console log because only one is called after the observer method invocation.

The performance.getEntries function gets data directly from the global buffers. It means we’ll see two performance entries in the second console log, even though one was created before the observer's creation.

Conclusion

After reading this article, you should have a solid understanding of the core concepts related to the performance hooks module such as:

• Monotonic and wall clocks

• Performance timeline

• Performance entries

• Performance observer

• When to start observing the entries?

• Performance hooks buffers

These concepts create a good foundation in terms of mental model and some API specifics.

Now, you shouldn’t have any problems using performance hooks and building your own abstractions upon them.

But just because it's popular doesn't mean it's the best choice for every project. In fact, there are some good reasons why you might want to think twice before using it.

This article takes a closer look at PM2 and the problems it can cause. We'll explore situations where other tools, like Docker, might be a better fit.

We'll discuss PM2's downsides, including its proprietary features and licensing issues. By the end, you'll have a clear picture of whether PM2 is right for your Node.js projects.

Problems

Before you jump on the PM2 bandwagon, it's crucial to understand the potential trade-offs and challenges it presents.

Overselling the cluster feature

Most of the online material mentions things like “PM2 has built-in load balancer” or “You can run the application in cluster module and take higher traffic volumes.”

The problem here is people talking about those features without a context. The context here is that PM2 uses a Node cluster module to make those things possible, and I already covered why you probably don’t need the cluster module.

In short, it doesn’t make much sense to have all of those features inside of a single Node server, especially when it comes to modern pipelines, CI/CD practices, and modern deployment strategies.

While it is not directly related to PM2 itself but more to the community around it, it doesn't change the fact that you'll most often encounter clusters in applications that use PM2 than without it.

Proprietary monitoring

One of the features that PM2 itself sells hard is monitoring. Monitoring is a good thing to have, and it shows you how your application and server are doing. The more data you have, the better decisions you can make. People build multi-million dollar businesses on it; take Datadog or Sentry as an example.

The problem with PM2 monitoring is vendor lock-in. You cannot take the data from what PM2 has collected and move it to a third-party monitoring service — at least not that easily. It all comes down to money. PM2 itself provides an advanced monitoring service, but to have access to it, you have to pay.

It doesn’t mean you cannot use other services' monitoring. However, if you think of monitoring as one of the PM2 cool features, you have to think about it again.

Attempts to solve too many problems

It feels like PM2 is trying to solve the problems it shouldn’t be solving but is doing so because “why not?”

It leads to poor results. Those problems are not solved well enough, and you suffer from the consequences.

To name a few:

• Memory management: The process manager tries to manage the memory of the running processes by restarting a process based on the consumed memory. However, it has a 30-second window in which it checks memory consumption. Even if the process goes beyond the limit, it might take up to 30 seconds to shut it down, and you cannot do much about it.

• Persistent application: PM2 can restart the process automatically whenever the machine restarts. It uses systemd daemon, which is used on UNIX-based OS. Because of it, you can run into problems with it on Windows. The other thing is you have to hassle around and update systemd daemon service whenever you want to change the Node.js version.

• Deployment: Doesn’t it sound odd that the process manager is somehow involved in the deployment process? This limits you to a bare metal deployment, which means no containers.

There are more to the list, but you get the idea.

Hard to justify usage with containers

If you use containers in your Node.js application, PM2 becomes redundant.

One of the most popular solutions for working with containers, Docker, provides many similar PM2 features. The difference? They are a lot more reliable.

As a contrary example to the PM2 problems:

• Superior resources management: You can limit memory usage, CPU, and GPU. Those limits are more flexible and reliable. For example, if a container reaches the limit of consumed memory, you’ll know it almost immediately. There is no fixed 30-second window.

• Reliable application persistence: It is possible to configure restart policies for Docker containers. Whenever the host machine is restarted, the Docker daemon spins up and restarts all containers configured for it. The best part is that it works seamlessly on Unix-based OSes as well as Windows. Also, you don’t need to do manual work whenever you change the Node.js version. The container will do it for you.

• Deployment: Containers make it extremely easy to deploy new applications because of their isolated environment. However, they do not attempt to deploy themselves as PM2 does.

Licensing

Another major issue is the licensing under which PM2 is distributed. It uses GNU AGPL-3 license. While the license might not say much to you, here are some of the implications of the license:

• If your project uses a library licensed under the GNU AGPL-3 and distribute it over the internet, you are automatically forced to distribute it under the same license.

• Some of the licenses are not compatible with the GNU APGL-3. If you’re using more than one library — I assume you do — you must ensure no conflicting licenses.

• Projects distributed over a network, like web applications, must allow users to see and download their source code.

As you can see, those are not the best conditions, especially if we compare them with MIT.

That’s the exact reason why Google restricts any usage of code under this license.

When can it be actually useful?

To talk about the cases where it can be actually useful, we have to check a couple of points that we’ve discussed previously:

• You comply with the license and do everything it asks for.

• You’re not using Docker or any other containerization software.

The main benefit of PM2 is simplicity. It tries to solve many problems by being a simple process manager for this exact reason.

You don't need to learn how to deploy your application, configure a load balancer, configure daemons for automatic restarts, or set up a monitoring system manually.

Just use the tool.

Conclusion

While there are certainly cases when you might see yourself using PM2, especially because of its simplicity, there are too many implications.

It tries to go beyond a simple process manager with the same user-friendly approach, which results in not-so-great implementations of those extra features, especially when compared with solutions that are meant to solve those problems, like resource management with containers.

Another huge pain point is licensing. Honestly, it is hard to imagine people willingly accepting the license condition. I assume that most users are simply not aware of the implications it brings.

This is quite a common and annoying situation. I have been there myself. To avoid such troubles, smart people developed tooling called “node version manager.” A shell utility that allows you to switch between Node.js versions easily.

This article will focus on the Node.js version managers market. You’ll see how they differ and which one you should consider using.

Criteria

To make comparison easier, we’ll introduce the following criteria:

• Cross-platform: Is the manager cross-platform?

• Upfront setup: How much work must you do for the initial installation?

• Node version sources: From what sources can the Node.js version be parsed?

• Daily usage: How easy and seamless is using version manager daily?

Contestants

• nvm

• n

• fnm

• volta

• pnpm

Comparison

With defined criteria, we can now look at each contestant in more detail.

Node Version Manager (NVM)

It is the most popular solution for node version management (at least by GitHub repository stars, 75.2k). The reason for that is its early appearance. It was one of the first, if not the first, Node.js version managers at the time and gained huge popularity in the community.

Is it cross-platform? Not really. It doesn’t have full Windows support. It works in some cases like GitBash (MSYS), Cygwin, and WSL (Windows Subsystem for Linux). There is a separate package for Windows called nvm-windows, but it is not NVM itself.

Another limitation is the support of POSIX shells only, such as bash or zsh, which leaves users of other shells, like Fish, out of the question.

The most straightforward way to install NVM is to run the following command.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

Here is how you use NVM to switch between different Node.js versions.

user@machine:~/project node -v
v21.7.2
user@machine:~/project cat .nvmrc
18.19.1
user@machine:~/project nvm use
user@machine:~/project node -v
v18.19.1

NVM can understand which version of Node.js to use through the .nvmrc file. You must either create one before switching between versions or explicitly declare Node.js version to which you want to switch, e.g. nvm use 18.10.

Notice that running the nvm use command will set the Node.js version for the current shell. What does this mean? Even if you leave the project folder and navigate to another project, the Node.js version will stay the same until you rerun the nvm use command.

It adds more friction to your workflow and creates a greater cognitive load because you must always be aware of what Node.js version your current shell uses and what is required for a particular project.

It is still better than manually managing all possible Node.js versions, but far from seamless integration.

N

N is another popular Node.js version manager (18.5k GitHub starts).

It is not cross-platform and has even more limitations than NVM. It does not work in native shells on Microsoft Windows (like PowerShell), Git for Windows Bash, or with the Cygwin DLL.

N can be installed directly from NPM. Run npm install -g n. It can also be installed with the Brew on macOS or by downloading the sh script.

curl -L https://bit.ly/n-install | bash

One of the big benefits of using N is its ability to detect Node versions directly from the “engines” section. If you have the following package.json structure:

{
  "name": "project",
  "version": "1.0.0",
  "main": "index.js",
  "engines": {
    "node": "18.17.0"
  },
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "license": "ISC"
}

N will install “18.17.0” as you specified in the engines section.

However, N suffers from a similar problem to NVM. If you want to use the exact Node.js version for different projects, you have to keep track of it yourself.

Moreover, N takes this problem to a whole new level. Using N means managing a “global” Node.js version. Even after closing a shell, you’re left with the Node version you used for the latest project — not the best experience.

Fast Node Manager (FNM)

FNM is a node version manager written in Rust. It is as popular as N (15.2k GitHub stars).

FNM is the first cross-platform node version manager on the list. It runs on Windows without the need to install any other packages.

The installation process is clear and intuitive.

# macOS
brew install fnm

# Using rust package manager cargo
cargo - cargo install fnm

# On windows using winget
winget - winget install Schniz.fnm

Or using bash script for Unix-based OS.

curl -fsSL https://fnm.vercel.app/install | bash

FNM manages Node.js version per shell and doesn’t try to build its main workflow through global versioning like N does. It has a “default” version which is global and it plays the role of fallback in case some project doesn’t have a specified Node.js version.

The other cool feature of FNM is the auto-switching of Node.js version based on the folder you’re in, but you have to do some configuration for it.

Auto-switching works in the following way: If you go from one project that uses the 18.17.0 version to a different one with 20.12.1, FNM automatically switches Node.js version after you navigate into the new project folder.

user@machine:~ node -v
V21.7.2
user@machine:~ cd project-1
Using Node.js v18.17.0
user@machine:~/project-1 cat .node-version
18.17.0
user@machine:~/project-1 cd ..
user@machine:~ node -v
V18.17.0
user@machine:~ cd project-2
Using Node.js V20.12.1
user@machine:~/project-2 cat .node-version
v20.12.1

We switched between two projects, and the Node version automatically changed based on the .node-version file inside those projects.

You must install the required Node.js version on a machine to make auto-switching work properly.

The other thing to remember is that it can detect node versions only from extra files you create in a project. Those files are .node-version or .nvmrc.

Volta

Volta is a rising star in the world of version managers (10k starts on GitHub).

It is written in Rust, and it is cross-platform.

The installation process is seamless for Unix-based systems.

curl https://get.volta.sh | bash

Windows has a separate installer.

When you configure Volta's Node.js version, you do not need to create extra files. Volta uses configuration from package.json.

{
  "name": "project",
  "version": "1.0.0",
  "main": "index.js",
  "engines": {
    "node": "18.17.0"
  },
}

The benefit of such a configuration is that the engines section is right next to the Volta configuration. This allows you to keep them in sync effortlessly. When placed in a separate file, it is easy to forget to sync those versions.

Another huge feature is the management of a toolchain. What does it mean?

Imagine that you’re using Yarn as a package manager. Other Node.js version managers can manage only Node.js versions. At the same time, Yarn version can change from project to project.

That is where Volta shines. You can dynamically switch not only the Node.js version but Yarn version as well. Just add Yarn version under the “volta” configuration section.

  "volta": {
    "node": "18.17.0",
    "yarn": "1.22.22"
  }

Whenever you run the install command, Volta, ensure that Node.js and Yarn versions match the declared one. Isn’t it magical?

PNPM

Don’t be surprised. PNPM is usually perceived as an alternative to package managers like NPM and Yarn. However, unlike those, PNPM can manage Node.js version itself.

PNPM is cross-platform and provides the same Node.js version management experience throughout all platforms.

However, there are four downsides to using PNPM as a Node version manager.

The first one is that PNPM is not a Node version manager at its core. It is a package manager that can manage the Node.js version. You can’t easily use it with other package managers like NPM or Yarn.

The second one is that Node.js installed using PNPM is not shipped with Corepack. Here is the note from the documentation:

PNPM env does not include the binaries for Corepack. If you want to use Corepack to install other package managers, you need to install it separately (e.g. PNPM add -g corepack).

The third one is that PNPM can only manage the Node.js version globally. You can’t configure it per-shell. If you try to install without the --global flag, you get the following error message:

"pnpm env use <version>" can only be used with the "--global" option currently

It doesn’t switch Node.js version dynamically as you navigate from project to project. This means you have to track it all yourself and ensure it matches the version required for a project.

Conclusion

The Node.js version managers have come a long way. NVM was the first and most popular solution for quite a long time and remains one.

But the ecosystem is evolving. Over time, different tools, such as N, FNM, and Volta, emerged. Each has pros and cons.

At this point, Volta seems to be our most feature-reach and complete Node.js version manager. It is cross-platform, provides a seamless experience in day-to-day usage, and takes care of other tools you use on the project.

While it is a common task, people in the Node.js community still get confused about how to implement it, what options we have to create and manage those tasks, and the pros and cons of each option.

In this article, we’ll answer all those questions, giving you a clear picture of the tools you have at your disposal.

Terminology

The world of task scheduling uses different terms that basically mean the same thing: jobs or tasks that the application performs on a schedule.

Many people call those cron jobs. However, this term can cause more confusion, especially if you’re just starting your journey on the backend.

For example, cron is a UNIX-based scheduler. What does it have to do with your application if you're running it on a Windows server?

A better term for it would be “scheduled tasks.” The name itself is crystal clear; you don’t have to second-guess what it stands for.

This term will be used throughout the rest of the article.

Factors to consider before choosing a task scheduling approach

Before exploring the different tools and approaches, it's important to understand your application's specific requirements. Considering the following factors will help you to make an informed decision.

• Application and infrastructure scale

• High-frequency tasks

• Long-running tasks

• Task stacking

Let's explore each of these factors in more detail.

Application and infrastructure scale

You have to understand the scale of your application and underlying infrastructure. It’ll allow you to make a reasonable decision on what approach to choose.

To name a few cases:

• A single instance of application is running on a single server

• Multiple instances of application are running on a single server

• Multiple instances of applications are running on multiple servers

It is not limited only to those 3. You might have a different setup and infrastructure configuration. The point is that you have to understand it before deciding on the task scheduling approach.

High-frequency tasks

If you need to run tasks at intervals shorter than 1 minute, your options will be more limited. Some scheduling solutions don't support high-frequency tasks out of the box at all or require additional workarounds.

Consider the minimum interval between tasks that your application requires, and ensure that the chosen solution fits those needs.

Long-running tasks

Long-running tasks introduce their own set of challenges. These tasks can exacerbate issues like memory leaks, which may not be apparent in applications without long-running processes. When implementing long-running tasks, consider the following challenges:

• Debugging complexity: Long-running tasks can be harder to debug due to their extended runtime and potential interactions with other parts of the system.

• Maintenance and updates: Careful planning is required when performing maintenance or updates on applications with long-running tasks to ensure minimal disruption and proper handling of in-progress tasks.

• Resource management: Long-running tasks consume system resources over an extended period. Proper resource management, such as memory and CPU usage, is crucial to avoid performance degradation and memory leaks.

Tasks stacking

Task stacking occurs when a new task is started before the previous one has been completed. This can happen when the scheduled interval is shorter than the task's execution time.

Task stacking can lead to resource contention, performance degradation, and unexpected behavior. When selecting a scheduling solution, consider how it handles task stacking and whether it provides mechanisms to prevent or manage such situations.

Tasks scheduling approaches

While all scheduled tasks share the common characteristics of having a specified execution time and associated code, they differ in how and where they are scheduled and managed. In this section, we'll explore the various approaches to scheduling and managing tasks, including:

• UNIX-based scheduling with cron

• Runtime scheduling

• Runtime scheduling with persistence

• Cloud-based scheduling solutions

Each approach has its own pros and cons, which we'll discuss in detail.

UNIX-based scheduling with cron

Cron is a long-standing and widely-used scheduler in UNIX-based systems. It allows you to schedule tasks, known as "cron jobs," to run at specific intervals of time.

The interface through which you schedule tasks to cron is called crontab (cron table). Crontab uses a specific syntax to define the schedule.

Cron runs a cron daemon, a single process responsible for managing all the scheduled tasks. When a new task is scheduled, the daemon starts monitoring it with a frequency of 1 minute. When a task is due to run, cron creates a separate process for that task and executes it.

Pros:

• Flexibility: Cron is a versatile tool for running various types of scripts and programs on a scheduled basis.

• Process isolation: Each cron job runs in its own separate process, providing a level of isolation and minimizing the impact of one task on others.

• Reliability: Cron has been around since 1975 and has proven to be a reliable and stable solution for task scheduling.

Cons:

• Single machine limitation: By default, cron is limited to a single machine, which can make it harder to scale for larger workloads.

• Task stacking: If a task takes longer to execute than its scheduled interval, multiple instances of the task may start running concurrently, leading to resource contention. Cron doesn't have built-in mechanisms to prevent this.

• Limited fault tolerance: Cron doesn't provide built-in error handling functionality. If a task fails, cron won’t automatically retry it. You need to implement your own error handling and retry mechanisms.

Runtime scheduling

Runtime scheduling refers to scheduling tasks directly within the application code. This approach is facilitated by various ready-to-use libraries in the Node.js ecosystem, such as node-cron, corn, croner, and others. While these libraries may have different implementation details, they all operate on the same fundamental principle.

Under the hood, these libraries typically use setTimeout or setInterval functions to schedule tasks. When your application starts, the scheduled jobs are initialized and set to run at their specified intervals.

Pros:

• Simplicity: Runtime scheduling is easy to set up and get running, as it doesn't require any additional infrastructure or external dependencies.

• Quick development: For simple use cases or prototypes, runtime scheduling allows you to implement task scheduling quickly without the overhead of more complex solutions.

Cons:

• Resource contention: Not all solutions execute tasks in a separate process/thread. This means that if you run CPU-intensive logic inside a task, you have to be aware of particular implementation details to ensure that those tasks won’t block the main thread.

• Deployment challenges: When deploying a new version of the application, all scheduled tasks will be rescheduled because all timers run inside of the same process as the application code (unless you separate it into a dedicated, independent process). It results in delayed task execution.

• Scalability limitations: As the application scales beyond a single instance, managing runtime-scheduled tasks becomes increasingly difficult. Each application instance runs the same code and schedules the same tasks, leading to duplication and conflicts.

• Task stacking: If a scheduled task takes longer to execute than its specified interval, multiple instances of the task may start running concurrently. This can result in resource contention and unexpected behavior, especially for long-running tasks.

Runtime scheduling can be a good fit for simple applications or prototypes where you want to test and visualize scheduled jobs quickly. However, it may not be the most suitable approach for production-grade applications that require scalability, reliability, and efficient resource utilization.

In this case, both task data and timers reside within the application.

Runtime scheduling with persistence

Runtime scheduling with persistence builds upon the basic runtime scheduling approach and introduces a persistence mechanism to store and manage scheduled tasks.

By incorporating a persistence layer, the application can store information about scheduled tasks in a database or a persistent storage system. This allows the application to track and recover tasks even after a restart or a new deployment, ensuring that tasks are executed on time.

Two notable libraries in the Node.js ecosystem provide runtime scheduling with persistence: Bull (or BullMQ) and Agenda.

Bull is a popular library that uses Redis, an in-memory data store, as its persistence mechanism.

Agenda is another library that provides runtime scheduling with persistence using MongoDB. It's important to note that the Agenda may not be actively maintained, with the last major release dating back to November 2022 (as of May 2024).

Unlike Ageda, Bull is actively maintained. The downside of Bull is it uses in-memory databases. If your server goes down, all jobs are lost.

Pros:

• Persistence: Runtime scheduling with persistence ensures that scheduled tasks are not lost during application restarts or deployments. The persistence mechanism allows you to recover and resume tasks from where they left off.

• Scalability: Abstracting task management from the main application and storing tasks in a separate persistence layer makes it easier to scale the application in the future. Multiple application instances can share the same persistence layer and coordinate task execution.

• No task stacking: When using Bull, the queue-based structure ensures that tasks are executed in a reliable and orderly manner. New tasks are only started after the previous ones are completed, preventing all problems related to task stacking.

Cons:

• Complexity: Implementing runtime scheduling with persistence requires additional setup, configuration, and learning compared to basic runtime scheduling. You need to set up and manage the persistence layer (e.g., Redis or MongoDB) and integrate it with your application.

• Dependency on external systems: Relying on external systems like Redis or MongoDB introduces additional points of failure. If the persistence layer experiences issues or downtime, it can affect the task scheduling workflow.

Runtime scheduling with persistence offers a more robust and reliable approach compared to basic runtime scheduling. It addresses the issue of losing scheduled tasks during restarts and deployments and provides better scalability options. However, it also introduces additional complexity and dependencies on external systems.

With this approach, we move task information to the persistence layer. The application is now only responsible for running timers and executing tasks themselves (in case we still run everything in a single application instance).

Cloud-based scheduling solutions

The other option is to move to the cloud. In this case, you don’t need to use any of the previous solutions to create, schedule, and persist tasks.

Popular cloud providers, such as Amazon Web Services (AWS) and Google Cloud Platform (GCP), offer dedicated services for scheduling tasks. For example, AWS provides the EventBridge Scheduler, while GCP offers the Cloud Scheduler.

Pros:

• Decoupled architecture: Cloud-based scheduling solutions decouple the scheduling logic from your application code. This separation of concerns makes it easier to scale and maintain your application independently of the scheduling infrastructure.

• Scalability and reliability: Cloud providers offer highly scalable and reliable scheduling services. They handle the underlying infrastructure, ensuring that tasks are executed on time and with high availability. You don't need to worry about managing the scheduling infrastructure yourself.

• Flexibility and integration: Cloud-based scheduling solutions often provide flexible scheduling options, such as cron-based scheduling or more advanced scheduling patterns. They also integrate well with other cloud services, allowing you to build complex workflows and data pipelines.

Cons:

• Learning curve: Cloud-based scheduling solutions require an understanding of a specific cloud platform and its services.

• Cost considerations: While cloud-based scheduling solutions offer scalability and convenience, they come with associated costs. As your usage grows, the cost of using these services may increase. It's important to carefully evaluate the pricing models and estimate the long-term costs based on your application's needs.

• Complexity in code sharing: If your application relies on code sharing between the main application and the scheduled tasks, using a cloud-based scheduling solution makes it increasingly harder to share the code. You may need to package and deploy your task code separately from your main application, which can require additional configuration and deployment processes.

Conclusion

In the world of Node.js task scheduling, there is no one-size-fits-all solution.

When deciding on a task scheduling approach for your application, it's critical to evaluate your specific needs and trade-offs carefully. Consider the scalability and reliability requirements, the complexity of setup and maintenance, and the potential costs involved.

Be open to exploring different options, adapting as your needs evolve, and finding the solution that best fits your application's goals and constraints.

In this article, we’ll see the pros and cons of using each of them. Spoiler: some of the options don’t make much sense to use.

Node.js CLI options

The Node.js CLI has two options for managing heap sizes: --max-old-space-size and --max-semi-space-size.

Trade-offs

Those options cannot regulate everything. Here a just a few cases where CLI options won’t work for you.

Spawned process. Whenever you spawn a new process via child_process.spawn, you’re creating a new instance of V8 alongside the process. It doesn’t inherit all of the options from the process that it was spawned from automatically. Sure, you can pass them manually, but now you have to be aware of each process and its memory consumption in the system.

Addons. Addons are not directly related to JavaScript. In fact, they are C++ libraries accessible through JavaScript. This means the code running inside those libraries is not affected by V8 restrictions, at least in this case.

I/O operations. I/O operations are handled by the libuv library and it means we’re facing C++ again. And not only that. When reading a large file, the result is passed as a buffer into the callback:

import fs from 'node:fs';

// The data is Buffer object.
fs.readFile('large-file.txt', (err, data) => {
  if (err) {
    console.error('Error reading file:', err);
  } else {
    console.log('File contents:', data.toString());
  }
});

Even when we have the buffer instance inside of JavaScript, the memory allocated for this buffer resides outside of the V8 heap and is, therefore, unaffected by the options.

When to use

Use those when you want to specifically imply the limits of JavaScript-related code consumption to a single process.

They make garbage collection more efficient. When memory consumption gets closer to the size that you provided, the garbage collection runs more frequently, resulting in less memory usage.

PM2 process manager

PM2 is a popular JavaScript process manager. It has a feature to restart a certain process based on the memory it consumes. You can achieve this by specifying the max_memory_restart option.

Trade-offs

The first and most significant tradeoff is how the process manager manages memory consumption. It has a separate worker process that checks memory consumption every 30 seconds.

This means it takes up to 30 seconds for the process that ran out of memory to be detected and restarted. These 30 seconds can cost a lot, up to the whole server crash.

The other is inherited problems that come with directly using PM2, such as:

• Overselling clustering that leads to cumbersome workflow.

• Attempts to go beyond a simple process manager and deliver on those attempts purely, compared to the alternatives.

• Licensing issues.

I’ll soon publish an article that goes deep into the PM2 problems.

When to use

To be honest, I don’t see any good reason to use PM2 at this point except only one specific use-case that I’ll describe in the upcoming article.

User limits

User limit is the way to set limits to resources based on the user's role in a unix-based system.

Trade-offs

It is hard to scale. This type of limitation is especially challenging to scale if we want fine-grained control over specific processes or groups of processes.

Managing a large number of users, each with its own limits, quickly becomes complex.

When to use

It is an excellent option to use as a second line of defense. For example, if you have some way of managing resource consumption of a process or process group but want to be sure that if something goes wrong, you have a backup plan.

Control groups

Control groups are meant to manage resource consumption on the system level, similar to user limits in their focus on resource management.

Trade-offs

The only major problem I see with control groups is the configuration process. You might rightly say “skill issues.” However, the lack of clear interfaces through which we can configure them, like a single configuration file that resides next to the application code, makes it increasingly hard to manage.

One more issue could be a lack of complete isolation. With control groups, you’re still pretty much working on the same machine, with the shared file system, network, and any other resources.

When to use

If you have enough skill and understanding of how they work, you can use them whenever you want. They are flexible enough to deliver on most of the tasks related to resource management.

Containers

Container is an abstraction that goes further than control groups. It allows allocating resources for a group of processes and almost completely isolates them in terms of file system, network, etc.

Trade-offs

The main trade-off of containers is the abstraction itself. It adds more complexity to the whole workflow.

Such complexity results in:

• Higher resource usage. Creating a container requires more resources than making a simple control group.

• Performance problems in high-performance applications. As a result of high resource consumption, you can run into performance issues.

• Learning curve.

When to use

Despite container trade-offs in particular cases, it is still the best solution for resource management we have so far. Here are just a few benefits that you get by using them:

• Granular control. They heavily restrict resource usage (using control groups for it). Each container is isolated from one another, making it harder to break things up.

• Better tooling. Tooling around containers allows you to configure containers for specific needs easily. Moreover, If you’re using some IDE with tools like Docker, it will hint you commands that you can use and highlight the ones that you can’t, making the experience even better.

• Great isolation. Containers provide a great isolation for applications running inside of them.

Conclusion

There are many options for resource management of Node.js applications. It all comes down to understanding the trade-offs of each approach and your specific needs.

In general, I would stick with containers whenever possible. Even if you don't know about them much, it is a great opportunity to learn.