A Practical Guide to the Cluster Module in Node JS

Sriniwas — Tue, 03 Oct 2023 08:06:42 +0000

Introduction

Scaling NodeJS is easier than you might think, but let's first understand how it works, you might've heard that NodeJS is an event-driven single threaded runtime for javascript, but trust me it's nothing to scoff at, thanks to the single-threaded nature of node it's exceptional at managing concurrent requests, while that may sound good on paper even that has it's limitation, and in this article we will discuss the cluster module.

Clusters

In order to fully utilize our CPU, we need to implement the cluster module, it's a module which allows us to create multiple 'workers' and each worker runs on one thread, if we have a CPI containing 4 cores we will 8 threads at our disposal, which means by implementing the cluster module our application can handle 8x more requests.

Now let's create a application!

// server.js
const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello, World!');
});

module.exports = app

We'll start by creating a basic express server with a route which sends 'Hello World!' as the response.

const cluster  = require('cluster')
const os = require('os')
const app = require('./server.js')
const port = 3000

if(cluster.isMaster){
  let cpus = os.cpus().length

  for(let i=0; i<cpus; i++){
    cluster.fork();
  }
} else {
  app.listen(port, () => {
    console.log(`Server is running on http://localhost:${port}`);
  });
}

and now we're gonna add another file cluster.js, this will be the entry point for application

node ./cluster.js

before ending this article there's one more thing we need to take care of, let's say one of our threads crash for some reason, in that case we need to fork another worker, which is actually quite simple to do.

// cluster.js
...
cluster.on('exit', (worker) => {
  console.log(`Worker ${worker.id} died`)
  cluster.fork()
})
...

With this block, whenever a process dies, we'll fork a new one.

5 Ways Bun is just better, than NodeJS

Sriniwas — Sat, 30 Sep 2023 11:47:47 +0000

Bun, it seems to be everywhere nowadays, is it worth the hype or it will fade away just like deno did, let's have a deeper look shall we.

The Good Parts

It's fast, ...really fast

While bun has a lots of nice features, the greatest one so far is the performance it offers, the biggest difference that bun has compared to nodejs under the hood is the JavaScript engine that they are using.

NodeJS is build on the trust V8 engine, which is a pretty good engine, but the Bun team decided to go ahead with JavaScriptCore given it's way faster and memory efficient compared to the v8 engine.

Excellent TypeScript Support

Adding TypeScript to your application is easy but it's still a hassle you need to take care of, with Bun we get "Native" TypeScript support, heck you can even import a typescript file into a javascript file without doing any sort of transpiling.

It's also a Bundler

Bun has a bundler built in (I know, shocking) and guess what it's faster than webpack, it also has several plugins for loading files for scss, json, toml and much more.

New Native Libraries (yay!)

Bun has an HTTP server built into it, after some testing I can say it's all right which is faster than express, it also has saveral libraries for Worker, File I/O, Hashing and much more but what really blew my mind was the inclusion of WebSockets, with bun implementing that will be easier than ever.

SQLite, Really?

Yes, you heard it right, it's has support for SQLite databases natively built into the runtime, it could be a real Boon(no pun intended) when you are working on small localized applications.

Closing Remarks

Given all the points above, bun is a promising candidate to replace NodeJS, but only time will tell.

DEV Community: Sriniwas