DEV Community: Vinay Madan

import vs require in JS

Vinay Madan — Sun, 06 Oct 2024 23:23:31 +0000

The most common question that is asked is, What are the key differences between import vs require in Javascript?

Import and Export are ES6 features(Next gen JS).
Require is old school method of importing code from other files

This simple image will help to you understand the differences between require and import.

Loading is synchronous(step by step) for require on the other hand import can be asynchronous

The major difference is in require, entire JS file is called or included. Even if you don't need some part of it.

var myObject = require('./otherFile.js'); //This JS file will be included fully.

Whereas in import you can extract only objects/functions/variables which are required.

import { getDate }from './utils.js';

//Here I am only pulling getDate method from the file instead of importing full file

Another major difference is you can use require anywhere in the program where as import should always be at the top of file

Edit: In Latest node versions you can use destructuring. It will look like this

const { getDate } = require('./date.js');

Playwright Annotations

Vinay Madan — Sat, 05 Oct 2024 07:42:42 +0000

What Are Annotations in Playwright?

Annotations are markers that you can attach to your tests to provide additional context, control test execution, or categorize tests. Playwright comes with several built-in annotations, and you can also create custom ones to suit your needs.

Built-in Annotations

Playwright provides a set of built-in annotations that can be used to control the behavior of your tests:

test.skip(): Marks the test as irrelevant. Playwright will skip running this test. Use this when the test is not applicable under certain configurations.

import { test } from '@playwright/test';

test.skip('skip this test', async ({ page }) => {
  // This test will be skipped
});

test.fail(): Marks the test as expected to fail. Playwright will run the test and expect it to fail. If the test does not fail, Playwright will report it as an issue.

import { test } from '@playwright/test';

test.fail('this test is expected to fail', async ({ page }) => {
  // This test is expected to fail
});

test.fixme(): Marks the test as failing but will not run it. Use this for tests that are slow or have issues that prevent them from running.

`import { test } from '@playwright/test';

test.fixme('this test is not yet ready', async ({ page }) => {
// This test will not run
});`

test.slow(): Marks the test as slow, which increases the timeout duration for this test by three times.

import { test } from '@playwright/test';

test.slow('this test is slow', async ({ page }) => {
  // This test has an extended timeout
});

Focus and Skip Tests

You can focus on specific tests or skip them based on the following conditions:

Focus a Test: Run only the focused tests in the entire test suite.

import { test } from '@playwright/test';

test.only('focus this test', async ({ page }) => {
  // This test will be the only one executed
});

Conditionally Skip a Test: Skip a test based on a condition.

import { test } from '@playwright/test';

test('conditionally skip this test', async ({ page, browserName }) => {
  test.skip(browserName === 'firefox', 'Still working on Firefox support');
});

Grouping Tests

Grouping tests allow you to organize them logically and apply hooks at the group level.

import { test } from '@playwright/test';

test.describe('Group of tests', () => {
  test('test one', async ({ page }) => {
    // Test implementation
  });

  test('test two', async ({ page }) => {
    // Test implementation
  });
});

Tagging Tests

Tags help you categorize tests and run specific subsets based on these tags. Tags start with the @ symbol.

Tag a Single Test:

import { test } from '@playwright/test';

test('test login page', {
  tags: ['@fast'],
}, async ({ page }) => {
  // Test implementation
});

Tag a Group of Tests:

import { test } from '@playwright/test';

test.describe('Group with tags', {
  tags: ['@report'],
}, () => {
  test('test report header', async ({ page }) => {
    // Test implementation
  });

  test('test full report', {
    tags: ['@slow', '@vrt'],
  }, async ({ page }) => {
    // Test implementation
  });
});

Run Tests by Tag

Use the --grep option to run tests with specific tags:

npx playwright test --grep @fast

Skip tests with a specific tag using --grep-invert:

npx playwright test --grep-invert @fast

Run tests containing either tag (logical OR):

npx playwright test --grep "@fast|@slow"

Run tests containing both tags (logical AND) using regex lookaheads:

npx playwright test --grep "(?=.*@fast)(?=.*@slow)"

Annotating Tests

Annotations provide more detailed context beyond tags. You can add annotations with a type and description.

Annotate a Single Test:

import { test } from '@playwright/test';

test('test login page', {
  annotations: [
    { type: 'issue', description: 'https://github.com/microsoft/playwright/issues/23180' },
  ],
}, async ({ page }) => {
  // Test implementation
});

Annotate a Group of Tests:

import { test } from '@playwright/test';

test.describe('Annotated tests group', {
  annotations: [{ type: 'category', description: 'report' }],
}, () => {
  test('test report header', async ({ page }) => {
    // Test implementation
  });

  test('test full report', {
    annotations: [
      { type: 'issue', description: 'https://github.com/microsoft/playwright/issues/23180' },
      { type: 'performance', description: 'very slow test!' },
    ],
  }, async ({ page }) => {
    // Test implementation
  });
});

Conditional Hooks

Use hooks like beforeEach conditionally to skip setup code based on conditions.

import { test } from '@playwright/test';

test.beforeEach(async ({ page, isMobile }) => {
  test.fixme(isMobile, 'Settings page does not work in mobile yet');
  await page.goto('http://localhost:3000/settings');
});

Runtime Annotations

You can also add annotations while the test is running:

import { test } from '@playwright/test';

test('example test', async ({ page, browser }) => {
  test.info().annotations.push({
    type: 'browser version',
    description: browser.version(),
  });

  // Test implementation
});

Summary

Annotations in Playwright offer a flexible way to manage and categorize your tests, control their execution, and enhance reporting. By leveraging built-in annotations, tags, and custom annotations, you can tailor your testing strategy to fit your specific needs, improve test organization, and make debugging easier

Getting started with Appium 2.0

Vinay Madan — Wed, 07 Aug 2024 04:28:26 +0000

Appium 2.0 is a big update to the Appium framework, introducing new features. It focuses on becoming a platform with independent driver and plugin ecosystems while removing old and deprecated functions.

Appium 2.0 Server Setup:
There are two options available for installing the Appium server environment. The first method involves manually installing individual components, such as the Appium server, drivers, plugins, and appium-doctor, using separate commands.

However, in this blog, we will focus on the second method, which utilizes the Appium Installer NPM Package.

This approach simplifies the installation process by guiding us through each step via the Appium CLI. You no longer need to remember specific commands, as the installer takes care of everything seamlessly and sequentially. Additionally, it automatically sets necessary environment variables, further streamlining the setup.

Download the Latest Version of Node:
Download the stable version of Node JS from its official website based on your OS.
Verify Node and NPM Installation:
Open the terminal and enter “node -v”to check the Node.js version and “npm -v” for npm’s version. Note that npm is bundled with Node.js and should be automatically installed during the process.
The version I used during setup might differ from the current one, as newer versions may have been released by the time you attempt the setup.

Install Appium Installer Package: Obtain the Appium installer package by executing the provided command, which installs it globally.

npm install appium-installer -g

Start Appium Installer and Setup: Launch the Appium installer using the given command to access various setup options. Follow the instructions for proper setup, skipping any steps that are already completed or unnecessary.

Set Up Android Environment: Set up the Android environment, which provides essential tools and infrastructure for communication with Android devices. Choose ‘Need help setting up Android Environment to run your Appium Test’ to download the required binaries and set up environment variables.

Set Up iOS Environment:
Choose ‘Need help setting up iOS Environment to run your Appium Test’ to download the required binaries and set up environment variables.
Select Target Devices and Browsers:
Choose target devices for running your Appium tests, including both virtual and real devices.

Also, specify the browser setup for emulators.

Install Appium Server: Selecting the option ‘Install Appium Server’ will download and install the latest Appium server, ensuring you have the most up-to-date version.

Install Appium Plugins: Opt for the ‘Install Appium Plugin’ option to view and select from a list of available Appium plugins that suit your requirements. Download the chosen plugins with a simple command.

Run Appium Doctor: Use the ‘Run Appium Doctor’ option to verify if your Appium setup is successful and ready for running tests.

Download Appium Inspector: Download Appium Inspector from the official website according to your operating system. Install the Inspector and utilize it to connect to devices (real or emulated) and inspect elements.

Start Appium Server: Run the ‘appium’ command to start the Appium server, and you are all set to begin your Appium tests with version 2.0.

Using Localstack for Component tests

Vinay Madan — Tue, 09 Jul 2024 01:58:03 +0000

The Ask?

I was always wondering if I could test Cloud Services locally without the hassle and expense of provisioning cloud services using one of the providers like AWS, Azure, or GCP then I found LocalStack, an open-source project that allows us to emulate multiple AWS cloud services, such as SQS, EC2, and CloudFormation, on the local machine

Introduction

LocalStack is a cloud service emulator that runs in a single container on your laptop or in your CI environment. With LocalStack, you can run your AWS applications or Lambdas entirely on your local machine without connecting to a remote cloud provider! Whether you are testing complex CDK applications or Terraform configurations, or just beginning to learn about AWS services, LocalStack helps speed up and simplify your testing and development workflow.

The required cloud service environment can be simulated using localstack and it supports wide range of cloud services including S3, lambda, SQS, SNS, SES, RDS, DynamoDB etc.

Component testing allows to test the behavior of the individual components or modules separately and ensure the it’s working as expected before integrating it into a large system. In the event-driven architecture, component testing is crucial due to the complex nature of integration testing caused by its asynchronous and distributed nature. Lambda functions are responsible for handling different events. Component testing can be utilised to identify defects or issues and to verify lambda specific logics by isolating and independently testing them.

Pre-requisite

There are some prerequisites to setup localstack with quarkus application.

Install Docker — Localstack emulates cloud services within a single docker container. Therefore, Docker should be installed and docker daemon should be running on the machine.
Install AWS CLI — You may need to run aws cli commands to check the cloud services created in test containers.

Setup

First of all, use the below cmd to create a directory app and create index.js, docker-compose.yml, and trust-policy.json.

index.js — this file is the main entry file for lambda and it contains the handler function. When the lambda function is invoked, it runs this handler method, and you will see the console statement inside your terminal. This method expects three arguments: event, context, and callback. Read more about the lambda argument here in the How it Works Section

docker-compose.yml — this file is used to start Localstack inside the docker container with some additional environments and configurations.

trust-policy.json —this file is used to define the IAM role that grants the function permission to access resources and services. You can read more about IAM here.

You have now successfully deployed your lambda function to localstack running inside a docker container on your system.

Execute the below command to invoke your lambda.

Switch to the terminal where you had run ‘docker-compose up’ and you will see Lambda is triggered inside your terminal.

Congratulations! You’ve successfully invoked your lambda function and it works as it would have in the AWS console.

The major upside of running localstack is that it enables you to

Explore other AWS services without worrying about incurring any cost by accident
Test your production code locally (thus crush some nasty bugs beforehand)

Further we can extend it to other AWS Services such as Dynamo DB

NodeJS Local Examples with DynamoDB/Docker
Some samples to test DynamoDB locally through Docker

 # Download & Run LocalStack
  $ docker pull localstack/localstack:latest
  $ docker run -it -p 4567-4578:4567-4578 -p 8080:8080 localstack/localstack

  # Add some fake credentials locally
  $ vi ~/.aws/credentials

  # Data to include >>>>>>>>>>>>>>>>>>>>>>>>>>>>
  [fake]
  region = eu-west-1
  aws_access_key_id = **NOT_REAL**
  aws_secret_access_key = **FAKE_UNUSED_CREDS**
  # Data to include <<<<<<<<<<<<<<<<<<<<<<<<<<<<

  npm i aws-sdk
  node nodejs-dynamodb-create-table-local.js
  node nodejs-dynamodb-populate-table-local.js
  node nodejs-dynamodb-read-table-local.js

And you can also view the new dynamoDB resource created at local dashboard

Sample scripts

nodejs-dynamodb-create-table-local.js

const AWS = require("aws-sdk")

// URI and other properties could be load by ENV Vars or by property file (.env)
AWS.config.update({
  region: "us-west-2",
  endpoint: "http://localhost:4569"
  })

const dynamodb = new AWS.DynamoDB()

const params = {
    TableName : "Users",
    KeySchema: [{ AttributeName: "email", KeyType: "HASH"}],
    AttributeDefinitions: [{ AttributeName: "email", AttributeType: "S" }],
    ProvisionedThroughput: {
      ReadCapacityUnits: 5,
      WriteCapacityUnits: 5
    }
}

dynamodb.createTable(params, console.log)

nodejs-dynamodb-populate-table-local.js

const AWS = require("aws-sdk")

// URI and other properties could be load by ENV Vars or by property file (.env)
AWS.config.update({
    region: "us-west-2",
    endpoint: "http://localhost:4569"
})

const dynamodb = new AWS.DynamoDB()

var params = {
    TableName:"Users",
    Item: {
        email : { S:"jon@doe.com"},
        fullname: { S:"Jon Doe" },
        role: { S:"Super Heroe" }
    }
};

dynamodb.putItem(params,console.log)

nodejs-dynamodb-read-table-local.js

const AWS = require("aws-sdk")

// URI and other properties could be load by ENV Vars or by property file (.env)
AWS.config.update({
    region: "us-west-2",
    endpoint: "http://localhost:4569"
})

const docClient = new AWS.DynamoDB.DocumentClient()
const email = process.env.EMAIL || 'jon@doe.com'

const params = {
    TableName: "Users",
    KeyConditionExpression: "#email = :email",
    ExpressionAttributeNames:{
        "#email": "email"
    },
    ExpressionAttributeValues: {
        ":email":email
    }
}

docClient.query(params,console.log)

Difference between CommonJS and ESM modules

Vinay Madan — Fri, 28 Jun 2024 02:37:18 +0000

Intro

CommonJS (CJS) and ECMAScript Modules (ESM) are two different module systems in JavaScript used for organizing and structuring code. They have different syntax and behaviors, and they are often used in different contexts. Let's explore each format:

CommonJS (CJS):

Synchronous: CommonJS modules are loaded synchronously. When you require a module, it is loaded and executed immediately.
Server-Side: CommonJS modules were originally designed for server-side JavaScript (e.g., Node.js). They are commonly used in server-side applications and back-end development.
require and module.exports: CommonJS modules use require to import modules and module.exports to export values from a module. For example:

// Importing a module
   const someModule = require('./someModule');

   // Exporting a value
   module.exports = someValue;

No Support for Tree Shaking: CommonJS modules don't support tree shaking, which means all exports are bundled, even if they are not used in the consuming code. This can result in larger bundle sizes in front-end applications.
Dynamic Imports: CommonJS does not support dynamic imports. You cannot conditionally import modules based on runtime conditions.

ECMAScript Modules (ESM):

Asynchronous: ESM is asynchronous. Modules are loaded and executed asynchronously, which can lead to better performance in certain scenarios.
Front-End and Back-End: ESM modules are supported in both front-end (browsers) and back-end (Node.js) environments. They are becoming more widely used for front-end development.
import and export Statements: ESM modules use import to import modules and export to export values from a module. For example:

 // Import a module
import { someValue } from './myModule';

// Export a value from a module
export default someValue;

Key Differences:

Synchronous vs. Asynchronous Loading: CommonJS modules are loaded synchronously, which means they block the execution of code until the module is loaded. ESM modules, on the other hand, are loaded asynchronously, allowing for better parallelism.
Static vs. Dynamic Imports: ESM supports static imports, meaning that the import statements are resolved at compile time. CommonJS supports dynamic imports, where module paths can be constructed dynamically at runtime.
Browser Compatibility: ESM is more suitable for modern web browsers, while CommonJS is often used in server-side environments. However, with the growth of JavaScript bundlers and transpilers, ESM can also be used in web applications with broader compatibility.
Syntax: ESM uses import and export statements, which are more concise and align with the language's evolution. CommonJS uses require() and module.exports, which have a different syntax.

Summary

CommonJS and ESM are two module systems in JavaScript, with CommonJS historically used in server-side environments like Node.js, and ESM emerging as the standard for modern web and server-side applications. Your choice of module system depends on your target environment and project requirements.

Design Patterns in Node.js

Vinay Madan — Mon, 24 Jun 2024 04:09:12 +0000

Node.js is a popular JavaScript runtime that allows developers to build scalable network applications using an event-driven, non-blocking I/O model. Like any sophisticated framework, Node.js applications can benefit from using proven design patterns to promote code reuse, maintainability and robustness. This article will provide an overview of some of the most useful design patterns for Node.js development
Introduction to Design Patterns
Design patterns are tried-and-true solutions to recurring problems that software developers encounter during their coding journey. They provide a structured approach to solving challenges and promote best practices in software architecture. By incorporating design patterns, developers can create more robust, maintainable, and extensible codebases.

Why Design Patterns Matter in Node.js

Node.js, known for its non-blocking event-driven architecture, presents unique challenges and opportunities in software design. Applying design patterns tailored to Node.js can lead to more efficient and optimized applications. Let’s explore some key design patterns that are particularly valuable in the Node.js ecosystem:

Singleton Pattern

The Singleton pattern ensures that a class has only one instance and provides a global point of access to it. In Node.js, where modules can be cached and shared across the application, using the Singleton pattern can help manage resources effectively. For instance, a database connection pool can be implemented as a singleton to prevent resource wastage.

class Database {
  constructor() {
    this.connection = null;
  }

  static getInstance() {
    if (!Database.instance) {
      Database.instance = new Database();
    }
    return Database.instance; 
  }

  connect() {
    // connect to database
    this.connection = 'Connected'; 
  }
}

const db1 = Database.getInstance();
const db2 = Database.getInstance();

console.log(db1 === db2); // true

db1.connect(); 

console.log(db1.connection); // 'Connected'
console.log(db2.connection); // 'Connected'

The key points are:

The constructor is made private to prevent direct instantiation.
The static method getInstance() creates an instance if it doesn't exist yet, and returns it. This ensures only one instance is created.
The instances db1 and db2 refer to the same object.
When db1 connects, db2 also gets the connection because they are the same object.
This ensures there is only one database instance and prevents duplicating connections. The Singleton pattern is useful for situations where only one instance of a class should exist.

Factory Pattern

The Factory pattern offers a way to create objects without specifying the exact class of object that will be created. In a Node.js context, this can simplify object creation, especially when dealing with asynchronous operations such as reading files or making API calls. By abstracting object creation, the Factory pattern enhances code readability and reusability.

class Car {
  constructor(model, price) {
    this.model = model;
    this.price = price;
  }
}

class CarFactory {
  createCar(model) {
    switch(model) {
      case 'civic':
        return new Car('Honda Civic', 20000);
      case 'accord':  
        return new Car('Honda Accord', 25000);
      case 'odyssey':
        return new Car('Honda Odyssey', 30000);
      default:
        throw new Error('Unknown model');
    }
  }
}

const factory = new CarFactory();

const civic = factory.createCar('civic');
const accord = factory.createCar('accord');

console.log(civic.model); // Honda Civic 
console.log(accord.model); // Honda Accord

The key points are:

The CarFactory class handles object creation logic.
The createCar() method returns a Car instance based on the model.
The client code uses the factory instead of direct constructor calls.
This abstracts away the object creation logic and allows easy extension of supported models. The Factory pattern is useful when there is complex object creation logic that should not be coupled to client code.

Observer Pattern

Node.js’s event-driven nature aligns well with the Observer pattern. This pattern involves a subject that maintains a list of its dependents, called observers, and notifies them of any state changes. In the context of Node.js, this can be leveraged to build event-driven systems, such as real-time applications and chat applications.

class Subject {
  constructor() {
    this.observers = []; 
  }

  subscribe(observer) {
    this.observers.push(observer);
  }

  unsubscribe(observer) {
    this.observers = this.observers.filter(o => o !== observer);
  }

  notify(data) {
    this.observers.forEach(o => o.update(data));
  }
}

class Observer {
  constructor(name) {
    this.name = name;
  }

  update(data) {
    console.log(`${this.name} received ${data}`);
  }
}

const subject = new Subject();

const observer1 = new Observer('Observer 1');
const observer2 = new Observer('Observer 2');

subject.subscribe(observer1);
subject.subscribe(observer2);

subject.notify('Hello World');
// Observer 1 received Hello World 
// Observer 2 received Hello World

subject.unsubscribe(observer2);

subject.notify('Hello Again');
// Observer 1 received Hello Again

The key points are:

The Subject maintains a list of observers.
The observers subscribe and unsubscribe to the subject.
When notify() is called, the subject updates all subscribed observers.
This allows publishing updates to multiple objects without coupling the publisher to the subscribers. The Observer pattern is useful for event handling and asynchronous workflows.

Middleware Pattern

Node.js’s middleware architecture is widely used for handling requests and responses in web applications. The Middleware pattern involves a chain of functions that process a request sequentially. Each function can modify the request or response before passing it to the next function in the chain. This pattern enhances modularity and allows developers to plug in various functionalities without tightly coupling them.

const express = require('express');
const app = express();

const logger = (req, res, next) => {
  console.log('Logged');
  next();
}

const authenticate = (req, res, next) => {
  // authenticate user 
  next(); 
}

app.use(logger); 
app.use(authenticate);

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

app.listen(3000);

The key points are:

The middleware functions logger and authenticate wrap the route handler.
They can execute logic before and after the route.
The next() function passes control to the next middleware.
app.use() mounts the middleware globally.
This allows decomposing request handling into smaller reusable units. The middleware pattern is very common in Express and other Node.js frameworks for things like logging, authentication, etc.

Some other examples of middleware are body parsers, compression, rate limiting, and more. The pattern allows building the request pipeline in a modular fashion.

Module Pattern

The module pattern is one of the most basic but fundamental patterns in Node.js. It allows you to organize your code into separate files or modules that encapsulate specific functionality.

// counter.js

let count = 0;

const increment = () => {
  count++;
}

const decrement = () => {
  count--;
}

const get = () => {
  return count; 
}

module.exports = {
  increment,
  decrement,
  get  
};

// app.js

const counter = require('./counter');

counter.increment();
counter.increment();

console.log(counter.get()); // 2

counter.decrement();

console.log(counter.get()); //

The key points are:

The module counter.js exports some functions that operate on the private count variable.
The functions encapsulate the logic and data within the module.
app.js imports the module and uses the public API.
This pattern provides data encapsulation and only exposes a public API. The module pattern is very common in Node.js to organize code into reusable and portable modules.

Some other examples are middleware modules, utility libraries, data access layers etc. The pattern helps manage dependencies and hide implementation details.

Decorator Pattern

Decorators dynamically add new functionality to objects without affecting other instances. This is ideal for extending core modules in Node.

class Car {
  constructor() {
    this.price = 10000;
  }

  getPrice() {
    return this.price;
  }
}

class CarOptions {
  constructor(car) {
    this.car = car;
  }

  addGPS() {
    this.car.price += 500;
  }

  addRims() {
    this.car.price += 300; 
  }
}

const basicCar = new Car();

console.log(basicCar.getPrice()); // 10000

const carWithOptions = new CarOptions(basicCar);

carWithOptions.addGPS();
carWithOptions.addRims();

console.log(carWithOptions.car.getPrice()); // 10800

The key points are:

CarOptions wraps the Car class and extends its behavior.
Methods like addGPS() modify the state of the wrapped Car.
The client has a decorated instance of Car with added functionality.
This allows extending behavior dynamically at runtime. The Decorator pattern is useful for abstraction and not having to subclass just to add small features.

Some other examples are authenticated routes, logging wrappers, caching decorators etc. The pattern provides a flexible way to adhere to the Open/Closed principle in Node.js applications.

Dependency Injection pattern

Dependency injection is a pattern where modules or classes receive dependencies from an external source rather than creating them internally. It helps with decoupling, testing, and reusability.

// service.js
class Service {
  constructor(db, logger) {
    this.db = db;
    this.logger = logger;
  }

  async getUser(userId) {
    const user = await this.db.findUserById(userId);
    this.logger.log(`Fetched user ${user.name}`);
    return user;
  }
}

// app.js
const Database = require('./database'); 
const Logger = require('./logger');

const db = new Database();
const logger = new Logger();

const service = new Service(db, logger);

service.getUser(1);

The key points are:

The Service class declares dependencies via the constructor.
The calling code injects the actual dependencies like db and logger.
This decouples Service from concrete dependencies.

Benefits:

Loose coupling between modules
Easier testing by mocking dependencies
Ability to swap implementations
The dependency injection pattern is commonly used with Node.js frameworks like NestJS. It enables better code organization and reusability.

Promise pattern
Promises are a pattern for asynchronous programming in Node.js. They represent the eventual result of an async operation. Here is a simple example:

const fetchData = new Promise((resolve, reject) => {
  // async operation
  const data = getDataFromDatabase();

  if (data) {
    resolve(data); 
  } else {  
    reject('Error fetching data');
  }
});

fetchData
  .then(data => {
    // handle successful data
  })
  .catch(err => {
    // handle error  
  });

The key aspects are:

A Promise takes a callback with resolve and reject functions.
The async operation is started inside the callback.
resolve(data) returns the data on success.
reject(error) returns the error on failure.
Consumers use .then() and .catch() to get the result.

Benefits:

Avoid callback hell in async code
Standardized way to handle async results
Ability to chain and compose promises
Promises are integral to modern Node.js development and enable writing clean asynchronous code. They power libraries like axios, core APIs like fs.promises, and more.

Implementing Design Patterns
Now that we’ve explored some key design patterns that align with Node.js’s strengths, let’s dive into how to implement them effectively:

Understanding Context
Before applying any design pattern, it’s crucial to understand the context of your application. Consider factors such as the application’s requirements, scalability needs, and the specific challenges you’re trying to address. Design patterns are not one-size-fits-all solutions; they should be tailored to fit the unique characteristics of your project.
Modularization
Node.js encourages modularization through its module system. When implementing design patterns, strive to keep modules small, focused, and single-responsibility. This promotes code reusability and maintainability, making it easier to swap out or enhance specific functionalities without affecting the entire application.
Asynchronous Patterns
Given Node.js’s asynchronous nature, it’s essential to choose design patterns that align with asynchronous programming paradigms. Patterns like the Observer pattern and the Middleware pattern naturally fit into the asynchronous environment, allowing developers to handle events and asynchronous operations seamlessly.

Conclusion

Design patterns enable Node.js developers to write organized, flexible and robust code. Leveraging proven patterns like factories, decorators and singletons allows you to build large-scale applications that are easy to maintain and extend over time. Understanding how to apply design principles is key for mastering advanced Node development.