DEV Community: Joel Ndoh

Running Unit Tests with MongoDB in a Node.js Express Application using Jest

Joel Ndoh — Sun, 26 May 2024 13:41:12 +0000

Hey everyone!

It's been a while since I last posted, and I'm excited to share something new today. Let's dive into running unit tests with MongoDB in a Node.js Express application. If you've ever struggled to set this up, this post is for you!

Why This Post?

Online resources often cover automated test setups for Node.js with SQL databases like PostgreSQL. However, setting up unit tests for Node.js, Express, and MongoDB is less common and can be quite challenging. Issues with running MongoDB in-memory for each test and the speed of test execution are just a couple of the hurdles.

Having used MongoDB for over three years, I've developed a robust method for running tests with MongoDB. My goal here is to help you set up your Node.js Express app to run tests smoothly with MongoDB.

Installing the Necessary Packages

Let's start by installing the essential packages:

jest: Jest is our test runner for Node.js Express applications.
jest-watch-typeahead: This package makes it easier to run specific tests. It allows us to select and search for test files and rerun failed tests quickly.
supertest: Supertest allows us to simulate API requests in our tests. mongodb The MongoDB driver for JavaScript.
uuid: This package generates unique IDs for each database used in our tests.

Setting Up the Jest Config File

Here's where we configure Jest to work with our setup. We include jest-watch-typeahead for flexibility and specify the test folder.

jest.config.js

module.exports = {
  testRegex: './__tests__/.*\\.spec\\.js$',
  watchPlugins: [
    'jest-watch-typeahead/filename',
    'jest-watch-typeahead/testname',
  ],
  testPathIgnorePatterns: ['<rootDir>/node_modules/', '<rootDir>/config/'],
  testEnvironment: 'node',
};

Handling Database Setup and Cleanup

Understanding the problem: By default, running tests in SQL databases can be done in-memory, which is fast and isolated. However, MongoDB lacks built-in in-memory support for isolated tests. Packages like mongodb-memory-server exist but have limitations with isolation.

Limitations of mongodb-memory-server

The mongodb-memory-server package allows us to spin up an in-memory instance of MongoDB for testing purposes. However, it comes with several limitations:

Shared Instance: mongodb-memory-server does not create separate instances for each test case. All tests share the same in-memory database, which can lead to data collisions and inconsistent test results.
Performance Overhead: Running an in-memory MongoDB instance can be resource-intensive. For large test suites, this can slow down the overall execution time and lead to performance bottlenecks.
Limited Features: Some features and configurations available in a full MongoDB instance may not be supported or fully functional in the in-memory server. This can lead to discrepancies between test and production environments.
Scalability Issues: As the number of tests grows, managing the in-memory database can become increasingly complex. Ensuring data isolation and cleanup becomes a significant challenge.
Given these limitations, we need a solution that ensures each test runs in an isolated environment, mimicking the behavior of in-memory databases used with SQL.

Our Solution

We'll create a new database for each test and drop it afterward. This approach uses UUIDs to ensure uniqueness and avoids database conflicts.

Setup File: setup.js

const mongoose = require('mongoose');
const { connectToDatabase } = require('../connection/db-conn');
const { redis_client } = require('../connection/redis-conn');
const { v4: uuidv4 } = require('uuid');

const setup = () => {
  beforeEach(async () => {
    await connectToDatabase(`mongodb://127.0.0.1:27017/test_${uuidv4()}`);
  });

  afterEach(async () => {
    await mongoose.connection.dropDatabase();
    await mongoose.connection.close();
    await redis_client.flushDb();
  });
};

module.exports = { setup };

Database Cleanup Script

To handle databases that may not be dropped properly after tests, we create a cleanup script. This script deletes all test databases whose names start with "test_".

Database Cleanup File: testdb-cleanup.js

const { MongoClient } = require('mongodb');

const deleteTestDatabases = async () => {
  const url = 'mongodb://127.0.0.1:27017';
  const client = new MongoClient(url);

  try {
    await client.connect();
    const databaseNames = await client.db().admin().listDatabases();
    const testDatabaseNames = databaseNames.databases.filter(db => db.name.startsWith('test_'));

    for (const database of testDatabaseNames) {
      await client.db(database.name).dropDatabase();
      console.log(`Deleted database: ${database.name}`);
    }
  } catch (error) {
    console.error('Error deleting test databases:', error);
  } finally {
    await client.close();
  }
};

deleteTestDatabases(); 
Updating package.json to Include Database Cleanup
To ensure cleanup happens after tests run, we update package.json:
package.json
{
  "scripts": {
    "start": "node index.js",
    "dev": "nodemon index.js",
    "test": "jest --runInBand --watch ./__tests__ && npm run test:cleanup",
    "test:cleanup": "node ./__tests__/testdb-cleanup.js"
  }
}

Running Tests

We'll place our tests in a folder called tests. Inside, we'll have apis for API tests and functions for unit tests.

Writing Tests

Use describe to group similar tests.

Function Tests: ./__tests__/functions/Rizz.spec.js

const RizzService = require('../../controllers/rizz-controller');
const Rizz = require('../../database/model/Rizz');
const { setup } = require('../setup');
setup();

describe('Getting the rizz', () => {
  it('should return the rizzes added to the database', async () => {
    await Rizz.create([{ text: 'First Rizz' }, { text: 'Second Rizz' }]);
    const result = await RizzService.GetLatestRizz();
    expect(result.total_docs).toBe(2);
  });
});

describe('Liking a rizz', () => {
  it('should increase the likes count of a rizz', async () => {
    const rizz = await Rizz.create({ text: 'First Rizz' });
    await RizzService.LikeRizz(rizz._id);
    const updatedRizz = await Rizz.findById(rizz._id);
    expect(updatedRizz.likes).toBe(1);
  });
});

API Tests: ./__tests__/apis/Rizz.spec.js

const request = require('supertest');
const { app } = require('../../app');
const { setup } = require('../setup');
setup();

describe('Rizz API', () => {
  it('should return the latest rizzes', async () => {
    await request(app)
      .post('/api/v1/rizz')
      .send({ text: 'First Rizz' });

    const response = await request(app)
      .get('/api/v1/rizz/latest?page=1&limit=100')
      .send();

    expect(response.body.data.total_docs).toBe(1);
  });

  it('should like a rizz', async () => {
    const rizzResponse = await request(app)
      .post('/api/v1/rizz')
      .send({ text: 'First Rizz' });

    const rizzId = rizzResponse.body.data._id;

    const response = await request(app)
      .post(`/api/v1/rizz/${rizzId}/like`)
      .send();

    expect(response.body.data.likes).toBe(1);
  });
});

Conclusion

Setting up unit tests with MongoDB in a Node.js Express app doesn't have to be daunting. By following these steps, you can ensure isolated, efficient tests. For the complete code, check out my GitHub repository:

GitHub - https://github.com/Ndohjapan/get-your-rizz

Happy testing! 🚀 #NodeJS #Express #MongoDB #AutomatedTesting #SoftwareDevelopment

Implementing Clean Architecture and Adding a Caching Layer

Joel Ndoh — Sun, 05 May 2024 17:02:42 +0000

In this article, we'll discuss implementing Clean Architecture and taking it a step further by adding a caching mechanism in front of our repository. This allows us to navigate between the database (Db) and Redis while performing a one-way data flow: read-only from Redis and write-only directly to the Db.

Building a Web Application with Clean Architecture and Caching

So far, for our final year project, we've been able to draft the database schema, which I shared in a previous LinkedIn post: https://www.linkedin.com/posts/joel-ndoh_dbdiagramio-database-relationship-diagrams-activity-7176510355722956800-m30p?utm_source=share&utm_medium=member_desktop.

I'd like to give a big shoutout to Rufai Quadri for designing the entire user interface.

We've begun development, with me handling the backend while Promise Sheggsmann and Jay Stance work on the dashboards and mobile app, respectively.

Since our system's requirements are dynamic, we aimed to create a plug-and-play system that can be easily adapted for any feature at any time.

Using Clean Architecture for a Modular and Maintainable System

Uncle Bob's Clean Architecture has been my go-to approach for every project I've worked on in the past eight months. There was no question about using it for this project either.

Over the past few months, I've observed various implementations of Clean Architecture, all adhering to the core concepts. Here's how I've structured mine:

Resource/Entity: These are the fundamental objects of the entire project, defining the basic data structure and properties.
Database: Here, I've modeled the schema for each resource and exposed a few database queries for each schema in a dedicated "schema-repository.js" file. This ensures that all database queries throughout the application are performed from a single location, preventing them from being scattered across the project. This makes it much easier to identify and fix any issues with database queries that might be affecting the database or application performance. This approach stems from my personal experience of having the database layer within the same layer as the service, which I found to be cumbersome and something I wouldn't want to repeat myself or recommend to others.
Cache Layer: This layer consists of a single file containing a list of frequently used Redis queries. Similar to the database queries, this promotes code organization by keeping all Redis queries in one place.
Database Service Layer: This layer is crucial for creating a well-cached application. By "cache," I mean the application caches static data whenever possible to prevent serving stale data to users. Here, we have a database service file for all our schemas. This implementation effectively bridges the gap between achieving a well-cached system and avoiding the issue of stale data.
Service Layer: This layer houses all our business logic. Each resource has its own dedicated service file named "resource_name-service.js". Previously, I used to combine the middleware, database, and service layers into a single "controller" layer. However, over time, while working on larger projects, this approach proved to be difficult to manage and maintain.
Routing/Middleware and Helper

Routing/Middleware: In this layer, we've ensured that no business logic runs here. It's solely for routing and validating user input. We then use middleware for tasks like rate limiting and authentication.
Helper: This layer contains functions that are not tightly coupled with our project's core business logic. Here, you might find functions for:

Handling external API calls
Sending messages to message queues
Receiving messages from message queues
Executing routine tasks that ultimately call methods within the service layer.

This concludes my breakdown of how I implemented Clean Architecture in my final year project.

Scalable Notification System Design for 50 Million Users (Database Design)

Joel Ndoh — Mon, 15 Apr 2024 09:01:49 +0000

Hey everyone, I will be writing about building a scalable notification system for an academic records management system I designed for my final year project.

This system needs to handle a whopping 50 million users, so scalability is key!

Project Constraints

Imagine this: students, lecturers, and a super admin (think academic head) are all buzzing around on the platform. The system needs to send out different notifications to these users.

For instance, a super admin might need to send announcements to a specific group of students. Students, on the other hand, might get reminders about upcoming classes, assignment deadlines, or new results.

Solution

To handle this, we'll use a NoSQL database like MongoDB. Here's how we'll structure things:

NotificationEntity Collection: This collection stores the core information about each notification type. Think of it as a notification template. We'll have details like the entity (e.g., coursework, class), the kind of event (e.g., creation, update), the notification type (reminder, announcement), and a message template with placeholders like lecturer_name or course_codes.

Here's a mongoose schema snippet for this collection:



const NotificationEntitiesSchema = new mongoose.Schema(
  {
    entity: {
      type: String,
      required: true,
    },
    entity_kind: {
      type: String,
      required: true,
    },
    type: {
      type: String,
      required: true,
      enum: notification_types,
    },
    template: {
      type: String,
      required: true,
    },
    is_deleted: {
      type: Boolean,
      default: false,
      select: false,
    },
    __v: { type: Number, select: false },
  },
  {
    timestamps: {
      createdAt: 'created_at',
      updatedAt: 'updated_at',
    },
  },
);

Notification Collection: This collection stores individual notifications fired off based on the templates in the NotificationEntity collection. We'll have the actual message, a reference to the notification entity it's based on, the type of actor who triggered it (super admin, lecturer), and their ID.
Here's another mongoose schema snippet for this collection:



const NotificationsSchema = new mongoose.Schema(
  {
    message: {
      type: String,
      required: true,
    },
    notification_entity: {
      type: mongoose.Schema.Types.ObjectId,
      ref: 'notification-entity',
      required: true,
    },
    actor_type: {
      type: String,
      enum: actors,
    },
    actor_id: {
      type: mongoose.Schema.Types.ObjectId,
      refPath: 'actor_type',
    },
  },
  {
    timestamps: {
      createdAt: 'created_at',
      updatedAt: 'updated_at'
    },
  }
);

NotificationReceivers Collection: This collection keeps track of who received a particular notification and their read status (read/unread, and if read, the date). Essentially, it links Notifications to Students.
Here's the mongoose schema snippet for this last collection:



const NotificationReceiversSchema = new mongoose.Schema(
  {
    notification: {
      type: mongoose.Schema.Types.ObjectId,
      ref: 'notification',
      required: [true, en['notification-id-required']],
    },
    student: {
      type: mongoose.Schema.Types.ObjectId,
      ref: 'student',
      required: [true, en['student-id-required']],
    },
    read_status: {
      type: {
        status: {
          type: Boolean,
          default: false,
        },
        date_read: {
          type: Date,
        },
      },
    },
    is_deleted: {
      type: Boolean,
      default: false,
      select: false,
    },
    __v: { type: Number, select: false },
  },
  {
    timestamps: true,
  }
);

Alright, so how do notifications get sent? Let's break it down:

Fetch the notification template: We'll grab the relevant notification entity from the NotificationEntity collection that matches the notification we want to send.
Craft the message: We'll use the template's message format and fill in any placeholders with relevant information.
Create the notification document: A new document is created in the Notification collection to store the actual notification message and references.
Identify recipients: We'll figure out who needs to receive this notification based on the notification type and any specific criteria (e.g., all students enrolled in a particular course).
Store notification receivers: For each recipient, a document is created in the NotificationReceivers collection linking them to the notification and marking the initial read status as unread.

This way, we can efficiently track who has seen what notification and scale the system to handle a massive number of users because each notification is stored separately with references to recipients.

Below is a simple illustration to explain the database tables in a Relational Database Management System (RDBMS)

So, that's the blueprint for a scalable notification system that can handle millions of users on our academic management platform. Hope this walkthrough was helpful!

Unraveling the Layers of System Requirements in Software Architecture

Joel Ndoh — Sun, 11 Feb 2024 20:55:39 +0000

Greetings, Tech Enthusiasts! 👋

It's been a while since I've delved into the world of blogging, and what better way to make a comeback than by unraveling the intricate layers of System Requirements in Software Architecture.

Understanding Performance 🚀

In the ever-evolving landscape of software design, the performance of a system is paramount. We're not just talking about how fast or responsive it should be, but breaking it down into measurable goals. Consider aiming for 90% of requests to be responded to in a crisp 50ms.

To truly grasp this, let's introduce a coffee bar analogy:

Latency: Picture the time from ordering a coffee to the barista handing it over. It's the wait time plus processing time.

Throughput: Think of throughput as how many coffee cups a barista can whip up in a given timeframe.

Scaling Up: The Art of Scalability 📈

Next on our exploration is Scalability. It's not just about handling a multitude of users simultaneously; it's about doing so gracefully. Think of it as ensuring your system can seamlessly dance through the traffic of a large user base without missing a beat.

Reliability in the Face of Challenges 🛡️

Now, let's talk about Reliability. A robust system isn't just efficient; it's resilient. It withstands failures, data center downtimes, and unexpected events with a stoic demeanor.

The Fort Knox of Software: Security 🔒

Security is a non-negotiable aspect of system requirements. We aim to send and store data securely, warding off any unauthorized attempts to breach our digital fortress.

Smooth Sailing through Deployment Challenges ⚙️

Enter Deployment—a formidable challenge in managing large-scale, distributed systems. We aim for frictionless deployments of our complex architectures, comprising microservices, databases, and more.

Choosing the Right Tools: Technology Stack ⚖️

Last but not least, the Technology Stack. Depending on our system requirements, such as performance and scalability, choosing the right tech stack becomes crucial. It's akin to selecting the tools that best fit the job when crafting a large-scale system.

Understanding and optimizing these six aspects will pave the way for robust and efficient systems. Stay tuned as we delve deeper into each element in the upcoming posts.

Are you ready to elevate your understanding of Software Architecture? Let's embark on this journey together! 💻✨

SystemRequirements #TechInsights #SoftwareArchitecture #Performance #Scalability #Reliability #Security #Deployment #TechStack

The Importance of JSON Web Tokens in Microservices Architecture

Joel Ndoh — Mon, 27 Mar 2023 11:19:38 +0000

JWTs are a compact, URL-safe means of representing claims to be transferred between two parties. In the context of microservices architecture, JWTs can be used to securely authenticate and authorize requests between services.

How It Works

Here's how it works: when a user logs into your application,

The authentication service generates a JWT containing the user's identity and any relevant permissions.
This JWT is then passed to the user's client application, which can then use it to make requests to other microservices in the system.
Each microservice can verify the authenticity of the JWT using a shared secret key.
This key is securely stored on each microservice and is used to verify the signature of the JWT.
Once the JWT is verified, the microservice can extract the user's identity and any relevant permissions from the token and use them to authorize the request.

Benefits

One of the key benefits of using JWTs in microservices architecture is that they are stateless. Unlike traditional session-based authentication, where a server has to maintain session information for each user, JWTs contain all the necessary information within the token itself.

This means that each microservice can independently verify the token without relying on a central authentication server, making the system more resilient to failures and easier to scale.

Another benefit of using JWTs is that they can be used across multiple domains. Because JWTs are self-contained, they can be easily passed between different services or even different applications. This makes it easier to integrate with third-party services or to build a system that spans multiple domains.

In summary, JSON Web Tokens are an important tool in microservices architecture. They provide a secure, stateless way of authenticating and authorizing requests between services, making it easier to build complex systems that are scalable and resilient. If you're building a microservices architecture, be sure to consider using JWTs as part of your authentication and authorization strategy.

Also, if you found this post helpful, please consider giving it a like, sharing what you think about it in the comment or sharing it with others. Thanks for reading!

My takes on EsLint and Prettier against TypeScript

Joel Ndoh — Mon, 27 Mar 2023 00:33:17 +0000

As a developer, I've always been a strong advocate for using Eslint and Prettier for type safety in JavaScript, even over
TypeScript programming language. I know this might be a bit controversial, but hear me out.

Number 1

First of all, Eslint and Prettier offer a lot of flexibility and customization options when it comes to enforcing coding standards and style. This not only improves code readability and consistency but also helps catch potential errors and bugs before they become a problem. With Typescript, while it offers type safety, it can be more rigid and may limit the ability to customize and enforce coding standards in the same way.

Number 2

Secondly, Eslint and Prettier are very easy to integrate into any JavaScript project, regardless of the framework or libraries being used. This can save a lot of time and effort, especially when working on multiple projects with different setups. With Typescript, there can be a steeper learning curve and more effort required to integrate it properly into a project.

Number 3

Finally, Eslint and Prettier have a large and active community, constantly updating and improving the tools with new features and fixes. This ensures that the tools remain up to date with the latest best practices and can adapt to changing development trends. While Typescript also has a large community, it may not be as active in updating and improving the language as frequently.

Of course, this is just my personal preference and I understand that different developers have different opinions and experiences. However, I believe that Eslint and Prettier provide a great solution for type safety in JavaScript and should be considered as a viable option, even over Typescript.

What are your thoughts on this? Do you prefer Eslint and Prettier or Typescript for type safety in JavaScript? Let's start a conversation in the comments!

How to prevent data loss when a Postgres container is killed or shut down.

Joel Ndoh — Sun, 26 Mar 2023 21:27:20 +0000

I do not like to make my blog contents so long when I can easily go straight to the point.

The simple answer to this problem is simply docker volume

Why Docker Volume

The main concept behind using Docker volumes for backups is to create a copy of the data outside the container. Each time the container is restarted, the data is copied from the local system into the Docker container file system. This ensures that the data is always up-to-date and consistent with the latest changes.

How To Create Docker Volume for PostgreSQL

To create a Docker volume for PostgreSQL, use the following command:

 docker volume create pgdata

This will create a new Docker volume called pgdata that you can use to store the data for your PostgreSQL container.

Start a new PostgreSQL container using the following command:

docker run -d --name postgresql -v pgdata:/var/lib/postgresql/data postgres:latest

This command starts a new PostgreSQL container called postgresql and maps the pgdata volume to the /var/lib/postgresql/data directory in the container. This means that the data stored in the container will be stored in the pgdata volume, which is separate from the container and will persist even if the container is deleted or restarted.

If the container is deleted or restarted, you can simply start a new container and map the pgdata volume to the /var/lib/postgresql/data directory again, and your data will be restored. You do not need to create backups of your data or copy the data back into the container manually.

Also you can check the docs for more information on docker volumes.

I usually use docker volume for development, but I have not really considered its importance when it comes to production if I won't be using a postgres container. I don't know about you? Tell me what you think in the comment section.

Also, if you found this post helpful, please consider giving it a like or sharing it with others who may be facing a similar issue. Thanks for reading!

How To Prevent HPP and XSS Attacks In Nodejs

Joel Ndoh — Sun, 19 Mar 2023 19:07:21 +0000

In today's world, cyber attacks are becoming more and more sophisticated. Two common types of attacks that websites and applications face are:

HPP (HTTP Parameter Pollution)
XSS (Cross-Site Scripting).

HPP

HPP attacks occur when the HTTP parameters are polluted with duplicate or malicious values.

XSS

While XSS attacks occur when attackers inject malicious scripts into a website or application. It occurs the most when we users are able to make queries using the URL.

Fortunately, there are modules available in Node.js that can help prevent these types of attacks. The "hpp" module can prevent HPP attacks, while the "xss-clean" module can prevent XSS attacks.

Prevent HPP

The "hpp" module works by preventing the duplication of HTTP parameters. It does this by checking each parameter and removing duplicates before passing the request to the next middleware. This ensures that the server receives only one instance of each parameter, preventing any HPP attacks that may be attempted.

To use the "hpp" module, simply install it using NPM

npm install hpp
const hpp = require('hpp');

Require it in your code:

const hpp = require('hpp');

Then add the middleware to your application:

app.use(hpp());

Prevent XSS

The "xss-clean" module, on the other hand, prevents XSS attacks by sanitizing user input. It does this by escaping characters that could be used to execute scripts, such as "<" and ">". This ensures that any user input is safe to use and cannot be used to execute malicious scripts.

To use the "xss-clean" module, install it using NPM

npm install xss-clean

Require it in your code:

const xss = require('xss-clean');

const xss = require('xss-clean');

app.use(xss());

In conclusion, HPP and XSS attacks are two common types of attacks that websites and applications face. Fortunately, modules such as "hpp" and "xss-clean" are available in Node.js to prevent these attacks. By using these modules in your Node.js application, you can help ensure that your application is secure and protected from these types of attacks.

I post stuff around DevOps and Backend Engineering, you can follow me if you found this helpful.

How To Fix "Starting broker... completed with 0 plugins." In RabbitMq

Joel Ndoh — Sat, 18 Mar 2023 18:00:17 +0000

When you install RabbitMQ, it comes with a default configuration that includes some plugins. However, if you try to run RabbitMQ without any additional configuration, you may encounter an error like the one below:

Logs: <stdout>
        c:/Users/<COMPUTER NAME>/AppData/Roaming/RabbitMQ/log/rabbit@Japan.log
        c:/Users/<COMPUTER NAME>/AppData/Roaming/RabbitMQ/log/rabbit@Japan_upgrade.log

  Config file(s): (none)

  Starting broker... completed with 0 plugins.

This error message indicates that RabbitMQ was unable to start because it could not find any plugins to load. Fortunately, this error can be easily fixed by installing the management plugin.

To install the management plugin, follow these steps:

Open a command prompt or terminal window.
Navigate to the RabbitMQ sbin directory. For example, on Windows, the command may look like:

cd "C:\Users\ndohj\Downloads\rabbitmq-server-windows-3.11.10\rabbitmq_server-3.11.10\sbin"

Run the following command to enable the management plugin:

rabbitmq-plugins enable rabbitmq_management

This command installs the management plugin, which provides a web-based interface for managing RabbitMQ.

Restart the RabbitMQ server by running the following command:

rabbitmq-server.bat

This command starts the RabbitMQ server with the newly installed management plugin.

Open a web browser and navigate to http://localhost:15672. This will bring up the RabbitMQ management interface.

If everything was installed and configured correctly, you should see a login page where you can enter your RabbitMQ credentials.

That's it! You should now be able to use RabbitMQ with the management plugin installed. If you encounter any further issues, be sure to leave a comment or check the RabbitMQ documentation or seek help from the RabbitMQ community.

And don't also forget to follow and react to the post 😎

Why Is EsLint Important In Nodejs

Joel Ndoh — Thu, 16 Mar 2023 18:32:27 +0000

ESLint is a popular tool used in Node.js development as a devDependency. Its main function is to analyze and find issues in your code that may cause errors or affect code quality. ESLint is a static analysis tool that checks your JavaScript code for syntax and style errors, as well as other common issues.

When ESLint is added to a Node.js project as a devDependency, it can help improve code quality, consistency, and maintainability. It enforces coding standards and helps prevent mistakes that can lead to bugs and security vulnerabilities. By detecting issues early in the development process, it can save time and effort in the long run by reducing the time spent on debugging and maintenance.

ESLint can be configured to match your team's coding style and preferences, which ensures that everyone adheres to the same coding standards. It can be integrated into your development workflow, such as your text editor or Continuous Integration (CI) pipeline, to provide immediate feedback as you write code.

Overall, ESLint is an essential devDependency for Node.js development, as it helps ensure that your code is high-quality, maintainable, and free from errors.

Don't forget to like and also follow for more simple analogies of complex concepts in web development and DevOps

How To Use "--save-dev" when installing Nodejs Modules

Joel Ndoh — Tue, 14 Mar 2023 19:26:23 +0000

Why Use `--save-dev`

When installing npm packages, the --save-dev option is used to indicate that the package being installed is a development dependency.

Development dependencies are packages that are only needed during the development process, such as testing libraries or build tools. They are not required for the production environment where the application will be deployed.

Importance

The importance of using --save-dev when installing npm packages is that it helps to manage dependencies more efficiently. By separating production dependencies from development dependencies, it is easier to track which packages are needed for each environment. This makes it easier to deploy the application to the production environment, as only the necessary dependencies are installed.

Additionally, when other developers work on the project, they can easily see which packages are used for development purposes and which are used for production purposes. This helps to prevent confusion and reduces the risk of including unnecessary packages in the production environment.

Summary

Overall, using --save-dev when installing npm packages is an important best practice for managing dependencies and ensuring that applications are properly configured for deployment.

Don't forget to leave a comment, like and even follow if you found this interesting. 😎

Great Analogy To Explain ID Tokens Vs Access Tokens

Joel Ndoh — Mon, 06 Mar 2023 14:34:33 +0000

Analogy For ID Token

Imagine you're planning to attend a fancy party at a private club. Before you can enter the club, you need to show the bouncer your ID to prove that you're on the guest list. In this analogy, the bouncer represents the server that's responsible for controlling access to the club, and your ID represents your ID token.

What Is ID Token

An ID token is a type of token that's used in authentication protocols like OAuth 2.0 and OpenID Connect. It's a JSON Web Token (JWT) that contains information about the authenticated user, such as their user ID and email address. When a user logs in to an application using a third-party identity provider (like Google or Facebook), the identity provider sends an ID token to the application server to verify the user's identity. The application server can then use the information in the ID token to create a user account or grant access to certain resources.

Analogy For Access Token

Now let's say you're inside the club and you want to order a drink from the bar. You need to show the bartender your membership card to prove that you're allowed to order drinks. In this analogy, the bartender represents the server that's responsible for controlling access to the club's resources (like drinks), and your membership card represents your access token.

What is Access Token

An access token is a type of token that's used in authorization protocols like OAuth 2.0. It's a string of characters that represents a user's permission to access certain resources. When a user logs in to an application using a third-party identity provider, the application can request an access token that allows the user to access certain resources (like their Google Drive files). The application can then include the access token in API requests to prove that the user has permission to access those resources.

So, to summarize:

ID tokens are like IDs that prove your identity and allow you to enter the party (authenticate).
Access tokens are like membership cards that grant you permission to access certain resources (authorize).

Don't forget to leave a comment if you found this interesting. 😎