DEV Community: Kerisnarendra

AWS Application Load Balancer Setup

Kerisnarendra — Fri, 21 Jul 2023 22:42:51 +0000

Introduction

In this blog post, I am going to remind myself the step-by-step process of setting up an Application Load Balancer (ALB) in AWS using the command line interface (CLI). ALB helps distribute incoming traffic across multiple EC2 instances, ensuring high availability, fault tolerance, and efficient scaling of web applications.

Prerequisites

Before we get started, make sure we have the following:

An AWS account with permissions to create security groups, launch templates, auto scaling groups, target groups, and load balancers.
Familiarity with AWS services and the AWS CLI.

Step-by-Step Guide

Create a Security Group: A security group acts as a virtual firewall for instances, controlling inbound and outbound traffic. Run the following command to create a security group named "my-security-group" allowing incoming traffic on ports 22 (SSH) and 80 (HTTP) from any source:

aws ec2 create-security-group --group-name my-security-group --description "my-security-group" --vpc-id OUR_VPC_ID --region OUR_REGION

Create a Launch Template: Launch templates define the launch configuration for instances. Create a launch template named "my-launch-template" using the Amazon Linux 2 AMI and T2 Micro instance type, and specify the "my-security-group" security group and user data for instance initialization:

aws ec2 create-launch-template --launch-template-name my-launch-template --image-id OUR_AMI_ID --instance-type t2.micro --security-group-ids OUR_SECURITY_GROUP_ID --user-data file://user-data-script.txt --region OUR_REGION

user-data-script.txt contains these command below to install and start Apache HTTPD and deploy a web page to let us know where the EC2 instance is located:

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
AZ=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
echo '<center><h1>This EC2 instance is located in Availability Zone: AZ</h1></center>' > /var/www/html/index.txt
sed "s/AZ/$AZ" /var/www/html/index.txt > /var/www/html/index.html

Create an Auto Scaling Group (ASG): An ASG manages the desired number of instances, scaling them based on demand. Create an ASG named "my-auto-scaling-group" with a minimum size of 1, maximum size of 3, and desired capacity of 2 instances. Specify the subnets we want to use for instances:

aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-auto-scaling-group --launch-template LaunchTemplateName=my-launch-template,Version=1 --min-size 1 --max-size 3 --desired-capacity 2 --vpc-zone-identifier "OUR_SUBNET_IDS" --region OUR_REGION

Create a Target Group: A target group defines a set of instances that handle incoming traffic. Create a target group named "my-target-group" for HTTP traffic on port 80 in our default VPC:

aws elbv2 create-target-group --name my-target-group --protocol HTTP --port 80 --vpc-id OUR_VPC_ID --region OUR_REGION

Create an Application Load Balancer (ALB): Now, create an ALB named "my-application-load-balancer" that is internet-facing, using the "my-target-group" target group, and associated with the previously created security group:

aws elbv2 create-load-balancer --name my-application-load-balancer --subnets OUR_SUBNET_IDS --security-groups OUR_SECURITY_GROUP_ID --scheme internet-facing --type application --region OUR_REGION

Create a Listener: A listener configures the ALB to forward incoming requests to the target group. Create a listener for HTTP traffic on port 80, forwarding it to "my-target-group":

aws elbv2 create-listener --load-balancer-arn OUR_ALB_ARN --protocol HTTP --port 80 --default-actions Type=forward,TargetGroupArn=OUR_TARGET_GROUP_ARN --region OUR_REGION

Attach the Auto Scaling Group to the Load Balancer: Finally, attach the ASG "my-auto-scaling-group" to the ALB using the "my-target-group" target group:

aws autoscaling attach-load-balancer-target-groups --auto-scaling-group-name my-auto-scaling-group --target-group-arns OUR_TARGET_GROUP_ARN --region OUR_REGION

Conclusion:

ALB plays a vital role in ensuring our application can handle varying loads while maintaining high availability. By following this guide, you can create a robust infrastructure that scales seamlessly with demand. Happy load balancing!

NestJS: Making Server-Side Development Easier - My Thoughts

Kerisnarendra — Fri, 21 Jul 2023 06:03:23 +0000

Introduction:

In this blog post, I want to remind myself why I decided to learn NestJS. As a developer who wants to create strong, reliable, and expandable server-side applications using TypeScript, NestJS caught my attention as a good recommendation. Let's explore the reasons that make NestJS worth the time and effort.

Understanding NestJS Compared to React and Angular:

To understand what NestJS is all about, it's important to compare it with React and Angular, which are frameworks used for front-end development. React is known for its flexibility and freedom to create user interfaces, mainly for the client-side. On the other hand, Angular takes a comprehensive approach, providing stability and reliability for building web applications.

The Role of NestJS on the Server-Side:

While React is great for the front-end, the server-side requires a different way of doing things. NestJS comes in as the perfect solution, offering a framework that meets the server's need for security and strength.

What is NestJS, and Why Should I Learn It?

NestJS is a powerful framework designed to build efficient and expandable server-side applications using TypeScript. Inspired by Angular, NestJS follows the principles of organizing code, writing clean and structured code, and managing dependencies. TypeScript's strong typing and robust features make it the main language for NestJS.

Exploring the Advantages of NestJS:

When it comes to back-end development, the focus is more on data and logic rather than user experience. NestJS excels in this area with its structured approach, influenced by Angular. This strong foundation allows NestJS to offer many features for organizing code effectively, including modular architecture, data manipulation through pipes, and the use of controllers.

A Wide Range of Built-in Features:

NestJS doesn't just offer a structured approach; it goes above and beyond by providing a wide range of built-in features. These include task scheduling, queue management, logging, cookie handling, validation, and much more. Additionally, the framework seamlessly integrates WebSockets, which allows real-time communication in applications like chat or multiplayer games. Another great advantage is that NestJS supports both REST and GraphQL APIs, giving developers the flexibility to choose the best option for their project.

NestJS vs. Other Node.js Frameworks:

Compared to other Node.js frameworks like Express.js, NestJS stands out with its comprehensive set of features, structured approach, and strength. Unlike React or Express, which may require additional libraries for certain features, NestJS offers a complete solution, reducing the need to search for external dependencies. However, it's important to note that NestJS's extensive capabilities come with a steeper learning curve and may feel overwhelming for smaller projects.

The True Value of Learning NestJS:

So, why should I invest my time in learning NestJS? The steep learning curve is actually one of the main reasons why NestJS is worth the effort. It's not just about learning a specific syntax, but also understanding the best practices of back-end development integrated into a framework. This knowledge becomes a valuable asset, even if I decide to work with a different framework or programming language later on. When I invest time in learning NestJS, I am ultimately investing in my own growth as a developer.

Conclusion:

NestJS is a powerful and valuable choice for building server-side applications. Its foundation inspired by Angular, extensive features, and structured approach make it an excellent option for developers looking for strong and expandable solutions. As I continue my journey in the ever-changing world of development, learning NestJS proves to be a valuable investment in advancing my skills and expertise. So, let's embrace NestJS and unlock its full potential to shape a brighter future in server-side development!

Unraveling the Tech Trinity: Monoliths, Microservices, and Serverless - A Comparative Analysis

Kerisnarendra — Tue, 23 May 2023 12:39:04 +0000

Introduction

In the world of software architecture, three prominent paradigms have emerged: monoliths, microservices, and serverless. Each approach has its own strengths and trade-offs. In this blog post, I will delve into a comparative analysis of these three architectures based on key criteria such as development experience, scalability, response time, reliability, and cost. Let's explore which option suits your needs best.

Criteria Boundary

Before diving into the comparison, let's set the boundaries for each criterion to provide a fair evaluation.

Development Experience:

Refactoring: Assessing the ease of modifying existing code.
Bug Fixing: Evaluating the simplicity of addressing and resolving bugs.
Feature Building: Analyzing the agility in developing new features.

Scalability:

Active Users/Requests: Measuring the ability to handle increasing user loads.

Response Time:

Gauging the system's speed in responding to user requests.

Reliability:

Error Handling: Assessing how the architecture deals with fatal errors.

Cost:

Daily Expenses: Comparing the overall cost implications of each architecture.

Comparison

Development Experience:

Monoliths: Relatively simple to refactor, fix bugs, and build features due to the consolidated codebase.
Microservices: Refactoring and fixing bugs might require coordination among multiple services, but building new features is more modular and scalable.
Serverless: Offers ease of refactoring and building features with minimal server management, while bug fixing may require navigating third-party services.

Scalability:

Monoliths: Scaling can be challenging due to the need to scale the entire application, potentially resulting in overprovisioning.
Microservices: Scalability is improved by independently scaling specific services to handle varying loads.
Serverless: Offers automatic scaling, allowing granular scaling based on demand, ensuring optimal resource utilization.

Response Time:

Monoliths: Typically faster due to direct access to the application's resources.
Microservices: Response time might vary depending on inter-service communication and network latency.
Serverless: Response time can be slightly slower due to the overhead of function invocation and initialization (cold start).

Reliability:

Monoliths: A fatal error in one component can bring down the entire system.
Microservices: Isolated services limit the impact of failures, improving overall system reliability.
Serverless: Third-party dependencies and serverless platform limitations can impact reliability, but individual failures are often contained.

Cost:

Monoliths: Usually more cost-effective for smaller applications, as fewer resources and infrastructure are required.
Microservices: Higher infrastructure costs due to managing multiple services, but potential cost savings can be achieved through optimized resource allocation.
Serverless: Cost depends on usage, but serverless architectures can provide cost efficiencies for low to moderate workloads.

FAQs

Q: How do I decide which architecture is best for my project?
A: Choosing the right architecture depends on various factors specific to your project. Consider the following guidelines:

Monoliths: Opt for a monolithic architecture if your application is relatively small, has a simple domain, and requires a quick development cycle with less emphasis on scalability.
Microservices: Choose microservices if your application is complex, with multiple teams working on different components, and requires independent scalability and deployment of services.
Serverless: Consider serverless if you have sporadic workloads, want to focus more on application logic rather than infrastructure management, and require automatic scaling.

Q: Can microservices be combined with serverless?
A: Yes, microservices can be combined with serverless architecture. In fact, it is common to see microservices implemented using serverless functions. You can leverage the benefits of both approaches by building each microservice as a serverless function, enabling independent scalability and deployment, while leveraging the serverless infrastructure for reduced operational overhead.

Q: Are there any specific performance considerations for each architecture?
A: Performance considerations vary across architectures:

Monoliths: Direct access to resources often results in faster response times. However, as the application grows, scalability might become a challenge.
Microservices: Inter-service communication and network latency can impact response times. Ensuring efficient communication protocols and minimizing network overhead is crucial for optimal performance.
Serverless: The overhead of function invocation and initialization might lead to slightly slower response times. Fine-tuning function cold start times and optimizing resource allocation can help mitigate this impact.

Conclusion

Choosing the right architecture depends on your project's specific requirements. Monoliths provide simplicity, microservices offer scalability, while serverless offers flexibility and cost efficiencies. Consider the development experience, scalability needs, response time expectations, reliability concerns, and cost implications to make an informed decision. Remember, there's no one-size-fits-all solution. Evaluate your project's unique needs and constraints before adopting an architecture that aligns with your goals.

Cross-Account Access to Amazon S3 using STS:AssumeRole

Kerisnarendra — Fri, 19 May 2023 04:53:34 +0000

Introduction

Amazon Simple Storage Service (S3) is a widely-used object storage service offered by Amazon Web Services (AWS). It provides secure, durable, and scalable storage for various types of data. In some scenarios, we may need to grant access to our S3 buckets to AWS accounts that are different from the one where the bucket resides. This is where cross-account access comes into play, and AWS Security Token Service (STS) with the AssumeRole API becomes the key mechanism to securely share data across accounts. In this guide, we will explore the steps to set up cross-account access to S3 using the sts:AssumeRole mechanism.

Step-by-Step Guide

Creating the IAM Role in the Destination Account:
Sign in to the AWS Management Console of the destination account.
Navigate to the IAM (Identity and Access Management) service. Create a new IAM role with the necessary permissions for accessing S3.
Define a trust policy that specifies the source AWS account(s) allowed to assume this role using the sts:AssumeRole API.

{
"Version": "2012-10-17",
"Statement": {
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT_SOURCE_ID:root"
    }
    "Action": "sts:AssumeRole",
    "Condition": {
        "StringEquals": {
            "sts:ExternalId": "EXTERNAL_ID"
            }
        }
    }
}

Attach the desired permissions policy that grants access to the specific S3 bucket(s).

{
"Version": "2012-10-17",
"Statement": {
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
    }
}

Assuming the IAM Role in the Source Account:
Sign in to the AWS Management Console of the source account. Navigate to the IAM service.
Create a new IAM user or use an existing one to assume the role in the destination account.
Attach the necessary permissions to the IAM user or group to allow assuming the role.

{
"Version": "2012-10-17",
"Statement": {
    "Effect": "Allow",
    "Action": [
        "iam:ListRoles",
        "sts:AssumeRole",
    ],
    "Resource": "*"
    }
}

Assuming the Role Programmatically:
Use the AWS SDK or AWS CLI in the source account to assume the IAM role in the destination account.
Specify the RoleArn **of the IAM role, the **RoleSessionName to identify the session, and optionally, an ExternalId for additional security.
The AssumeRole operation returns temporary security credentials consisting of an AccessKeyId, SecretAccessKey, SessionToken, and Expiration.

aws sts assume-role --role-arn "arn:aws:iam::ACCOUNT_DESTINATION_ID:role/TRUST_POLICY_ROLE_NAME_IN_ACCOUNT_DESTINATION" --role-session-name SESSION_NAME --external-id EXTERNAL_ID

Accessing the S3 Bucket in the Destination Account:
Use the temporary security credentials obtained after assuming the role to access the S3 bucket in the destination account.
Configure our AWS SDK or AWS CLI to use the temporary credentials when making S3 API requests.
These credentials have the necessary permissions as defined in the IAM role's permissions policy.
Testing and Verifying Access:
Perform tests to ensure that the cross-account access is working as expected.
Use the AWS CLI or SDKs to list, upload, or download objects from the S3 bucket.
Verify that the access control policies on the S3 bucket are correctly configured to allow the assumed role.

FAQ

Q: What is the benefit of using sts:AssumeRole for cross-account access?

A: The sts:AssumeRole mechanism allows us to grant temporary access to another AWS account without sharing long-term credentials, enhancing security and reducing the attack surface.
Q: Can I restrict the duration of the assumed role's access?

A: Yes, we can define an expiration time for the temporary credentials obtained through sts:AssumeRole, ensuring limited access to the destination account.
Q: Are there any additional costs associated with cross-account access to S3?

A: No, there are no additional costs

Conclusion

Cross-account access to Amazon S3 using the sts:AssumeRole mechanism provides a secure and efficient way to share data between AWS accounts. By leveraging IAM roles and the Security Token Service, we can grant temporary access to S3 buckets without sharing long-term credentials. This approach enhances security and allows for fine-grained control over access permissions. Whether we need to collaborate with external partners, consolidate data from multiple accounts, or implement multi-tier architectures, the sts:AssumeRole mechanism simplifies cross-account access and empowers us to utilize the full potential of AWS cloud storage.

Securing Our AWS Environment: Preventing Privilege Escalation with Permission Boundaries

Kerisnarendra — Sun, 14 May 2023 15:21:09 +0000

Introduction

In the world of AWS, security is incredibly important. To keep things secure, it's important to make sure that users and roles only have the access they need to do their jobs. But sometimes, users or roles end up with more access than they should have, which can be dangerous. That's where privilege escalation comes in.

Privilege escalation is when someone gains access to more resources or permissions than they're supposed to have. This can happen if there's a security vulnerability that lets someone exploit the system. If someone manages to escalate their privileges, they can access things they shouldn't be able to, and that can be really bad for a company.

In this blog post, I am going to remind myself how to prevent privilege escalation using a permission boundary in AWS IAM.

Prerequisites

Before we begin, make sure we have the following:

An AWS account with IAM access
Basic knowledge of AWS IAM and policies
The permission boundary JSON file below

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Action": [
                "iam:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Sid": "DenyPermBoundaryIAMPolicyAlteration",
            "Effect": "Deny",
            "Action": [
                "iam:DeletePolicy",
                "iam:DeletePolicyVersion",
                "iam:CreatePolicyVersion",
                "iam:SetDefaultPolicyVersion"
            ],
            "Resource": [
                "arn:aws:iam::Account_ID:policy/PermissionPolicy"
            ]
        },
        {
            "Sid": "DenyRemovalOfPermBoundaryFromAnyUserOrRole",
            "Effect": "Deny",
            "Action": [
                "iam:DeleteUserPermissionsBoundary",
                "iam:DeleteRolePermissionsBoundary"
            ],
            "Resource": [
                "arn:aws:iam::Account_ID:user/*",
                "arn:aws:iam::Account_ID:role/*"
            ],
            "Condition": {
                "StringEquals": {
                    "iam:PermissionsBoundary": [
                        "arn:aws:iam::Account_ID:poliy/PermissionBoundary"
                    ]
                }
            }
        },
        {
            "Sid": "DenyUserAndRoleCreationWithoutPermBoundary",
            "Effect": "Deny",
            "Action": [
                "iam:CreateUser",
                "iam:CreateRole"
            ],
            "Resource": [
                "arn:aws:iam::Account_ID:role/*",
                "arn:aws:iam::Account_ID:user/*"
            ],
            "Condition": {
                "StringNotEquals": {
                    "iam:PermissionsBoundary": [
                        "arn:aws:iam::Account_ID:policy/PermissionBoundary"
                    ]
                }
            }
        }
    ]
}

Step-by-Step Guide

Create an IAM policy that allows users and roles to perform their intended actions, but also includes a permission boundary to limit their privileges. This policy should be applied to the users and roles in our AWS account.
Note: We have already been provided with a sample permission boundary JSON file. We can use this as a starting point for our own permission boundary policy.
Create an IAM policy that denies the creation of new users and roles without a permission boundary. This policy should be applied to all users and roles in our AWS account.
Create an IAM policy that denies the removal of permission boundaries from any user or role. This policy should be applied to all users and roles in our AWS account.
Create an IAM policy that denies the alteration of the permission boundary policy. This policy should be applied to the permission boundary policy in our AWS account.
Once the policies have been created, apply them to the appropriate users and roles in our AWS account.
Test the policies by attempting to create a user or role without a permission boundary. The policy should deny the creation and provide an error message.
Test the policies by attempting to remove the permission boundary from a user or role. The policy should deny the removal and provide an error message.
Test the policies by attempting to alter the permission boundary policy. The policy should deny the alteration and provide an error message.

FAQ

Q: What is a permission boundary in AWS IAM?
A: A permission boundary is an advanced feature in AWS IAM that allows us to set the maximum permissions for a user or role. It limits what actions a user or role can perform on AWS resources.

Q: Why is a permission boundary important?
A: A permission boundary is important because it can help prevent privilege escalation. By setting a maximum level of permissions, we can ensure that users and roles only have the access they need to perform their intended actions.

Q: How do I know if I am vulnerable to privilege escalation?
A: We can assess our AWS environment for privilege escalation vulnerabilities using tools like AWS IAM Access Analyzer.

Conclusion

Privilege escalation can be a serious security issue in an AWS environment. By using a permission boundary, we can help prevent this issue from occurring. In this blog post, we went through the steps needed to handle privilege escalation using a permission boundary in AWS IAM. It is important to regularly review and update our IAM policies to ensure that they are up-to-date and providing the appropriate level of access to users and roles in our AWS account.

Automating EC2 Instance Start/Stop using Serverless Code and CloudWatch Rule

Kerisnarendra — Fri, 12 May 2023 04:47:00 +0000

Introduction

In this blog post, I am going to remind myself how to use serverless(https://www.serverless.com/) and a CloudWatch rule to automate starting and stopping EC2 instances in AWS. This is particularly useful for teams that need to frequently scale up and down their infrastructure. We'll also cover the cron syntax used to specify the schedule for the CloudWatch rule, including an important limitation to be aware of. By automating this process, we can save time and reduce costs by only running EC2 instances when we need them.

Prerequisites

Before we get started, make sure we have the following:

An AWS account with permissions to create EC2 instances, CloudWatch rules, and Lambda functions.
An EC2 instance that we want to start and stop based on a schedule.
A basic understanding of serverless and the AWS CloudWatch service.

Step-by-Step Guide

To create a CloudWatch rule that invokes a Lambda function to start and stop an EC2 instance using serverless code, follow these steps:

Set up a new serverless project in AWS by running the command "serverless create --template aws-nodejs --path ec2-scheduler".
Navigate to the "ec2-scheduler" folder and open the "serverless.yml" file.
Under "provider", add the following lines to allow the Lambda function to start and stop EC2 instances:

service: ec2-scheduler

provider:
  name: aws
  runtime: nodejs16.x
  stage: dev
  region: ap-southeast-1
  stackName: ${self:service}
  stackTags:
    Name: ${self:service}
  iam:
    role:
      statements:
        - Effect: "Allow"
          Action:
            - "ec2:StartInstances"
            - "ec2:StopInstances"
          Resource: "*"

Under "custom", add the instance ID of the EC2 instance we want to start and stop, as well as the cron expressions for starting and stopping the instance. For example:

custom:
  instanceId: i-0f00
  start: cron(0 0 ? * MON-FRI *)
  stop: cron(15 9 ? * MON-FRI *)

This will start the instance at 0:0 AM (UTC) every Monday through Friday and stop the instance at 9:15 PM (UTC) every Monday through Friday.
The cron() expression syntax should conform to the following, where all six fields are required and must be separated by a white space:
cron(Minutes Hours Day-of-Month Month Day-of-Week Year)
Each field can have the following values/wildcards:

Notes: Make Sure We're Not Using * in Both the Day-of-Month and Day-of-Week Fields

Under "functions", create two functions: "start" and "stop". These functions will call the "startInstances" and "stopInstances" methods of the EC2 service, respectively. For example:

functions:
  start:
    handler: handler.start
    events:
      - schedule:
          rate: ${self:custom.start}
          input:
            id: ${self:custom.instanceId}
            region: ${self:provider.region}

  stop:
    handler: handler.stop
    events:
      - schedule:
          rate: ${self:custom.stop}
          input:
            id: ${self:custom.instanceId}
            region: ${self:provider.region}

Create the "handler.js" file and define the "start" and "stop" functions that will be called by the "start" and "stop" functions defined in the "serverless.yml" file. For example:

'use strict'

const AWS = require('aws-sdk');

module.exports.start = (event, context, callback) => {
  const ec2 = new AWS.EC2({region: event.region});

  ec2.startInstances({InstanceIds: [event.id]}).promise()
    .then(() => callback(null, `Successfully started ${event.id}`))
    .catch(err => callback(err))
};

module.exports.stop = (event, context, callback) => {
  const ec2 = new AWS.EC2({region: event.region});

  ec2.stopInstances({InstanceIds: [event.id]}).promise()
    .then(() => callback(null, `Successfully stopped ${event.id}`))
    .catch(err => callback(err))
};

Deploy the project by running the command "serverless deploy --aws-profile aws-profile-in-dot-aws-folder". This will create the CloudWatch rule and Lambda function in our AWS account.
Once the deployment is complete, verify that the CloudWatch rule and Lambda function have been created in the AWS console.
Test the solution by waiting for the scheduled time to start and stop the EC2 instance. We should see the instance status change in the AWS console.

FAQ

Q: Can I schedule different start and stop times for different instances?
A: Yes, we can modify the "custom" section of the serverless.yaml file to specify different instance IDs and schedules for each instance.

Q: What if the Lambda function fails to start or stop the instance?
A: The Lambda function will return an error message if it fails to start or stop the instance. We can view the error message in the AWS console or in the CloudWatch logs.

Q: Can I use this solution with other AWS services besides EC2 instances?
A: Yes, we can modify the Lambda function code to interact with other AWS services.

References

Conclusion

Automating the start and stop of EC2 instances based on a schedule can help we save time and reduce costs by only running instances when they are needed. Using serverless code and a CloudWatch rule makes it easy to implement this solution in our AWS account. With this solution in place, we can focus on other important tasks while our infrastructure scales up and down automatically.

Memoization in JavaScript: The need for speed

Kerisnarendra — Wed, 22 Mar 2023 08:44:03 +0000

Memoization is a technique used in programming to optimize the performance of frequently executed functions. It involves caching the results of a function call, so that the same results can be returned for subsequent calls with the same arguments, rather than recalculating them each time.

Memoization is based on the idea that if a function is called with the same arguments multiple times, it will return the same result each time. Therefore, it makes sense to cache the result of the first function call and return it for all subsequent calls with the same arguments.

The process of memoization involves creating a cache object, which is used to store the results of function calls. When a function is called with a set of arguments, the cache object is checked to see if the result for those arguments already exists. If it does, the cached result is returned; otherwise, the function is executed, and the result is stored in the cache object for future use.

Memoization can be particularly useful for functions that are computationally expensive or have complex logic. By caching the result of the first call, subsequent calls with the same arguments can be executed quickly and without the need to repeat the same calculations.

In Node.js, memoization can be implemented using a variety of techniques. One common approach is to use a JavaScript object to store the cached results. Here's an example of a simple memoization function:

function memoize(func) {
  const cache = {};
  return function(...args) {
    const key = JSON.stringify(args);
    if (cache[key]) {
      return cache[key];
    }
    const result = func.apply(this, args);
    cache[key] = result;
    return result;
  };
}

This function takes a function as an argument and returns a new function that wraps the original function with memoization. The cache object is created as an empty JavaScript object, and a new function is returned that will be used to execute the memoized function.

The memoized function takes a variable number of arguments using the spread syntax ...args. These arguments are converted into a string using the JSON.stringify() method, which is used as the key for the cache object. If the key exists in the cache, the cached result is returned. If it doesn't, the original function is executed using the apply() method, and the result is stored in the cache object for future use.

Here's an example of how you can use the memoization function:

function fibonacci(n) {
  if (n <= 1) {
    return n;
  }
  return fibonacci(n - 1) + fibonacci(n - 2);
}

const memoizedFibonacci = memoize(fibonacci);

console.log(memoizedFibonacci(10)); // Output: 55
console.log(memoizedFibonacci(10)); // Output: 55 (cached result)

In this example, the fibonacci() function calculates the Fibonacci sequence for a given number. The memoize() function is used to create a new function memoizedFibonacci that wraps the fibonacci() function with memoization. The memoizedFibonacci() function is then called twice with the same argument, and the result is returned from the cache object on the second call.

Memoization is a powerful technique that can greatly improve the performance of your Node.js applications. By caching the results of frequently executed functions, you can avoid repeating expensive calculations and reduce the overall processing time.

Memoization is one of effective techniques for optimizing the performance of functions that execute SQL queries. By caching the results of previous queries, subsequent calls with the same arguments can be served quickly without having to re-execute the query. Another approach for improving performance is to use materialized tables, which store the results of a query in a physical table, so that subsequent queries can retrieve the pre-calculated results directly from the table. Are you interested in materialized tables topic? I discussed it in another post.

Visitor Pattern in Typescript

Kerisnarendra — Mon, 16 Jan 2023 03:21:50 +0000

Visitor design pattern is a type of behavioral pattern, a way to separate an algorithm or an action from the objects it operates on. It allows new functionality to be added to a set of classes without modifying the classes themselves, by encapsulating the new functionality in a separate class called the Visitor. This makes it more flexible, maintainable and reusable.

This pattern can be used in a real-life vehicles service scenario to perform different inspections on a variety of vehicles.

This pattern consists of the following components:

Visitor interface: it defines a visit method for each class in the object structure. Sample:

interface VehicleInspector {
    visit(car: Car): void;
    visit(van: Van): void;
    visit(motorbike: Motorbike): void;
}

Concrete visitor classes: it implements the visitor interface. Each concrete visitor class defines a specific behavior for the visit method. Sample:

class CarInspector implements VehicleInspector {
    visit(car: Car): void {
        console.log(`Visiting ${car.constructor.name} with CarInspector`);
    }
}

class VanInspector implements VehicleInspector {
    visit(van: Van): void {
        console.log(`Visiting ${van.constructor.name} with VanInspector`);
    }
}

class MotorbikeInspector implements VehicleInspector {
    visit(motorbike: Motorbike): void {
        console.log(`Visiting ${motorbike.constructor.name} with MotorbikeInspector`);
    }
}

Element interface: this defines an accept method that takes a visitor as a parameter. Sample:

interface Vehicle {
  accept(vehicleInspector: VehicleInspector): void;
}

Concrete element classes: it implements the element interface. Each concrete element class has an accept method that calls the appropriate visit method on the visitor for that class. Sample:

class Car implements Vehicle {
    accept(vehicleInspector: VehicleInspector): void {
        return vehicleInspector.visit(this)
    }
}

class Van implements Vehicle {
    accept(vehicleInspector: VehicleInspector): void {
        return vehicleInspector.visit(this)
    }
}

class Motorbike implements Vehicle {
    accept(vehicleInspector: VehicleInspector): void {
        return vehicleInspector.visit(this)
    }
}

Sample to use:

let car = new Car();
let van = new Van();
let motorbike = new Motorbike();

let carInspector = new CarInspector();
car.accept(carInspector);

let vanInspector = new VanInspector();
van.accept(vanInspector);

let motorbikeInspector = new MotorbikeInspector();
motorbike.accept(motorbikeInspector);

The result will be like this:

Visiting Car with CarInspector
Visiting Van with VanInspector
Visiting Motorbike with MotorbikeInspector