DEV Community: Arinze Obi

Clustering: The Good Parts

Arinze Obi — Sat, 04 Feb 2023 05:35:57 +0000

Last week I experimented in depth with clustering in node.js applications and going to be breaking down the core concepts (pun intended) and possible use cases

NB: Unlike previous articles I will henceforth refrain from using analogies to represent technologies as I have learned that analogies (or the way it is communicated) may differ from person to person. Instead I shall focus on asking and answering questions about the tech to better focus more on it's use cases and abilities.

Why

As the popular saying goes "A journey of a thousand miles begins with a single step", so too does our journey into learning something new needs to always start with a WHY - much like your four old nephew asking why the sky is blue on a random tuesday afternoon.

Q: Why would we need to use clustering?
A: To make our application more performant when put through considerable stress (also read as scale).
To further drive the point home, let's quickly take a look at a simple server in node.js

const http = require('node:http');
const OPERATIONS_COUNT = 10;

const server = http.createServer((req, res) => {
  if(req.url === '/') {
  for (let i = 0; i < OPERATIONS_COUNT; i++) {}
  res.end('What is clustering anyway :(');
} else {
  res.end('clustering is the process of creating clusters')
}
});

server.listen(3000, () => console.log('Listening on port 3000'));

We visit http://localhost:3000 and we instantly get back a text saying What is clustering anyway :( and if we visit any other route we get clustering is the process of creating clusters - simple enough.

Now let's up the gear a little and increase the OPERATIONS_COUNT to 10_000_000_000, restart our server and hit the / endpoint again. Now we see a considerable lag in the time taken to get back our response but more importantly lets notice that while / is still processing our initial request any subsequent request made to the server is suspended as well. clustering helps avoid some of these problems

Q: What is clustering?
A: First let's take a look at what a cluster is, according to the oxford dictionary:

a group of similar things or people positioned or occurring closely together.

So clustering is just the process of making clusters in an application.

Q: How would one use clustering
A: I'm glad you asked, that's the focus for today.

At an abstract level clustering is a group of two or more nodes/processes that run in parallel to achieve a common goal. This enables tasks that would otherwise be cumbersome for one process to be spread out across a network of clone processes which have their own memory, thread-pool and engine instance hence increasing overall performance of the application.

processes are usually connected in an enclosed network enabling them synchronously communicate with each other. These processes then consist of ONE master process (main node) who is responsible for delegating tasks and then the child process (cloned nodes) who work on these assigned tasks.

Types of cluster configuration

Active-Active Configuration
Active-Passive Configuration

Just like load balancers, clusters can be configured as active-active or active-passive. An active-active configuration has all child processes actively handling tasks alongside the master process while active-passive configuration keeps all workload on the master-process and only delegates tasks to further child processes should the master process fail/experience downtime.
For the scope of this article I'll focus on the active-active configuration

Setting up processes

Next we'll set up processes to correctly account for the lag in our code snippet above.
Node.js has a built-in library called cluster which enables clustering in our application. Our code initially runs on one core (master node), we will then be calling on the extra cores in our computer to serve as worker nodes. Every computer differs in the amount of cores they have though. To check the amount of cores your computer has, can copy the snippet below

const os = require('os');
console.log(os.cpus());

/** You would get back an array that is structured similarly
* [
* {
*   model: 'Intel(R) Core(TM) i5-9878U CPU @ 1.40GHz',
*   speed: 1400,  
*   times: {
*     user: 92892892,
*     nice: 0,
*     sys: 111111,
*     idle: 10101010,
*     irq: 0
*    }
* },
* { 
*  ...
* }
* ]
*/

The CPU object array has these values

model: the CPU model
speed: the CPU speed in MHz
user: the number of milliseconds the CPU has spent in user mode
nice: the number of milliseconds the CPU has spent in nice mode
sys: the number of milliseconds the CPU has spent in sys mode
idle: the number of milliseconds the CPU has spent in idle mode
irq: the number of milliseconds the CPU has spent in irq mode

To get more information out of your CPU, you can use the node-os-utils package.

To our snippet we will add a cluster and spin-off as much worker processes as our computer can handle

const cluster = require('node:cluster');
const http = require('node:http');
const os = require('node:os');

const cores = os.cpus().length;
const OPERATIONS_COUNT = 10_000_000_000;

const server = http.createServer((req, res) => {
  if (req.url === '/') {
    for (let i = 0; i < OPERATIONS_COUNT; i++) {}
    res.end('What is clustering anyway :(');
  } else {
    res.end('clustering is the process of creating clusters');
  }
});

if (cluster.isMaster) {
  for (let i = 0; i < cores; i++) {
    cluster.fork();
  }
} else {
  server.listen(3000, () => console.log('server listening on port 3000')); // only listen to port once all child nodes have been created 
}

When we visit / this time around and then subsequently visit /about we can see that /about is not held up by the processing of /. This illustrates that a worker process stepped in and handled the next request.

To do the math on the performance gain of deploying child processes in our application, let's imagine a single node could handle 1000 requests a minute, using clustering with 8 nodes, we upped that request to 8000 requests THAT'S 8X MORE OUTPUT! Not sure how you feel about that but for me, it blows my mind.

Clustering is frequently used in the software development and in even in some technologies like kubernetes and redis.

How to use PassportJS for authentication in NodeJS

Arinze Obi — Wed, 25 Jan 2023 06:57:14 +0000

NB:

Basic knowledge of node.js is needed to follow along with this article

You should be on the root path of the project when typing in the commands from the command line snippet

The majority of the codebases I've worked on over the years have always favoured using JSON web-tokens (JWT) or Authentication-as-a-Service platforms (Auth0, Okta etc) for authentication logic.
These are indeed excellent choices! however, on smaller projects I find these to always seem to be overkill. Recently I started working on a chrome extension that performs social sign-in using twitter OAuth API and decided to use passport.js to outsource some of the heavy lifting involved in setting up authentication. Below I walk through the benefits and step-by-step guide in getting started with passport.js for authentication

The Why

Authentication is a very delicate process in the creation of software and having the right strategy to use for your application can be a chore. In order not to get caught up in a dilemma of the perfect authentication flow to use that would handle millions of users, I like to stick to simpler tools that would serve my end users effectively and only scale when the need arises (and not a moment before). For a frontend heavy application like the chrome extension I'm working on, I found setting up authentication with passport.js to be the more effective option for my use case as I will require very little usage of the backend.

What is PassportJS

According to the official docs

Passport is authentication middleware for node.js. Extremely flexible and modular, Passport can be unobtrusively dropped in to any Express-based web application. A comprehensive set of strategies support authentication using a username and password, Facebook, Twitter, and more.

Let's break this down so we understand it at a more fundamental level.

passport is authentication middleware for node.js: A middleware is just a function that runs in between a request/response cycle and node.js is a runtime environment that enables us run javascript outside the browser.

can be unobtrusively dropped in to any express-based application: This means we can use passport in any node.js application in a way that keeps our code lean, clean and easy to maintain.

support authentication using a username and password, Facebook, Twitter: passport.js gives you the flexibility to authenticate users with username/password, google, twitter and more. It does this by using strategies which are installed as separate packages from the npm directory and there are more than 500 strategies that can work with passport!

To top it all off this package is 81kB! For context the google-auth-library which is the official library for implementing google OAuth has a size of 496kB. Pretty easy to see why I am using passport.js on this project

Project Scope and Setup

Without wasting too much time let's jump into the scope of the project.
Today we will be making a simple app that
allows users to login, view the current time of day and logout

First thing's first, let's setup our server.
(PS: You might want to make sure you have nodejs installed on your machine first)

Create folder

mkdir timely # create folder for project
cd timely # navigate into folder
touch index.js # create main entry point into your server
npm init -y # initialize npm

Install dependencies

npm install passport express express-session passport-local ejs # install dependencies
npm install nodemon --save-dev #install peer dependencies

Setup User Interface

We're going to be using EJS as our templating engine so we can dynamically display user content on our website. If you're not quite sure what templating engines are, you can get an idea through on this amazing article.

mkdir views # create views folder
cd views # navigate into views folder
touch authenticate.ejs && touch index.ejs # create out home and authentication page

Now we will be adding the public folder which houses our static assets for the project

mkdir public # create public folder 
cd public # navigate into public folder 
touch main.js && touch styles.css

I've included the content for main.js and styles.css which you can copy over here

Locate the index.ejs file and replace it's contents with the following as well

<!-- navigate into timely/views/index.ejs and insert the following -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <link rel="stylesheet" href="/styles.css" />
    <script defer src="/main.js"></script>
    <title>Timely | Who needs a rolex anyway 🤷‍♂️</title>
  </head>
  <body>
    <div class="header">
      <h1>Timely 🕰</h1>
    </div>
      <div class="container">
        <h1>Welcome User</h1>
        <div class="content"></div>
      </div>
  </body>
</html>

Create a Server

// Navigate into timely/index.js
const express = require('express');
const path = require('node:path');
const app = express();


app.use(express.static(path.join(__dirname, 'public'))); // Require static assets from public folder
app.set('views', path.join(__dirname, 'views')); // Set 'views' directory for any views being rendered res.render()
app.engine('html', require('ejs').renderFile); // Set view engine as EJS
app.set('view engine', 'ejs');

app.get('/', (req, res) => res.render('index'));

app.listen(3000, () => console.log('server is running on port 3000'));

Setup scripts in package.json

{
  "scripts": {
   "test": "echo \"Error: no test specified\" && exit 1",
   "start": "node index.js",
   "start:dev": "nodemon index.js"
 }
}

Run script

npm run start:dev

At this point we should get back a large text that reads "Welcome User" along side the current date and time when we visit http://localhost:3000/

Looks great! but we want only logged in users to have access to the time and date. so lets create an authentication page for users that aren't logged in.
Locate the authentication.ejs file inside your views folder and replace it's content with the following

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <link rel="stylesheet" href="/styles.css" />
    <title>Timely | Who needs a rolex anyway 🤷‍♂️</title>
  </head>
  <body>
    <div class="header">
      <h1>Timely 🕰</h1>
    </div>
    <form action="/log-in" method="POST" class="container">
      <h1>please log in</h1>
      <div>
        <label for="username">Username</label>
        <input name="username" placeholder="username" type="text" />
      </div>
      <div>
        <label for="password">Password</label>
        <input name="password" type="password" />
      </div>
      <button>Log In</button>
    </form>
  </body>
</html>

Before we write out any more code, lets understand the passport packages we installed and how they fit together

passport: This is the main passport module that helps us attach the information of a current logged in user to the req.user object

passport-local: Passport.js works in collaboration with strategy packages to perform the authentication flows you need for your application. We will be using passport-local for this as we will be authenticating our users with username and password only

express-session: This will enable us store and manage sessions of currently logged in users on the server

Now that we have a little idea of how passport works, let's create our passport middleware strategy. This will be the logic behind adding the user information into our req.user object. In your root folder create the following directories

mkdir strategy && cd strategy # create and move into strategy folder
touch local.js # create strategy file

NB: On real world projects it's best to hash user passwords before storing them, for improved security and also use an actual database for storing user information. Here I will be storing user information in a json file on the system to avoid network calls and keep the sole focus of the article on passport.js.

Inside local.js replace it's content with the following

const path = require('node:path'); // path module to find absolute paths on the system 
const fs = require('node:fs'); // file system module to manipulate files
const passport = require('passport'); // the main star of the show
const LocalStrategy = require('passport-local'); // the co-protagonist in this sequel 

const dbpath = path.join(__dirname, 'db.json'); // path to our custom in-house json database

passport.serializeUser((user, done) => { 
  done(null, user.id);
});

passport.deserializeUser((id, done) => {
  if (!fs.existsSync(dbpath)) { // if db does not exist, create db
    fs.writeFileSync(dbpath, JSON.stringify({ users: [] }));
  }

  const db = JSON.parse(fs.readFileSync(dbpath, { encoding: 'utf-8' }));

  let user = db.users.find((item) => item.id === id);

  if (!user) {
    done(new Error('Failed to deserialize'));
  }

  done(null, user);
});

passport.use(
  new LocalStrategy(async (username, password, done) => {
    if (!fs.existsSync(dbpath)) { // if db.json does not exist yet, we create it
      fs.writeFileSync(dbpath, JSON.stringify({ users: [] }));
    }

    const db = JSON.parse(fs.readFileSync(dbpath, { encoding: 'utf-8' }));

    let user = db.users.find((item) => {
      return item.username === username && item.password === password;
    });

    if (!user) {
      user = {
        id: Math.floor(Math.random() * 1000), // generate random id between numbers 1 - 999
        username,
        password,
      };

      db.users.push(user);
      fs.writeFileSync(dbpath, JSON.stringify(db));
    }

    done(null, user);
  })
);

this file will be run each time a request is made to our server. Let's breakdown what each method does exactly

passport.use: This is the first point of contact and is responsible for creating our users. It is run once and after successfully authenticating our user, it passes this information unto the next middleware which is the passport.serializeUser

passport.serializeUser: This creates a session in passport with our key being user.id. It's quite important for our sessionIDs to be unique as well to avoid conflict

passport.deserializeUser: On each request, This method receives our sessionID and scans our database to get the user information of the currently logged in user then attaches that information to the req.user object

Now That we know how passport works lets finally include it into the project which will enable us identify logged in users and re-route their requests accordingly

const express = require('express');
const passport = require('passport');
const session = require('express-session');
const path = require('node:path');
const app = express();
require('./strategy/local'); // passport strategy will listen to every request

app.use(
  session({
    secret: 'SOME SECRET', // secret key to sign our session
    resave: false,
    saveUninitialized: false,
    cookie: {
      maxAge: 1000 * 60 * 60 * 24, // TTL for the session
    },
  })
);
// initialize passport package
app.use(passport.initialize());
// initialize a session with passport that authenticates the sessions from express-session
app.use(passport.session());

app.use(express.urlencoded({ extended: false }));

app.use(express.static(path.join(__dirname, 'public'))); // Require static assets from public folder
app.set('views', path.join(__dirname, 'views')); // Set 'views' directory for any views being rendered res.render()
app.engine('html', require('ejs').renderFile); // Set view engine as EJS
app.set('view engine', 'ejs');

app.get('/', (req, res) => {
  if (!req.user) {
    // if passport does not have record of this user, we redirect them to the authentication page
    res.render('authenticate');
  } else {
    res.render('index', { user: req.user });
  }
});

app.post(
  '/log-in',
  passport.authenticate('local', {
    // on Initial login, passport will redirect to either of these routes
    successRedirect: '/',
    failureRedirect: '/',
  })
);

app.listen(3000, () => console.log('server is running on port 3000'));

If we visit http://localhost:3000/ on our browser again, we are immediately routed to the authentication page.

Upon sign-up we are assigned a session cookie which you can view in our browser devtools console (right click on the page -> inspect -> Application -> cookies -> http://localhost:3000).
Each time a request is sent to the server, this cookie is sent alongside it and from this cookie, passport can correctly identify if we are logged in or not.
To further certify this point, you can go ahead and delete the cookie from the devtools console then refresh the page - In an instant you are immediately re-routed to the authentication page.

Our homepage looks good but let's add a bit of personality to it by displaying the users username with ejs and also the ability for users to logout.

In index.ejs make the following changes

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <link rel="stylesheet" href="/styles.css" />
    <script defer src="/main.js"></script>
    <title>Timely | Who needs a rolex anyway 🤷‍♂️</title>
  </head>
  <body>
    <div class="header">
      <h1>Timely 🕰</h1>
    </div>
    <form class="container" action="/log-out" method="post">
      <h1>Welcome back, <%= user.username %></h1>
      <div class="content"></div>
      <button>Log out</button>
    </form>
  </body>
</html>

Now to handle the logout route on the server we can add the following code just above app.listen() method

app.post('/log-out', (req, res) => {
  req.logOut((err) => { // clear out information in passport-session and redirects user
    if (err) {
      res.send('something went wrong');
    }

    res.redirect('/');
  });
});

app.use('*', (req, res) => res.redirect('/')); // to catch and redirect all other routes

NB: You might have noticed that each time you make changes to server files, you are re-routed to the authentication page. This is because sessionIDs are stored in a cache created by express-session and once nodemon restarts the server, the express-session cache is wiped clean hence passport can not recognise us with the previous sessionID.

And that's it! Now we can fully log in and out of our application using passport.js.
I do recommend reading more into their documentations to discover new strategies you can use in your future projects. Till next time, Ciao!

Load balancing for beginners

Arinze Obi — Sat, 21 Jan 2023 08:01:36 +0000

Keeping in tune with my new years resolution, this week I studied in depth into setting up load balancers and node clustering. Without wasting much time lets dive right in to the notes

Drawing from this popular definition of an API analogy:

Let's then start off by imagining a restaurant with guests, a waiter and the kitchen staff — you know how it goes.

Say this restaurant is huge and we have 4 kitchens in the restaurant each responsible for making amazing meals but specialised in making one delicacy (Chinese, Indian etc). Now for some reason a large chunk of the guests tonight fancy chinese and place around 60 orders, the waiter does his job and takes all orders to kitchen 1 who is specialised in making chinese food - attending to 60+ orders at a go would no doubt put a lot of stress on kitchen 1 but we have to remember that the other kitchens can make chinese as well just not specialised on it.
Wouldn't it make for a better experience for both the chef and the guests if the orders were spread out equally among each kitchen - I mean that would take a chunk of work off kitchen 1 and make sure guests get their food in less time! A win-win case for everyone.

Now the waiter could go about distributing this workload in a couple of ways:

Spread all orders equally, so if there are 4 requests each kitchen works on 1
Give the order to the kitchen with the least amount of orders
Give the order to the kitchen that has always handled the particular guests' order anytime they visit
Give the order to the kitchen with the hottest stove

There are a chunk of ways to go about it really but for now lets reveal the technologies involved in this analogy:

The guests are obviously our client devices (web browser, mobile, desktop) 🖥️
The kitchen is our server/API 🗄️
The waiter in this scenario is our load balancer ⚖️

You must probably be thinking that the load balancer serves the same purpose as the API since it takes our requests from the client to the processing point/server but you would be a bit off. For a start your request passes through the load balancer (waiter) first before ever making contact with the API/Server (kitchen) and secondly the load balancer as the name implies balances the request load (order) each of your servers have to handle which maximises performance to a great degree.

You see if kitchen 1 kept getting ALL orders, it wouldn't take long before the cooking staff become exhausted and take a break, leaving the guests waiting for much longer to have their orders fulfilled.
Now in this case the waiter is specially trained to reduce overall wait time of the guests by identifying which chef to give an order.

There are a few algorithms a load balancer can employ to determine how to select the server to handle a request we'll look at just the 4 quoted above (which is configurable based on your requirements)

Round robin - This just spreads the requests incrementally across each server. If there are 4 requests, 4 servers handle 1 each. If there are 7 requests, only server 8 gets to handle 1
Least connections - This just assigns the request to the server with the least request being handled
Hashing - This distributes the requests based on a key we define, such as the client IP address or the request URL
Least Bandwidth - This algorithm measures traffic in megabits per second (Mbps), sending client requests to the server with the least Mbps of traffic.

You can go over this brilliant article by the good folks at cloudflare to learn more about load balancing algorithms.

Now hopefully we have a firm understanding about the concept of load balancers, but as software engineers we always need to avoid single points of failure and if you've noticed where our single point of failure is in this story kudos to you! and if not let's walk over it together.
You see the waiter could call in sick on a random day and that could quickly disrupt the flow of the restaurant resulting in bad customer experience. Same way our load balancer for whatever reason could fail and then we would more or less be back to square one struggling with a volume of requests. That's why in practice we need to ensure we have fallback load balancers so in a case where our master load balancer experiences downtime, the substitute will be called up and keep the whole process running!

Features of load balancers

Load balancers are quite dynamic and in addition to optimally routing requests to servers they can be used for quite a number of services like:

Logging
Encryption
Caching
Redirects
Autoscaling and many more

Load balancers are great and if you decide to use one in your project, here are a few services commonly used in the industry today

And that will be all for now. Next week I'll dive into the concept of clustering for NodeJS apps and how they can enhance performance of your web apps, until then Ciao!

Writing as a form of learning new concepts

Arinze Obi — Sat, 14 Jan 2023 06:00:00 +0000

This year one of my main goals is to "put myself out there". Naturally I tend to be less audible, do my job and avoid the spotlight as much as possible but this year I want to step out of the comfort zone a little (it's gotten a bit too comfy in there) and try out writing. I do this for two main reasons:

Connecting with new people
Enhancing my knowledge on a topic

You see there's a mainstream quote that goes something like

when one teaches, two learn.

which I think is a brilliant quote because for one it forces the teacher to solidify their knowledge before passing it down to another and secondly it creates an avenue for the teacher to also learn if there happens to be an aspect of the topic that they don't understand quite well.

I'm starting to learn nodejs in depth - not express, not nestjs, just raw and unfiltered nodejs and writing about my learnings would not only expose my knowledge gaps to a wider community who would be quick to call out on my errors, but also serve as a reference point if I was to forget such concepts later down the line.
I think the mistake most developers make when transitioning into backend development with nodejs is to immediately pick up frameworks after a few lessons on creating a server or reading contents from a file which to be honest I don't view as such a horrible act, I mean here is a snippet on how to send a "hello world" message using both nodejs and express as a server

nodejs

const http = require('http');

const server = http.createServer((req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/plain', 
  });
  res.end('Hello world')
});

server.listen(3000);

express

const app = require('express')();
app.use('/', (req, res) => res.send('hello world')
app.listen(3000)

I mean it's immediately obvious why you would want to use express right off the bat but this creates a huge knowledge gap into the underlying workings of nodejs and if a deep technical problem was to surface (memory leaks anyone? 👀), I don't think stack overflow would be enough to save you.

But naturally you get to a stage in your career where you move on from using existing frameworks and libraries to either wanting to contribute to them or creating your own entirely whether that be for internal or public use and at that point you will find yourself running back to the basics -- very much like I am right now 😅

So here's to more learning AND writing this year 🥂

Based opinion but for me a good measure of when to know you don't understand a technical topic quite well is when you can't educate a non-technical person on how it works or it's concept