DEV Community: Srishti Prasad

Decoding the Dynamics Between Microservices, Application Servers, Web Servers, and Clients

Srishti Prasad — Sat, 28 Dec 2024 13:10:29 +0000

In modern software architecture, the interaction between microservices, app servers, web servers, and clients forms the backbone of scalable, distributed systems. Let’s dive into how these components interact, troubleshoot common issues like 504 Gateway Timeout, and learn how to configure critical layers like API gateways and web servers effectively.

Key Components and Their Roles

1). Client (Browser/App)

The user's device or application (e.g., web browser, mobile app).

Initiates requests (e.g., "show me my profile").

2). Web Server

Handles HTTP/HTTPS requests and serves static content (e.g., HTML, CSS, images).

Routes dynamic requests to the application server or API gateway.

Examples: Apache, Nginx.

3). Application Server

Orchestrates requests and coordinates communication between microservices.

May handle request aggregation, authentication, and response formatting.

Examples: Node.js, Spring Boot.

4). Microservices

Provide specialized functionalities (e.g., user management, payment processing).

Operate independently and communicate with other microservices via APIs or message queues.

Interaction Workflow

1). Request Initiation: A client sends a request (e.g., GET /user/profile) to the web server.

2). Routing: The web server forwards the request to the application server or API gateway.

3). Business Logic Processing:

The application server coordinates with the appropriate microservice(s).
Microservices handle domain-specific tasks and may communicate with their respective databases.

4). Response Aggregation: The application server aggregates responses from multiple microservices and formats them.

5). Response Delivery: The web server sends the final response back to the client.

Does the Application Server Contain Business Logic?

Application Server's Typical Role in Microservices Architecture

In a pure microservices architecture, the application server often acts as a request router or orchestrator, rather than containing business logic.

Primary Responsibilities:

Routing Requests: Forwarding requests to appropriate microservices.
Orchestration: Coordinating interactions between multiple microservices.
Response Formatting: Aggregating and preparing responses for the client.
Authentication: Validating client credentials before passing requests

504 Gateway Timeout: Where and Why?

A 504 Gateway Timeout occurs at the gateway or proxy layer (e.g., web server, API gateway, load balancer) when:

Common Causes

1). Slow Upstream Service:

The microservice or backend server is too slow to respond.

2). Unreachable Backend:

The gateway cannot connect to the upstream service due to downtime or misconfiguration.

3). Improper Timeout Configurations:

Gateway timeouts are shorter than the time required for upstream processing.

4). Cascading Timeouts:

Delays propagate through interconnected services, causing overall timeouts.

Troubleshooting Steps

Check Backend Health: Ensure all upstream services are operational.
Review Logs: Analyze logs at the gateway and upstream services.
Increase Timeout Settings
Optimize Service Performance: Address bottlenecks in backend systems.

Conclusion

Understanding the interaction between microservices, application servers, web servers, and clients is crucial for building efficient, scalable systems. By effectively using tools like API Gateways and configuring layers to handle timeouts and routing, you can optimize the architecture for performance and resilience. Addressing common issues like 504 Gateway Timeout ensures a smooth user experience and robust backend operations.

A Curious Encounter: Unraveling the Roles of Microservices, API Gateways, and API Servers

Srishti Prasad — Sat, 28 Dec 2024 12:39:50 +0000

It all started during one of my routine code reviews. The task was straightforward: a user dashboard needed to pull data from several services—user information, order history, and notifications. Our system was already built on a microservices architecture, and we had an API Gateway in place. Yet, there it was: the API Server orchestrating the entire process.

I couldn’t help but wonder: Why are we writing this business logic in the API Server? Shouldn’t the microservices handle this directly? And if the API Gateway is already routing the requests, why do we even need an API Server?

That lingering thought stayed with me throughout the day. Later, during a team discussion, I brought it up. I asked,

“If our microservices are already self-contained and handle business logic, why are we duplicating or centralizing some of it in the API Server? Doesn’t that contradict the very idea of microservices? And in this setup, what exactly is the role of the API Gateway?”

Key Concepts:

Microservices:

Each microservice is responsible for a specific business capability (e.g., user service, order service, payment service).
Microservices are independent and encapsulate their own business logic and database.

API Gateway:

A centralized entry point for client requests.
Handles routing, authentication, rate limiting, load balancing, and sometimes response aggregation.
It does not implement business logic but ensures smooth interaction between clients and microservices.

API Server:

A layer that might exist between the API Gateway and microservices.
Typically used in systems transitioning to microservices or where business logic is too complex to be directly handled by microservices.

Why Use an API Server Alongside Microservices?

1). Centralized Logic for Complex Use Cases

Sometimes, you need a layer to combine data or functionality from multiple microservices.
Instead of embedding complex orchestration logic in the client or microservices, the API Server acts as a mediator.
Example:
You have a User Service and an Order Service. To show a user’s dashboard, you need to combine data from both. The API Server orchestrates these calls and merges the responses.

2). Legacy Support or Gradual Migration
In systems transitioning from monolithic to microservices architecture, the API Server may still house some business logic until the migration is complete.
Example:
A monolithic application is being broken into microservices, but the API Server still handles user authentication logic until a dedicated service is created.

3). Abstraction for Clients
The API Server can expose a unified API to clients, abstracting the complexity of multiple microservices.
Example:
Instead of the client calling /users, /orders, and /notifications separately, it calls /dashboard, and the API Server coordinates with the microservices.

What Does the API Gateway Do Then?

The API Gateway focuses on cross-cutting concerns and provides system-wide functionality. Its role complements, rather than overlaps with, the API Server.

API Gateway Responsibilities:

1).Routing:
Directs requests to the correct microservice or API Server.

2).Authentication and Authorization:
Validates tokens or API keys before forwarding requests.

3).Rate Limiting and Throttling:
Ensures no client overloads the system.

4).Caching:
Reduces load on microservices by caching responses.

5).Load Balancing:
Distributes traffic among multiple instances of a service.

6).Request Transformation:
Converts incoming requests or modifies responses (e.g., converting
XML to JSON).

When You Don’t Need an API Server

If your microservices are fully self-contained and lightweight, the API Gateway can directly route client requests to them, eliminating the need for an API Server.

Example:

Client -> API Gateway -> Microservices (User Service, Order Service, etc.).

This approach works well for:

Systems with simple orchestration needs.
Microservices designed with minimal dependencies and clear APIs.

When You Need Both API Server and API Gateway

1). Complex Orchestration:

If multiple microservices must work together to fulfill a request.
Example: Generating a report that requires data from User, Order, and Analytics Services.

2). Centralized Business Logic:

If business logic spans across multiple microservices.
Example: Calculating discounts based on user history, current promotions, and payment method.

3). Client Simplification:

Clients interact with a single API endpoint exposed by the API Server, while the server coordinates with microservices.

CONCLUSION

If your microservices can directly handle requests, you might not need an API Server. However, if there is complex business logic that spans multiple services, an API Server becomes useful. The API Gateway is always essential for routing, security, and system-wide tasks.

[Boost]

Srishti Prasad — Mon, 16 Dec 2024 15:45:50 +0000

🔐 Top 3 Best Authentication Frameworks for 2025 🗝️🧰

Martins Gouveia ・ Dec 13

#webdev #javascript #react #tutorial

Proxy Design Pattern

Srishti Prasad — Sat, 19 Oct 2024 04:10:17 +0000

In my previous blogs, I explored various creational design patterns that deal with object creation mechanisms. Now, it’s time to dive into structural design patterns, which focus on how objects and classes are composed to form larger structures while keeping them flexible and efficient. Let's start with proxy design pattern

Proxy Design Pattern in JavaScript

The Proxy design pattern is a structural design pattern that provides an object representing another object. It acts as an intermediary that controls access to the real object, adding additional behavior such as lazy initialization, logging, access control, or caching, without changing the original object’s code.

In JavaScript, proxies are built-in features provided by the Proxy object, allowing you to define custom behavior for fundamental operations such as property access, assignment, function invocation, etc.

When Do We Need the Proxy Pattern?

The Proxy pattern is particularly useful when:

Lazy Initialization: You want to delay the creation of a resource-heavy object until it is needed.
Access Control: You need to control access to an object, for example, to restrict unauthorized access or to limit operations based on conditions.
Logging: You want to log actions on an object (e.g., property access or method calls).
Caching: You want to cache the result of expensive operations to avoid redundant computations.

Components of Proxy Pattern

Subject: The interface that defines the common operations for both the real object and the proxy.
RealSubject: The actual object that performs the real work.
Proxy: The intermediary that controls access to the RealSubject.

Analogy:

Imagine you have a large painting that you want to show your guests, but it takes a lot of time to pull it out from a storage room (because it's heavy and takes time to carry). Instead of waiting for that every time, you decide to use a small postcard image of the painting to show them quickly while they wait for the actual painting to be fetched.

In this analogy:

The large painting is the real object (like an image that takes time to load).
The postcard is the proxy (a lightweight substitute that stands in until the real object is ready).
Once the real painting is ready, you show the actual one to your guests.

Real-World Analogy:

Think of a real estate agent as a proxy. When you want to buy a house, you don’t immediately visit every house (loading the real object). Instead, the real estate agent (proxy) first shows you photos and descriptions. Only when you’re ready to buy (i.e., when you call display()), the agent arranges a house visit (loads the real object).

Real-World Example: Image Loading (Virtual Proxy)

Let’s use the example of image loading in a web application where we want to delay the loading of the image until the user requests it (lazy loading). A proxy can act as a placeholder until the real image is loaded.

Here’s how you can implement the Proxy design pattern in JavaScript.

Example: Proxy for Image Loading

// Step 1: The real object
class RealImage {
  constructor(filename) {
    this.filename = filename;
    this.loadImageFromDisk();
  }

  loadImageFromDisk() {
    console.log(`Loading ${this.filename} from disk...`);
  }

  display() {
    console.log(`Displaying ${this.filename}`);
  }
}

// Step 2: The proxy object
class ProxyImage {
  constructor(filename) {
    this.realImage = null; // no real image yet
    this.filename = filename;
  }

  display() {
    if (this.realImage === null) {
      // load the real image only when needed
      this.realImage = new RealImage(this.filename);
    }
    this.realImage.display(); // display the real image
  }
}

// Step 3: Using the proxy to display the image
const image = new ProxyImage("photo.jpg");
image.display(); // Loads and displays the image
image.display(); // Just displays the image (already loaded)

Explanation:

1). The Real Image:

The RealImageclass represents the actual image.
It takes a filename as input and simulates the time-consuming process of loading the image from disk (shown by the loadImageFromDiskmethod).
Once loaded, the displaymethod is used to show the image.

2). The Proxy Image:

The ProxyImageclass acts as a stand-in for the RealImage. It doesn’t load the real image immediately.
It holds a reference to the real image (but initially it’s nullbecause the real image hasn’t been loaded yet).
When you call the displaymethod on the proxy, it checks if the real image has been loaded. If not, it loads it first, and then displays it.

3). Usage:

When we create an instance of ProxyImage, the actual image is not loaded yet (because it's resource-intensive).
The first time displayis called, the proxy loads the image (using the RealImageclass) and then displays it.
The second time displayis called, the real image has already been loaded, so it only displays the image without loading it again.

The built-in Proxy object

The ES6 proxy consists of a proxy constructor that accepts a target & handler as arguments

const proxy = new Proxy(target, handler)

Here, target represents the object on which proxy is applied, while handler is a special object that defines the behaviour of the proxy.

The handler object contains a series of optional methods with predefined names called trap methods ( forexample apply,get,set and has) that are automatically called when the corresponding operations are performed on the proxy instance.

Let's understand this by implementing calculator using built-in proxy

// Step 1: Define the Calculator class with prototype methods
class Calculator {
  constructor() {
    this.result = 0;
  }

  // Prototype method to add numbers
  add(a, b) {
    this.result = a + b;
    return this.result;
  }

  // Prototype method to subtract numbers
  subtract(a, b) {
    this.result = a - b;
    return this.result;
  }

  // Prototype method to multiply numbers
  multiply(a, b) {
    this.result = a * b;
    return this.result;
  }

  // Prototype method to divide numbers
  divide(a, b) {
    if (b === 0) throw new Error("Division by zero is not allowed.");
    this.result = a / b;
    return this.result;
  }
}

// Step 2: Create a proxy handler to intercept operations
const handler = {
  // Intercept 'get' operations to ensure access to prototype methods
  get(target, prop, receiver) {
    if (prop in target) {
      console.log(`Accessing property: ${prop}`);
      return Reflect.get(target, prop, receiver); // Access property safely
    } else {
      throw new Error(`Property "${prop}" does not exist.`);
    }
  },

  // Intercept 'set' operations to prevent mutation
  set(target, prop, value) {
    throw new Error(`Cannot modify property "${prop}". The calculator is immutable.`);
  }
};

// Step 3: Create a proxy instance that inherits the Calculator prototype
const calculator = new Calculator(); // Original calculator object
const proxiedCalculator = new Proxy(calculator, handler); // Proxy wrapping the calculator

// Step 4: Use the proxy instance
try {
  console.log(proxiedCalculator.add(5, 3)); // Output: 8
  console.log(proxiedCalculator.multiply(4, 2)); // Output: 8
  console.log(proxiedCalculator.divide(10, 2)); // Output: 5

  // Attempt to access prototype directly through proxy
  console.log(proxiedCalculator.__proto__ === Calculator.prototype); // Output: true

  // Attempt to modify a property (should throw an error)
  proxiedCalculator.result = 100; // Error: Cannot modify property "result".
} catch (error) {
  console.error(error.message); // Output: Cannot modify property "result". The calculator is immutable.
}

The best part using proxy this way as :

The proxy object inherits the prototype of the original Calculator class.

Mutations are avoided through the set trap of the Proxy.

Explanation of the Code

1). Prototype Inheritance:

The proxy does not interfere with the original prototype of the Calculator class.
this is confirmed by checking if proxiedCalculator.proto === Calculator.prototype. The result will be true.

2). Handling getOperations:

The get trap intercepts property access on the proxy object.
We use Reflect.get to safely access properties and methods from the original object.

3). Preventing Mutations:

The set trap throws an error whenever there is an attempt to modify any property on the target object. This ensures immutability.

4). Using Prototype Methods through the Proxy:

The proxy allows access to methods such as add, subtract, multiply, and divide, all of which are defined on the original object's prototype.

Key points to observe here is:

Preserves Prototype Inheritance: The proxy retains access to all prototype methods, making it behave like the original Calculator.
Prevents Mutation: The set trap ensures the internal state of the calculator object cannot be altered unexpectedly.
Safe Access to Properties and Methods: The get trap ensures only valid properties are accessed, improving robustness.

If you've made it this far, don't forget to hit like ❤️ and drop a comment below with any questions or thoughts. Your feedback means the world to me, and I'd love to hear from you!

Prototype Design Pattern

Srishti Prasad — Sat, 12 Oct 2024 12:04:47 +0000

The Prototype Design Pattern in JavaScript is a creational pattern that allows you to create new objects by cloning an existing object (the "prototype") instead of creating them from scratch, which serves as a prototype. This pattern is particularly well-suited to JavaScript, as JavaScript itself is a prototype-based language and is useful when object creation is costly or when you want to create an object that shares certain properties with a base prototype.

ES6 classes make it easier to understand the structure of objects. Using extends simplifies inheritance but before ES6, prototype was used to inherit and implement this. Here is blog to understand this concept.

Ps : In the Prototype Design Pattern in JavaScript, there is no built-in clone() method like there is in some other languages (e.g., Java). However, you can manually implement a clone() method in your prototype or constructor function to provide similar functionality.

The idea behind the Prototype pattern is to:

Create an object that acts as a prototype (blueprint).
Use that object to create new instances, either by copying it or linking new instances to the prototype.

Key Concepts of Prototype Pattern

Prototype: A template object from which new objects are created.
Cloning: New objects are created by copying the prototype.
Prototype Chain: Objects can delegate behaviour to their prototype

Part 1: The Base Shape Class

class Shape {
  constructor(type = 'Generic Shape', color = 'White') {
    this.type = type;
    this.color = color;
  }

  getDetails() {
    return `Type: ${this.type}, Color: ${this.color}`;
  }

  // Clone method to create a new object with the same prototype
  clone() {
    return Object.create(this);  // Creates a new object that inherits from this prototype
  }
}

Explanation:

Purpose: The Shape class acts as a base class or "prototype" from which specific shapes like circles or rectangles can inherit.

clone() Method: This is a key part of the Prototype Pattern. Instead of creating a new instance of a class from scratch, we create a clone of the existing instance (or "prototype"). In this case, Object.create(this) creates a new object that shares the same prototype as the original Shape.

Part 2: The Circle Class

class Circle extends Shape {
  constructor(radius = 0, color = 'White') {
    super('Circle', color); // Calls the parent (Shape) constructor
    this.radius = radius;
  }

  getArea() {
    return Math.PI * this.radius * this.radius;
  }
}

Explanation:
Purpose: The Circle class extends the Shape class and represents a specific type of shape.

Attributes:

radius: The radius of the circle.
In the constructor, the super() function calls the constructor of the Shape class, passing "Circle" as the shape type and the color.

getArea() Method: This calculates the area of the circle using the formula π * radius^2.

Part 3: The Rectangle Class

class Rectangle extends Shape {
  constructor(width = 0, height = 0, color = 'White') {
    super('Rectangle', color);  // Calls the parent (Shape) constructor
    this.width = width;
    this.height = height;
  }

  getArea() {
    return this.width * this.height;
  }
}

Explanation:

Purpose: The Rectangle class extends the Shape class and represents another specific type of shape (a rectangle).

Like the Circle class, the Rectangle class uses super() to call the parent class Shape constructor, specifying that this is a "Rectangle".
getArea() Method: This calculates the area of the rectangle using the formula width * height

Part 4: Cloning and Using the Prototype

const circlePrototype = new Circle();  // Create prototype
const myCircle = circlePrototype.clone();  // Clone the prototype
myCircle.radius = 5;
myCircle.color = 'Red';

const rectanglePrototype = new Rectangle();  // Create prototype
const myRectangle = rectanglePrototype.clone();  // Clone the prototype
myRectangle.width = 10;
myRectangle.height = 5;
myRectangle.color = 'Blue';

Explanation:

Here, instead of creating myCircle and myRectangle objects from scratch using the new keyword, we are cloning prototypes.

Cloning Process:

First, we create prototype instances (circlePrototype and rectanglePrototype).
Then, we clone these prototypes using the clone() method, which creates new objects that inherit from the prototype object.

Modifying Cloned Instances:

After cloning, we modify the properties (e.g., radius, width, height, color) of the cloned objects (myCircle and myRectangle) to match our needs.
This allows us to easily create multiple objects from a base prototype, modifying only the necessary properties.

Part 5: Output

console.log(myCircle.getDetails()); // Output: Type: Circle, Color: Red
console.log(`Circle Area: ${myCircle.getArea()}`);  // Output: Circle Area: 78.54

console.log(myRectangle.getDetails()); // Output: Type: Rectangle, Color: Blue
console.log(`Rectangle Area: ${myRectangle.getArea()}`);  // Output: Rectangle Area: 50

Explanation:

We use the getDetails() method inherited from the Shape class to print the details (type and color) of myCircle and myRectangle.
We also use the getArea() methods (specific to the Circle and Rectangle classes) to calculate and display the area of each shape.

Prototype Design Pattern Perspective:

Prototype Creation: Instead of creating new objects of Circle and Rectangle from scratch, we first create a prototype instance (circlePrototype and rectanglePrototype).
Cloning: Once the prototype exists, the clone() method is used to create new objects based on the prototype. This is the essence of the Prototype Pattern: creating objects by copying an existing object (the prototype).

Use case:

The Prototype pattern is useful when:

You need to create new objects by cloning existing objects.
You want to avoid subclassing and directly reuse existing objects as blueprints.
creation is costly or complex and when many similar objects need to be created. By using prototypes, you can streamline the process and improve efficiency.

If you've made it this far 💕✨, drop a comment below with any questions or thoughts. I'd love to hear from you and engage in some great discussions!✨

Builder Design Pattern

Srishti Prasad — Mon, 07 Oct 2024 15:24:14 +0000

The Builder Pattern is a creational design pattern that provides a way to construct complex objects step by step. It separates the construction of an object from its representation, allowing the same construction process to create different types and representations of objects.

Now the question arises why do we need builder design pattern, what problem do we face ?

While creating object when object contain many attributes there are many problem exists:

We have to pass many arguments to create object
some parameters might be optional
factory class takes all responsibility for creating object. If the object is heavy then all complexity is the part of factory class

So in builder pattern provides several advantages, especially when dealing with the construction of complex objects and is used to create object step by step and finally return object with desired values of attribute.

The Builder Pattern can be explained with a simple analogy: ordering a customized pizza.

Scenario without the Builder Pattern:

Imagine you go to a pizzeria 🍕 and are given only one option to order a pizza: you have to specify everything in one go — the type of crust, the size, the sauce, the toppings, and the extras. If you miss or incorrectly specify something, the pizza 🍕 might not turn out the way you want, and you’d have to redo the entire process from scratch. This is like using a constructor with many parameters — it’s error-prone and difficult to manage, especially when there are many options or optional items.

Example without Builder:

"I want a pizza 🍕 with thin crust, medium size, tomato sauce, mushrooms, cheese 🧀, no olives 🍅, and extra basil 🍀." If you miss something, you’d have to start over!
Scenario with the Builder Pattern:
Now, think of a more flexible approach where the pizza maker asks you step by step for your preferences:

First, they ask what size you want.
Then, they ask about the crust type.
Next, they ask about the toppings.
Finally, they ask if you'd like any extras, like extra cheese or a specific sauce.
At each step, you make decisions based on what you want, and at the end, you get a pizza exactly tailored to your taste. You didn’t have to worry about remembering or specifying everything at once. Each choice built on the previous one.

Example with Builder:

"I want a medium pizza."
"I’d like thin crust."
"Add mushrooms and cheese."
"No olives, please."
"Add extra basil."
The Builder Pattern allows for a step-by-step, structured process, where you build your object (or pizza!) incrementally, leading to more flexibility and fewer mistakes.

Here are few points I have observed how builder pattern gives you an edge over other approaches like telescoping constructors or setters:

1). Simplifies Object Construction with Many Parameters

When an object has many optional or mandatory parameters, using a standard constructor can become confusing and error-prone.
The Builder Pattern provides a clear, step-by-step approach to object creation, making it easier to set only the necessary properties without worrying about parameter order.

Example: Instead of this confusing constructor:

const car = new Car('Tesla', 'Model S', 2024, 'Red', true, false);

You get this readable code:

const car = new CarBuilder('Tesla', 'Model S')
              .setYear(2024)
              .setColor('Red')
              .addGPS()
              .build();

2). Supports Fluent Interface (Method Chaining)

The fluent interface allows methods to return the builder object itself, enabling method chaining. This makes the code more intuitive and readable, as it provides a logical, step-by-step process for setting attributes.

Advantage: Each method call reads like a sequence of instructions for constructing the object, improving readability.

3). Handles Optional Parameters Gracefully

With constructors, it’s difficult to deal with optional parameters without resorting to passing null values or creating many overloaded constructors.
The Builder Pattern allows you to include only the parameters you need, without worrying about providing defaults or placeholders for every parameter.

Without Builder (using constructor):

const car = new Car('Tesla', 'Model S', 2024, null, true, false); // Confusing

With Builder:

const car = new CarBuilder('Tesla', 'Model S')
              .setYear(2024)
              .addGPS()
              .build();  // Clean and understandable

4). Promotes Immutability

Once the object is built, it’s often immutable—you can’t change its state after creation. This ensures that the constructed object is in a valid and stable state, making your code safer and less prone to bugs.

Advantage: The object is fully constructed and valid after the build() method is called, reducing chances for errors due to partially constructed objects.

5). Easier to Extend

The Builder Pattern is easily extendable. When new attributes or features are added, the builder can be modified without affecting existing code. Without Builder: If you add a new parameter to the constructor, you must change every instantiation of the object across the codebase.

With Builder: You simply add a new setter method to the builder, without affecting the places where the object is built.

Example: Adding an engine type:

const car = new CarBuilder('Tesla', 'Model S')
              .setYear(2024)
              .setColor('Red')
              .setEngineType('Electric')
              .build();

6). Improved Readability and Maintainability

The Builder Pattern offers high readability by breaking down the construction process into small, easy-to-understand steps.
This makes the code more self-documenting—you can clearly see how an object is being constructed, without having to look up what each argument in a constructor represents. Advantage: It’s easier to maintain and modify the code since each method clearly defines what part of the object it’s modifying.

7). Prevents Object Inconsistency

The Builder ensures that all required parameters are set before the object is built, preventing the creation of inconsistent or incomplete objects.
This validation process happens at the time of building, ensuring the object is in a valid state when it's created.

Without Builder: You might create objects that are incomplete or improperly initialized.

With Builder: The builder pattern guarantees a consistent and fully constructed object.

8). Reduces the Need for Overloaded Constructors

Without the Builder Pattern, you might end up with multiple overloaded constructors to accommodate different combinations of parameters. Advantage: With the builder, you don’t need multiple versions of constructors—just one clear, flexible building process.

Let’s compare object creation with and without the Builder Pattern using a real-world example where we are creating a Car object that has multiple properties, some of which are optional.

Without the Builder Pattern

1). Using Constructor with Many Parameters

class Car {
  constructor(make, model, year, color, hasGPS, hasSunroof) {
    this.make = make;
    this.model = model;
    this.year = year;
    this.color = color;
    this.hasGPS = hasGPS || false;     // Optional parameter
    this.hasSunroof = hasSunroof || false; // Optional parameter
  }

  describe() {
    return `${this.year} ${this.make} ${this.model} in ${this.color} color with GPS: ${this.hasGPS} and Sunroof: ${this.hasSunroof}`;
  }
}

// Creating the object
const car = new Car('Tesla', 'Model S', 2024, 'Red', true, false);
console.log(car.describe());

With the Builder Pattern

2). Using the Builder Pattern

// Car class remains simple, no complex constructor
class Car {
  constructor(builder) {
    this.make = builder.make;
    this.model = builder.model;
    this.year = builder.year;
    this.color = builder.color;
    this.hasGPS = builder.hasGPS;
    this.hasSunroof = builder.hasSunroof;
  }

  describe() {
    return `${this.year} ${this.make} ${this.model} in ${this.color} color with GPS: ${this.hasGPS} and Sunroof: ${this.hasSunroof}`;
  }
}

// CarBuilder class for step-by-step object creation

class CarBuilder {
  constructor(make, model) {
    this.make = make;
    this.model = model;
  }

  setYear(year) {
    this.year = year;
    return this;
  }

  setColor(color) {
    this.color = color;
    return this;
  }

  addGPS() {
    this.hasGPS = true;
    return this;
  }

  addSunroof() {
    this.hasSunroof = true;
    return this;
  }

  build() {
    return new Car(this); // Builds and returns the Car object
  }
}

// Creating the object using the builder

const car = new CarBuilder('Tesla', 'Model S')
  .setYear(2024)
  .setColor('Red')
  .addGPS()
  .build();

console.log(car.describe());

I would love to hear how you've applied these ideas to your work? Share your thoughts or questions in the comments below—I’d love to hear from you.

Thank you for joining me on this learning journey!

Abstract Factory Design Pattern

Srishti Prasad — Sat, 05 Oct 2024 07:35:52 +0000

Abstract factory method design pattern :- basically it is a pattern inside a pattern it is a creational design pattern which is required to create objects which belong to a family of similar objects the way we had factory design pattern where we created objects which are of similar type here we are using a factory of factory to create objects which belong to a family of similar objects.

Difference between factory and abstract factory design pattern

The Abstract Factory Pattern is similar to the Factory Method Pattern, but with one extra layer. In the Abstract Factory, there's a central interface (or "factory") that defines methods to create a group of related objects (like buttons or checkboxes).

Each Concrete Factory class decides which specific factory (for example, one for Windows or Mac) will be used to create the actual objects. The logic for creating the final objects (like a Mac button or a Windows checkbox) is then implemented in these Concrete Product classes.

In short:

The Abstract Factory defines methods to create families of objects.
Concrete Factories decide which specific factory to use based on some logic.
The Concrete Products (actual objects) are created based on the logic in these factories.

This pattern helps create related objects without tightly coupling the code to specific implementations.

Class Diagram of abstract factory design pattern

        +----------------------+
        |   AbstractFactory     | <------------------------------+
        |---------------------- |                                  |
        | + createProductA()    |                                  |
        | + createProductB()    |                                  |
        +----------------------+                                   |
                  ^                                                |
                  |                                                |
   +-------------------------+             +-------------------------+
   |     ConcreteFactory1     |             |     ConcreteFactory2     |
   |------------------------- |             |-------------------------|
   | + createProductA()       |             | + createProductA()       |
   | + createProductB()       |             | + createProductB()       |
   +-------------------------+             +-------------------------+
            |                                       |
            |                                       |
    +---------------+                      +---------------+
    |   ProductA1   |                      |   ProductA2   |
    +---------------+                      +---------------+
    +---------------+                      +---------------+
    |   ProductB1   |                      |   ProductB2   |
    +---------------+                      +---------------+

Analogy to understand abstract factory design pattern: Smartphone Manufacturer

Imagine a smartphone company that offers two product lines: Android and iPhone. Both lines include a Phone and a Charger, but the specific models for each line differ.

A smartphone company makes two product lines: Android and iPhone, each having a Phone and a Charger.

Abstract Factory: Think of it as the blueprint that defines which products (Phone and Charger) need to be created.
Concrete Factories: These are like the Android and iPhone departments, responsible for creating specific products based on the line chosen (Android or iPhone).
Concrete Products: The actual items (Android Phone, Android Charger, iPhone, iPhone Charger) made by the departments.
Client: You, as the customer, choose between Android or iPhone, and the right products are created for you without needing to know how they are built. This pattern ensures compatible products (Phone and Charger) are created together without exposing the internal creation logic.

Following is UML diagram for above analogy

                 +--------------------+
                 |   AbstractFactory   |  <--- Abstract Interface for creating products
                 +--------------------+
                 | + createPhone()     |
                 | + createCharger()   |
                 +--------------------+
                          /\
                          ||
        +-------------------------------------------+
        |                                           |
+----------------------+                  +----------------------+
|  AndroidFactory      |                  |  iPhoneFactory       |  <-- Concrete Factories
+----------------------+                  +----------------------+
| + createPhone()      |                  | + createPhone()      |
| + createCharger()    |                  | + createCharger()    |
+----------------------+                  +----------------------+
        /\                                      /\
        ||                                      ||
+-------------------+                +-------------------+
| AndroidPhone      |                | iPhone            |  <-- Concrete Products
+-------------------+                +-------------------+
| + makeCall()      |                | + makeCall()      |
+-------------------+                +-------------------+
+-------------------+                +-------------------+
| AndroidCharger    |                | iPhoneCharger     |  <-- Concrete Products
+-------------------+                +-------------------+
| + charge()        |                | + charge()        |
+-------------------+                +-------------------+

Client
+----------------------------------+                <-- Client Code
| Calls either AndroidFactory or   |
| iPhoneFactory to get products    |
+----------------------------------+

Here is code for above analogy to understand in a better way

// Abstract Factory
class AbstractFactory {
  createPhone() {
    throw new Error('This method should be overridden');
  }

  createCharger() {
    throw new Error('This method should be overridden');
  }
}

// Concrete Factory for Android
class AndroidFactory extends AbstractFactory {
  createPhone() {
    return new AndroidPhone();
  }

  createCharger() {
    return new AndroidCharger();
  }
}

// Concrete Factory for iPhone
class iPhoneFactory extends AbstractFactory {
  createPhone() {
    return new iPhone();
  }

  createCharger() {
    return new iPhoneCharger();
  }
}

// Product classes for Android
class AndroidPhone {
  makeCall() {
    return 'Making a call from Android Phone';
  }
}

class AndroidCharger {
  charge() {
    return 'Charging Android Phone';
  }
}

// Product classes for iPhone
class iPhone {
  makeCall() {
    return 'Making a call from iPhone';
  }
}

class iPhoneCharger {
  charge() {
    return 'Charging iPhone';
  }
}

// Client code
function getFactory(osType) {
  switch (osType) {
    case 'Android':
      return new AndroidFactory();
    case 'iPhone':
      return new iPhoneFactory();
    default:
      throw new Error('Unknown OS type');
  }
}

// Example usage
const androidFactory = getFactory('Android');
const androidPhone = androidFactory.createPhone();
const androidCharger = androidFactory.createCharger();

console.log(androidPhone.makeCall());  // Output: Making a call from Android Phone
console.log(androidCharger.charge());  // Output: Charging Android Phone

const iphoneFactory = getFactory('iPhone');
const iphone = iphoneFactory.createPhone();
const iphoneCharger = iphoneFactory.createCharger();

console.log(iphone.makeCall());        // Output: Making a call from iPhone
console.log(iphoneCharger.charge());   // Output: Charging iPhone

The Abstract Factory Pattern is a powerful design approach that promotes the creation of families of related objects without specifying their exact classes. By decoupling the client code from the actual product creation, it ensures flexibility, scalability, and cleaner code management when introducing new product families. Whether it's for managing cross-platform interfaces or creating different product lines, this pattern offers a structured and maintainable solution for handling object creation complexities. Implementing the Abstract Factory helps you future-proof your code and maintain clear separation of concerns as your system evolves.

I would love to hear how you've applied these ideas to your work? Share your thoughts or questions in the comments below—I’d love to hear from you.

Thank you for joining me on this learning journey!

Factory Design Pattern in JavaScript

Srishti Prasad — Thu, 03 Oct 2024 11:33:08 +0000

The Factory Design Pattern is a creational design pattern that provides a way to create objects without specifying the exact class of the object that will be created. It involves creating a factory method that decides which class to instantiate based on the input or configuration. It is used when all the object creation and its business logic we need to keep at one place.

The main advantage factory design pattern is its ability to decouple the creation of an object from one particular implementation.
It allows to create object whose class is determined at runtime.
Factory allows us to expose a "surface area" that is much smaller than that of a class, class can be extended, manipulated, while factory being just a function offers fewer options to the user, making it more robust.
Hence factory can also be used to enforce encapsulation by leveraging closures.

A method to impose encapsulation

In Javascript, one of the main ways to enforce encapsulation is through functions scopes and closures.

A factory can also be used as an encapsulation mechanism.

Encapsulation refers to controlling the access to some internal details of the component by preventing external code from manipulating them directly. The interaction with the component happen only through its public interface, isolating external code from the changes in the implementation details of the component.

Closures allow you to create private variables and methods that are not accessible from outside the factory, thereby enforcing encapsulation and hiding the internal details of object creation and implementation.

Decoupling object creation and implementation

Invoking a factory, instead of directly creating new object from a class using the new operator or Object.create(), is so much more convenient and flexible in several respects.

Factory allows us to separate the creation of an object from the implementation. A factory wraps the creation of a new instance, giving us more flexibility and control in a way we do it. Inside the factory we choose to create a new instance of a class using the new operator, or leverage closures to dynamically build a stateful object literal, or even return a different object type based on a particular condition. The consumer of factory is totally unaware of how the creation of instance is carried out.

Let's take small example to understand why we need factory design pattern

function createImg(name) {
    return new Image(name);
}

const image = createImg('photo.jpg');

You could have said why to write this extra line of code , when we can directly write:

const image = new Image(name);

So the idea behind using a factory function (createImg) is to abstract away the process of creating an object.

Benefits of Factory Function in Refactoring:

Single Point of Change: By using a factory function, you centralize the object creation process. Refactoring or extending logic requires changes in one place rather than throughout the codebase.

Simplifies Client Code: Client code that consumes the factory function remains unchanged, even as the complexity of the object creation process increases.

Encapsulation: The factory function encapsulates any additional logic (e.g., caching, default parameters, or new object types). This prevents duplication of logic in multiple places and reduces the risk of errors during refactoring.

Maintainability: As your code grows, maintaining a factory function becomes much easier than refactoring direct instantiation. With a factory function, you can introduce new features, make optimizations, or fix bugs without affecting the rest of the code.

Example

Here’s a basic example of implementing the Factory Design Pattern in JavaScript:
Scenario: A factory for creating different types of vehicles (Car, Bike, Truck), depending on the input.

// Vehicle constructor functions
class Car {
  constructor(brand, model) {
    this.vehicleType = 'Car';
    this.brand = brand;
    this.model = model;
  }

  drive() {
    return `Driving a ${this.brand} ${this.model} car.`;
  }
}

class Bike {
  constructor(brand, model) {
    this.vehicleType = 'Bike';
    this.brand = brand;
    this.model = model;
  }

  ride() {
    return `Riding a ${this.brand} ${this.model} bike.`;
  }
}

class Truck {
  constructor(brand, model) {
    this.vehicleType = 'Truck';
    this.brand = brand;
    this.model = model;
  }

  haul() {
    return `Hauling with a ${this.brand} ${this.model} truck.`;
  }
}

// Vehicle factory that creates vehicles based on type
class VehicleFactory {
  static createVehicle(type, brand, model) {
    switch (type) {
      case 'car':
        return new Car(brand, model);
      case 'bike':
        return new Bike(brand, model);
      case 'truck':
        return new Truck(brand, model);
      default:
        throw new Error('Vehicle type not supported.');
    }
  }
}

// Using the factory to create vehicles
const myCar = VehicleFactory.createVehicle('car', 'Tesla', 'Model 3');
console.log(myCar.drive()); // Output: Driving a Tesla Model 3 car.

const myBike = VehicleFactory.createVehicle('bike', 'Yamaha', 'MT-15');
console.log(myBike.ride()); // Output: Riding a Yamaha MT-15 bike.

const myTruck = VehicleFactory.createVehicle('truck', 'Ford', 'F-150');
console.log(myTruck.haul()); // Output: Hauling with a Ford F-150 truck.

How It Works:

Vehicle Classes: We define different types of vehicles (Car, Bike, Truck), each with its own constructor and specific methods like drive(), ride(), and haul().
Factory Method: The VehicleFactory.createVehicle() method is the factory that handles the logic of creating objects. It decides which type of vehicle to instantiate based on the type argument passed to it.
Reusability: The factory centralizes the logic for creating vehicles, making it easy to manage, extend, or modify the creation process.

Ps: In the Factory Design Pattern examples above, classes like Car, Bike, and Truck are instantiated using the new keyword inside the factory method (VehicleFactory.createVehicle)
The Factory Pattern abstracts object creation, meaning the client doesn't have to use the new keyword themselves. They rely on the factory method to return the correct instance.

When to Use the Factory Pattern:

When the exact types of objects need to be determined at runtime.
When you want to centralize the object creation logic.
When the creation process involves complex logic or multiple steps.

Summary

The Factory Design Pattern is a useful way to handle complex or varied object creation in JavaScript.
It abstracts the instantiation logic, allowing for flexibility and easier management of different object types.
This pattern is widely used in real-world applications, especially when working with complex systems where object creation may depend on runtime conditions or configurations.
In a real-world project, as your code evolves and becomes more complex, the factory function approach minimizes the number of changes you need to make, making your code more maintainable and easier to refactor.

Reference Book : NodeJs Design pattern by Mario Casciaro

As we've explored, design patterns play a crucial role in solving common software design challenges efficiently. Whether you're just beginning like I am, or looking to deepen your understanding, the insights shared here can help you build more adaptable and scalable systems.

The journey to mastering design patterns may feel overwhelming at first, but by starting small, experimenting, and applying these concepts in real-world projects, you'll strengthen your skills as a developer. Now it's your turn! How will you apply these ideas to your work? Share your thoughts or questions in the comments below—I’d love to hear from you.

Thank you for joining me on this learning journey!
✨✨✨✨✨✨

Understanding Creational Design Patterns: Building Blocks of Object Creation

Srishti Prasad — Wed, 02 Oct 2024 16:00:52 +0000

When designing software, one of the key challenges is how objects are created. If we don't structure object creation carefully, the code can become complex, difficult to maintain, and hard to scale. This is where Creational Design Patterns come into play.

Creational design patterns deal with the efficient management and creation of objects in a way that enhances flexibility and reuse. These patterns abstract the process of object instantiation, making it easier to deal with complex creation logic.

In this blog, we’ll explore the different creational design patterns, how they help, and when to use them.

Why Do We Need Creational Design Patterns?

At first glance, creating objects may seem simple: you just instantiate a class. However, as systems grow, so do the complexities of object creation. Here are a few scenarios where object creation becomes problematic:

Complex construction logic: When creating an object involves many steps or configurations.
Multiple object types: When different variations of objects need to be created dynamically.
Resource management: When objects need to be controlled (e.g., limiting instances or reusing objects to avoid resource exhaustion).
Creational design patterns solve these problems by abstracting the instantiation process and offering more flexible ways to create objects.

Here are the five main creational design patterns, each addressing different aspect s of object creation:

1). Factory Method Pattern
Purpose: Provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created.

The Factory Method Pattern delegates the responsibility of object creation to subclasses, promoting loose coupling. Instead of directly instantiating objects, you ask a factory class to create them for you.

When to Use:

When the exact type of object to create isn't known until runtime.
When you want to abstract away the instantiation logic from the client.

2). Abstract Factory Pattern
Purpose: Provides an interface for creating families of related or dependent objects without specifying their concrete classes.

The Abstract Factory Pattern helps to create a suite of related objects (e.g., for different platforms or themes) without the client needing to know the specific classes. It returns factories that produce specific object families.

When to Use:

When you need to create families of related objects (e.g., GUI elements like buttons, windows for different operating systems).
When you want to ensure that related products are used together.

3). Builder Pattern
Purpose: Separates the construction of a complex object from its representation, allowing the same construction process to create different representations.

The Builder Pattern is useful for creating objects that require multiple steps to instantiate. Instead of using a large constructor with many arguments, the builder pattern lets you construct objects step by step.

When to Use:

When creating complex objects with many configurations.
When you want the same construction process to build different representations of an object.

4). Prototype Pattern
Purpose: Creates new objects by copying an existing object, known as the prototype.

The Prototype Pattern is used when the cost of creating a new instance of a class is expensive. Instead of creating an object from scratch, you make a copy (clone) of an existing object. This pattern is useful for object creation in resource-constrained systems.

When to Use:

When creating an object is costly (e.g., performance-heavy initialization).
When you want to avoid subclassing for object creation.

5). Singleton Pattern
Purpose: Ensures a class has only one instance and provides a global point of access to it.

The Singleton Pattern is useful when you need exactly one object to coordinate actions across the system. For instance, a logging system, configuration manager, or connection pool is often implemented using Singleton.

When to Use:

You need to limit the number of instances of a class.
You want to control access to a single shared resource.

When to Use Creational Design Patterns

Creational patterns help manage complexity and enhance flexibility by controlling how objects are created. They are most useful in the following cases:

Dynamic object creation: When the type or nature of objects must be determined at runtime.
Simplified object creation: When object creation involves multiple steps or complex configurations.
Managing dependencies: When object creation needs to account for interdependencies and you want to avoid tight coupling.

Conclusion

Creational design patterns provide powerful solutions for object creation, ensuring flexibility, scalability, and maintainability in your software architecture. By abstracting and managing the instantiation process, these patterns simplify how complex systems are built and extended.

In the next blog, we will dive deeper into each of these patterns, starting with the Factory Design Pattern, exploring its implementation, advantages, and real-world use cases. Stay tuned for more practical insights into building robust and scalable systems!

If you've made it this far, don't forget to hit like ❤️ and drop a comment below with any questions or thoughts. I'd love to hear from you and engage in some great discussions!

Low level design and SOLID Principles

Srishti Prasad — Tue, 01 Oct 2024 14:52:46 +0000

Low-Level Design (LLD) is a critical phase in software development that bridges the gap between high-level design and actual implementation. While high-level design focuses on architectural blueprints, LLD deals with how each component, class, or function is implemented to fulfill the overall system's requirements.

In simpler terms, LLD involves designing classes, methods, interfaces, and interactions between them, ensuring that the code is efficient, maintainable, and scalable. It’s an essential skill for software engineers, especially when building systems that need to be robust, reusable, and easy to modify over time.

This blog will introduce you to the key concepts, principles, and techniques involved in low-level design and show how they can help you write better, more maintainable code.

The first question that comes in our mind is:

Why is Low-Level Design Important?

Maintainability: A well-thought-out design makes it easier to maintain, extend, and debug code. Poor design leads to technical debt, making future changes costly.
Scalability: Good LLD ensures that your code is scalable, both in terms of performance and in supporting new features as the system evolves.
Reusability: Well-designed components can be reused across different parts of a system or in entirely different projects.
Clarity: With a well-defined design, engineers can understand how various parts of the system fit together, making collaboration easier.

To bridge the gap between LLD concepts and real code, let's break down the process of designing a low-level diagram through the following steps:

Step 1:Object Oriented Principles
Step 2:SOLID Principles
Step 3:Design Patterns

Object oriented principles

Object-oriented programming concept 4 pillars are must-have to go start learning low-level designing. I have already covered this concept in brief checkout blog

SOLID Principles

S: Single Responsibility Principle (SRP)

Each unit of code should have only one responsibility to change.
A unit can be a class, module, function, or component.
Keeps code modular and reduces tight coupling.

Example: Imagine a class that handles both user authentication and logging. If we need to change how logging works, we would end up modifying the authentication class as well. This violates SRP. Instead, we should have two separate classes: one for user authentication and another for logging, so each class has a single responsibility.

O: Open/Closed Principle (OCP)

Units of code should be open for extension but closed for modification.
Extend functionality by adding new code, not modifying existing code.
Useful in component-based systems like a React frontend.

Example: Consider a payment processing system that handles payments via credit cards. If you need to add support for PayPal, rather than modifying the existing code, you should extend it by adding a new class for PayPal payments. This ensures the existing system remains stable while allowing new functionality to be added.

L: Liskov Substitution Principle (LSP)

Subclasses should be substitutable for their base classes.
Functionality in the base class should be usable by all subclasses.
If a subclass can’t use the base class functionality, it shouldn’t be in the base class.

Example: If we have a Bird class that has a method fly(), and we create a subclass Penguin, which cannot fly, this violates LSP. The Penguin class should not inherit fly() since it changes the expected behavior. Instead, the Bird class should be refactored to handle birds that can and cannot fly differently.

I: Interface Segregation Principle (ISP)

Provide multiple specific interfaces rather than a few general-purpose ones.
Clients shouldn’t depend on methods they don’t use.

Example: Suppose we have an interface Animal with methods fly(), swim(), and walk(). A class Dog that implements Animal would be forced to define fly(), which it doesn't need. To comply with ISP, we should split the Animal interface into smaller interfaces like Flyable, Swimmable, and Walkable to avoid forcing irrelevant methods on classes

D: Dependency Inversion Principle (DIP)

Depend on abstractions(eg use interface), not concrete classes.
Use abstractions to decouple dependencies between parts of the system.
Avoid direct calls between code units use interfaces or abstractions.

Example: Notification System
You have a service that sends notifications.

OrderService → EmailSender

What’s wrong?

OrderService directly depends on EmailSender
If tomorrow you want SMS or WhatsApp, you must change OrderService
High-level business logic is tied to low-level implementation Real world problem : “Every time notification type changes, core business code changes.”

INSTEAD :
Step 1: Create an abstraction

Notification interface
send(message)

Step 2: Implement it

EmailNotification
SMSNotification
WhatsAppNotification

Step 3: High-level module depends on interface

OrderService → Notification (interface)

“Instead of OrderService depending on Email or SMS directly, it depends on a Notification interface. This way, I can change or add notification methods without touching business logic.”

Design Patterns

Design patterns are proven solutions to common problems that arise in software design. They are best practices that developers can follow to solve specific design issues efficiently and systematically. Instead of reinventing the wheel, design patterns provide a standard approach to solving recurring problems.

Design patterns can be categorized into three types:

Creational Patterns: Deal with object creation
- Factory design pattern
- Abstract factory design pattern
- Builder design pattern
- Prototype Design pattern
- Singleton design pattern
Structural Patterns: Deal with object composition and relationships
- Adapter Pattern
- Bridge Pattern
- Composite Pattern
- Decorator Pattern
- Facade Pattern
- Flyweight Pattern
- Proxy Pattern
Behavioral Patterns: Deal with object interaction and responsibility
- Chain of Responsibility Pattern
- Command Pattern
- Interpreter Pattern
- Mediator Patter
- Memento Pattern
- Observer Pattern
- State Pattern
- Strategy Pattern
- Template Method Pattern
- Visitor Pattern

When writing code, you typically face three major types of problems:

Object Creation:

The first challenge is figuring out how to create objects.
This is where creational design patterns come into play. Patterns like:
Factory, Abstract Factory, Singleton, Builder .These patterns deal with the creation of objects.

Object Relationships:

Once you’ve created the objects, the next question is: How will they be related to each other?
You need to decide how to structure these objects into a larger system or module. This is where structural design patterns are useful. Patterns like: Facade, Composite, Adapter
These help define the relationships and structure between objects.

Object Communication:

Finally, you need to determine how the objects will communicate with each other and what responsibilities each object will have.
Do you want different time behaviors, or chaining of objects?
Behavioral design patterns solve this. Patterns like: Strategy, Command, Observer
These patterns manage object communication and behavior delegation.

Now that we've laid the foundation by exploring the SOLID principles and introduced the vast landscape of design patterns, we're ready to dive deeper! In the upcoming series, I'll break down each design pattern with practical examples and real-world scenarios. Whether you're just starting your design journey or looking to sharpen your skills, these patterns will help you write cleaner, more scalable code. Stay tuned for the next blog, where we unravel the first design pattern—step by step!

If you've made it this far, don't forget to hit like ❤️ and drop a comment below with any questions or thoughts. Your feedback means the world to me, and I'd love to hear from you!

Understanding Prototypes in JavaScript: The Backbone of Inheritance

Srishti Prasad — Sun, 22 Sep 2024 15:53:37 +0000

JavaScript is a powerful language that uses prototypal inheritance, which can be a bit confusing for those coming from class-based languages. In this post, we'll explore how prototypes work in JavaScript, their role in inheritance, and how you can utilize them effectively.

What Are Prototypes?

In JavaScript, every object has a property called prototype. This property allows objects to inherit properties and methods from other objects, enabling a form of inheritance that is key to JavaScript’s flexibility.

The Prototype Chain

When you try to access a property on an object and it doesn’t exist on that object itself, JavaScript looks up the prototype chain to find it. This chain continues until it reaches the end, which is null.

Creating Objects Without Classes

JavaScript allows you to create objects using constructor functions. Here’s how it works:

// Constructor function
function Person(name, age) {
  this.name = name;
  this.age = age;
}

// Adding methods via prototype
Person.prototype.greet = function() {
  console.log(`Hello, my name is ${this.name}`);
};

// Creating an instance
const person1 = new Person('Srishti', 25);
person1.greet(); // Output: Hello, my name is Srishti

In this example, the greet method is part of the Person prototype, allowing all instances of Person to access it without being defined in each instance.

ES6 Classes: A Modern Approach

With the introduction of ES6, JavaScript now supports classes, making it easier to create objects and manage inheritance. Here’s a similar example using the class syntax:

// Class declaration
class Person {
  constructor(name, age) {
    this.name = name;
    this.age = age;
  }

  greet() {
    console.log(`Hello, my name is ${this.name}`);
  }
}

// Creating an instance
const person1 = new Person('Srishti', 25);
person1.greet(); // Output: Hello, my name is Srishti

Key Differences Between Constructor Functions and Classes

Syntax: Classes offer a cleaner and more intuitive way to define objects compared to constructor functions.

Structure: While constructor functions require manual attachment of methods via the prototype, classes inherently support methods as part of their definition.

Conclusion

Understanding prototypes is crucial for mastering JavaScript, especially as you work with inheritance and object-oriented patterns. Whether you choose to use traditional constructor functions or the modern class syntax, grasping the concept of prototypes will greatly enhance your coding capabilities.

That's it for today, thanks if you are reading till here ! Hope you enjoyed reading it. Don't forget to hit ❤️.

Feel free to engage in the comment section if you have any questions or wish to contribute further insights to this blog. Your feedback and discussions are valued contributions that enhance our shared knowledge.

Develop and Test AWS S3 Applications Locally with Node.js and LocalStack

Srishti Prasad — Sat, 13 Jul 2024 16:25:19 +0000

AWS S3 (Simple Storage Service)

A scalable, high-speed, web-based cloud storage service designed for online backup and archiving of data and applications.
Provides object storage, which means it stores data as objects within resources called buckets.

Managing files and images is crucial in modern web development, often utilizing cloud storage solutions such as Amazon S3.
Directly developing and testing S3 interactions on AWS can be cumbersome and expensive.

This blog targets: Node.js developers,Cloud developers,DevOps engineers.
The focus is on simulating AWS S3 locally using LocalStack for:

Efficient development and testing workflows
Cost-effective solutions

By the end of this blog, you will learn:

How to utilize Node.js and AWS SDK v3
Methods for uploading and fetching images
Strategies to ensure a seamless local development workflow

📚What is localstack?

Localstack is a technology with the help of which, we may mimic a development environment using AWS services by accessing local versions of various cloud services. This enables you to improve and debug your code prior to putting it into a live environment. Because of this, Localstack is a useful tool for simulating important AWS services like message queues and object storage, among others.

Furthermore, Localstack is a useful resource for learning how to set up and launch services using a Docker container without having to use your credit card or open an AWS account.
We build a Localstack container in this tutorial to implement the primary S3 service functions.

🌐Node Js & 📁LocalStack

As mentioned earlier, LocalStack provides a means to emulate a local environment for Amazon with some of the most popular services. This article will guide you through the process of creating a container using the LocalStack image. Subsequently, it will demonstrate the utilization of Node.js and AWS SDK v3 to create an S3 bucket and implement key functionalities within these services.

Prerequisites
Before you begin please ensure that you have the 🐳 Docker & Docker desktop should be installed.

🚀 A Step-by-Step Guide:
1) Pull docker image of localstack from Docker hub:

docker pull localstack/localstack

2) Run the container with following command:

docker run -d --rm -it -p 4566:4566 -p 4510-4559:4510-4559 localstack/localstack

3) To list the running containers in your Docker environment run

docker ps

Now you have to copy containerID of localstack over there and run next command

4) Get inside the container with the following execution:

 docker exec -it '<container-id>/<name>' bash

example:

5) To set the default creds, AWS APIs need some kind of dummy configuration

 aws configure --profile default

enter same accessID and secret key as you are going to add in script here I have used 'test'

6) To test if you are able to build the S3 buckets

 awslocal s3api create-bucket --bucket sample-bucket

here name of bucket is sample-bucket (I have named it as 'banner')so I'll add the same in the script.

7) To list AWS S3 buckets

 awslocal s3api list-buckets

You have S3 bucket created. Now you can perform operations on bucket created.

Node js script to generate signedUrl for every image in s3 bucket

import {
  S3Client,
  CreateBucketCommand,
  GetObjectCommand,
  HeadBucketCommand,
  waitUntilBucketExists,
  ListObjectsV2Command,
  PutObjectCommand
} from '@aws-sdk/client-s3';
import { fromEnv } from '@aws-sdk/credential-providers';
import { getSignedUrl } from '@aws-sdk/s3-request-presigner';
import fs from 'fs';
import path from 'path';

// Set AWS credentials and configuration
process.env.AWS_ACCESS_KEY_ID = 'test';
process.env.AWS_SECRET_ACCESS_KEY = 'test';

const s3Client = new S3Client({
  region: 'us-east-1',
  endpoint: 'http://localhost:4566',
  forcePathStyle: true,
  credentials: fromEnv()
});

const bucket = 'banner';

// Here you have to add absolute path of image or file 
const directoryPath = '/Users/download/S3-localstack/images';

async function generateSignedUrl(key) {
  try {
    const getObjectUrl = await getSignedUrl(s3Client, new GetObjectCommand({ Bucket: bucket, Key: key }), { expiresIn: 3600, responseContentDisposition: 'inline' });
    return getObjectUrl;
  } catch (error) {
    console.error(`Error generating signed URL for ${key}:`, error);
    return null;
  }
}

async function uploadFiles() {
  const files = fs.readdirSync(directoryPath);
  const uploadPromises = files.map(file => {
    const filePath = path.join(directoryPath, file);
    const fileStream = fs.createReadStream(filePath);
    fileStream.on('error', function (err) {
      console.error('File Error', err);
    });

    const uploadParams = {
      Bucket: bucket,
      Key: file,
      Body: fileStream
    };

    const putObjectCommand = new PutObjectCommand(uploadParams);
    return s3Client.send(putObjectCommand).then(() => {
      console.log(`File ${file} successfully uploaded to bucket ${bucket}`);
    });
  });

  await Promise.all(uploadPromises);
}

async function main() {
  try {
    // Check if the bucket exists
    try {
      const headBucketCommand = new HeadBucketCommand({ Bucket: bucket });
      await s3Client.send(headBucketCommand);
      console.log(`Bucket ${bucket} already exists`);
    } catch (err) {
      if (err.name === 'NotFound') {
        const createBucketCommand = new CreateBucketCommand({ Bucket: bucket });
        await s3Client.send(createBucketCommand);
        console.log(`Bucket ${bucket} successfully created`);
      } else {
        throw err;
      }
    }

    // Wait until the bucket exists
    await waitUntilBucketExists({ client: s3Client, maxWaitTime: 20 }, { Bucket: bucket });
    console.log(`Bucket ${bucket} is ready`);

    // Upload files to the bucket
    await uploadFiles();

    // List objects in the bucket
    const listObjectsCommand = new ListObjectsV2Command({ Bucket: bucket });
    const data = await s3Client.send(listObjectsCommand);

    if (!data.Contents || data.Contents.length === 0) {
      console.log('No objects found in the bucket');
      return;
    }

    const imageKeys = data.Contents.map((object) => object.Key);
    console.log('Found keys:', imageKeys);

    // Generate signed URLs for each image
    const signedUrls = await Promise.all(imageKeys.map((key) => generateSignedUrl(key)));
    console.log('Signed URLs for the uploaded images:', signedUrls);

    return signedUrls;
  } catch (err) {
    console.error(`Failed to complete operations for bucket ${bucket}:`, err);
  }
}

// Call the main function
main();

When using AWS S3 in a real-world scenario, you typically fetch files or images directly from the S3 bucket rather than from a local directory.

Output :-
Run the above script using: node <name_of_the_file>

Bucket banner successfully created
Bucket banner is ready
File newS3.jpeg successfully uploaded to bucket banner
File s3.jpeg successfully uploaded to bucket banner
Found keys: [ 'newS3.jpeg', 's3.jpeg' ]
Signed URLs for the uploaded images: [
  'http://localhost:4566/banner/newS3.jpeg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=test%2F20240713%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240713T145911Z&X-Amz-Expires=3600&X-Amz-Signature=e82c43d8017029c9e175df4ba4e7c317fecc4240c8a745291ed04696facc4da4&X-Amz-SignedHeaders=host&x-id=GetObject',

  'http://localhost:4566/banner/s3.jpeg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=test%2F20240713%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240713T145911Z&X-Amz-Expires=3600&X-Amz-Signature=e4d173ae016a3d89d0355d92b0f59b0b008866d18d2a4cfda2a93fcda381fb0c&X-Amz-SignedHeaders=host&x-id=GetObject'
]

If you want to build an API to get those URLs and send them to the frontend, you can integrate the script with an Express server by creating & exposing a route utilizing this script.

This approach not only demonstrates the practical use of the AWS SDK and LocalStack for local development but also shows how you can extend this functionality to real-world applications by integrating it with backend services like Express.js

Here is documentation to follow you will get deatil of each method which I have used in the script.
aws sdk v3

Let me know in comments if you need help in exposing the api

That's it for today, thanks if you are reading till here ! Hope you enjoyed reading it.