Forem: GaneshMani

Schedule sunday

GaneshMani — Sun, 01 Feb 2026 14:16:02 +0000

This is a new scheduler for the data

First data
Second data

This is for testing

Schedule again

GaneshMani — Sat, 31 Jan 2026 19:03:02 +0000

This is a new scheduler for the data

First data
Second data

This is for testing

GaneshMani — Sun, 18 Jan 2026 15:31:20 +0000

New production coming soon…

Welcome to the new product.

Zero-Downtime Deployments for Node.js Applications: A Step-by-Step Guide with AWS ECS and Terraform

GaneshMani — Thu, 19 Sep 2024 08:19:50 +0000

Deploying updates to a live application can be risky, especially if downtime affects user experience. This guide will walk you through setting up zero-downtime deployments for a Node.js application using AWS ECS (Elastic Container Service) and Terraform. We’ll explore setting up an ECS cluster, deploying a Node.js app with Docker, and using Terraform to manage the infrastructure.

Prerequisites

Before we begin, ensure you have the following:

• AWS Account: Access to an AWS account with permissions to create and manage ECS, ALB, VPC, and other resources.

• Terraform: Installed and configured to manage AWS resources.

• Docker: Installed locally to build and test the Node.js application.

• Node.js and NPM: Installed for application development and testing.

Why Choose AWS ECS for Zero-Downtime Deployments?

AWS Elastic Container Service (ECS) is a fully managed container orchestration service that simplifies deploying, managing, and scaling containerized applications. ECS excels at zero-downtime deployments for several reasons:

Managed Service: ECS abstracts the complexities of managing underlying compute resources, allowing developers to focus solely on container deployment and management.
Blue-Green Deployment Support: When combined with an Application Load Balancer (ALB), ECS effortlessly facilitates blue-green deployments. This strategy enables deploying a new version of an application alongside the old one, with traffic switched to the new version once it's proven stable.
Seamless AWS Service Integration: ECS integrates smoothly with other AWS services such as CloudWatch for monitoring, IAM for security, and ECR for Docker image management. This integration creates a robust and secure environment for deploying production workloads.
Serverless Options via AWS Fargate: ECS supports Fargate, a serverless compute engine that eliminates EC2 instance management. Fargate handles scaling, patching, and infrastructure security, further streamlining zero-downtime deployments.
Dynamic Scaling and Load Balancing: ECS offers auto-scaling capabilities, ensuring your application scales up or down based on demand. When paired with Application Load Balancers, this ensures a consistent and reliable user experience without interruptions.

Introduction to Setting Up a Node.js Application for Zero Downtime

To set up a zero-downtime deployment pipeline for a Node.js application on AWS ECS, we need to follow a series of steps:

Dockerize the Application: Package the Node.js application and its dependencies into a Docker container.
Create an ECS Cluster and Task Definitions: Define how the Docker container will run in the ECS cluster using task definitions.
Set Up an Application Load Balancer (ALB): Use an ALB to distribute incoming traffic across multiple ECS tasks and manage blue-green deployments.
Deploy the Application Using Terraform: Use Terraform to automate the provisioning and deployment of AWS resources.

Why Dockerize the Application?

Dockerizing an application means packaging it with all its dependencies, libraries, and environment settings into a single, lightweight container. This container can be deployed consistently across different environments without worrying about environment-specific issues. Dockerization is a critical step for several reasons:

Consistency Across Environments: Docker ensures that the application runs the same way in development, staging, and production environments, eliminating the “works on my machine” problem.
Isolation: Containers provide isolation from the host system and other containers. This makes managing dependencies, libraries, and runtime environments easier and reduces conflicts.
Simplified Deployment: Docker images provide a standardized unit of deployment. Once the application is packaged into a Docker image, it can be deployed to any Docker-compatible environment, such as AWS ECS.
Scalability: Docker containers are lightweight and can be quickly started, stopped, or replicated. This makes scaling applications easier and more efficient, which is essential for managing traffic and ensuring zero downtime.

Here, we have a simple Nodejs application to deploy into AWS ECS. Let’s dockerize the application to deploy.

Dockerizing a Node.js Application

Dockerizing a Node.js application involves creating a Docker image that contains the application code and all the necessary dependencies. This image can then be deployed to any environment that supports Docker.

Here’s a basic overview of the steps to Dockerize a Node.js application:

1.Create a Dockerfile: A Dockerfile is a script containing instructions on how to build a Docker image for the application. Here’s an example:

FROM --platform=linux/amd64 node:lts-alpine as builder
# Create app directory
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production image
FROM --platform=linux/amd64 node:lts-alpine
ENV NODE_ENV=production
USER node
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY --from=builder /app/build ./build
ENV PORT=8080
EXPOSE 8080
CMD [ "node", "build/main.js" ]

The provided Dockerfile uses a multi-stage build process to create a Docker image for a Node.js application. This approach is efficient because it separates the build environment from the production environment, resulting in a smaller, more secure, and optimized image for deployment. Let’s break down each part of the Dockerfile step-by-step:

1. Build Stage

The first stage is the build stage where the application is built.

# Build stage
FROM --platform=linux/amd64 node:lts-alpine as builder

• FROM –platform=linux/amd64 node:lts-alpine as builder: This line specifies the base image for the build stage. It uses the node:lts-alpine image, which is a lightweight Alpine Linux-based Node.js image. The --platform=linux/amd64 option ensures compatibility for a specific platform architecture. The as builder part gives a name to this stage, which is used later to refer to it.

# Create app directory
WORKDIR /app

•WORKDIR /app: This sets the working directory inside the Docker container to /app. All subsequent commands will be run from this directory.

COPY package*.json ./
RUN npm ci

• *COPY package.json ./**: This copies the package.json and package-lock.json files from the host machine to the current working directory inside the Docker container.

• RUN npm ci: This installs the dependencies listed in package-lock.json using npm ci (clean install). npm ci is faster and more reliable for CI/CD environments because it uses the exact versions specified in package-lock.json.

COPY . .
RUN npm run build

• COPY . .: This copies all the application source files from the host machine to the Docker container.

• RUN npm run build: This runs the build command defined in package.json to create a production-ready build of the application. The resulting files are typically placed in a build directory.

2. Production Stage

The second stage is the production stage, where the final production image is created.

# Production image
FROM --platform=linux/amd64 node:lts-alpine

• FROM –platform=linux/amd64 node:lts-alpine: This starts a new stage using the same node:lts-alpine base image but without the as builder alias. This is a fresh, minimal environment that will only contain the production-ready application.

ENV NODE_ENV=production
USER node
WORKDIR /app

• ENV NODE_ENV=production: This sets the NODE_ENV environment variable to production, which optimizes the performance of the Node.js application for production use.

• USER node: This switches the user from root to node, which is a non-privileged user that comes with the node Docker image. Running as a non-root user enhances the security of the container.

• WORKDIR /app: This sets the working directory to /app for this stage as well.

COPY package*.json ./
RUN npm ci --production

• *COPY package.json ./**: This copies the package.json and package-lock.json files again into the working directory of the production stage.

• RUN npm ci –production: This installs only the production dependencies by using the --production flag, which helps reduce the image size and surface area for vulnerabilities.

COPY --from=builder /app/build ./build

• COPY –from=builder /app/build ./build: This copies the built application files from the /app/build directory of the builder stage to the /build directory of the current (production) stage. This is where the built code lives and will be executed from.

ENV PORT=8080
EXPOSE 8080

• ENV PORT=8080: This sets the PORT environment variable to 8080, which is the port on which the Node.js application will run.

• EXPOSE 8080: This exposes port 8080 to the outside world, allowing external access to the application running inside the container.

CMD[('node', 'build/main.js')];

• CMD [“node”, “build/main.js”]: This is the command that runs when the Docker container starts. It starts the Node.js application by executing node build/main.js, which is the entry point of the built application.

Why Multi-Stage Docker build?

Smaller Image Size: By separating the build and production stages, only the essential files and dependencies are included in the final image, reducing the overall size.
Security: Running as a non-root user and excluding unnecessary build tools in the final image enhances security.
Efficiency: Multi-stage builds avoid the overhead of creating and managing multiple Dockerfiles for different environments. It also speeds up the CI/CD pipeline by ensuring that dependencies are cached and reused efficiently.
Consistency: The build and deployment processes are defined in code (the Dockerfile), ensuring consistent and reproducible environments.

Now, we have the docker build ready to deploy to ECS. Let’s configure infrastructure to provision the resources.

Provisioning Infrastructure using Terraform

When configuring infrastructure to provision resources for deploying a Dockerized Node.js application on AWS ECS using Terraform, it’s common to follow a modular approach. This approach enhances code readability, reusability, and maintainability by organizing each resource in its own module. Here, we are going to follow the same approach separating each resource as module and configure them using terraform.

Terraform structure

infra/
├── main.tf
├── variables.tf
├── outputs.tf
├── providers.tf
├── vpc/
│   ├── main.tf
│   ├── variables.tf
│   ├── outputs.tf
├── ecs/
│   ├── main.tf
│   ├── variables.tf
│   ├── outputs.tf
├── alb/
│   ├── main.tf
│   ├── variables.tf
│   ├── outputs.tf
├── dynamodb/
│   ├── main.tf
│   ├── variables.tf
│   ├── outputs.tf
└── cloudwatch/
    ├── main.tf
    ├── variables.tf
    ├── outputs.tf

main.tf: This is the root configuration file where the infrastructure’s main components are defined. It pulls together all the modules and provides overall orchestration.
variables.tf: This file contains input variables used across the infrastructure. These variables help make the code more dynamic and flexible.
outputs.tf: Defines the outputs of the Terraform configuration, which are the values you may need to reference later, such as IDs, ARNs, or URLs.
providers.tf: Specifies the cloud provider (AWS) and any additional provider-specific configurations required for the deployment.

Module Structure

•vpc/: Sets up the Virtual Private Cloud (VPC), subnets, and security groups. This foundational module establishes the networking layer for other components.

•ecs/: Configures the ECS Cluster, Service, and Task Definition. It defines the compute environment for running the Dockerized application.

•alb/: Creates the Application Load Balancer (ALB). The ALB distributes incoming traffic to ECS Service instances, enabling zero-downtime deployments.

•cloudwatch/: Establishes CloudWatch Logs for monitoring and logging. This module captures application logs for troubleshooting.

Deploying the infrastructure requires a logical order to resolve dependencies correctly:

1.vpc/ Module: Begin with the VPC, subnets, and security groups. This foundational network layer must be in place before other components.

2.alb/ Module: Set up the Application Load Balancer next. The ALB depends on the subnets and security groups defined in the VPC module.

3.ecs/ Module: Deploy the ECS Cluster, Service, and Task Definition after the ALB. ECS resources rely on both the VPC for networking and the ALB for load balancing.

4.cloudwatch/ Module: Configure CloudWatch Logs to monitor ECS tasks. Deploy this module alongside or after the ECS module.

Now, we have an idea of modules required to deploy the application to AWS ECS and achieving Zero downtime. Let’s provision the infrastructure to deploy it.

1. Configuring default VPC

The vpc/main.tf file is responsible for defining the networking environment required for deploying resources such as ECS (Elastic Container Service), ALB (Application Load Balancer), and other AWS services. In this code, we are creating a Default VPC along with Default Subnets in two different availability zones.


resource "aws_default_subnet" "default_subnet_ab" {
    availability_zone = "${var.aws_region}a"
}

resource "aws_default_subnet" "default_subnet_ac" {
    availability_zone = "${var.aws_region}b"
}

resource "aws_default_vpc" "ecs_vpc" {
    tags = {
        Name = "ecs-vpc"
    }
}

Now, we have the default VPC to configure ECS. Let’s provision resources to create ECS clusters and Services.

2. Setting Up ECS Task Definition and ECS Service

The ecs/main.tf file contains the configuration for setting up the ECS Cluster, Task Definition, and ECS Service.

resource "aws_ecs_task_definition" "ecs-nodejs-api-task-definition" {
  family = "ecs-nodejs-api-task"
  container_definitions = <<DEFINITION
  [
    {
      "name": "web-api",
      "image": "${var.ecr_repository_url}:${var.ecr_repository_tag}",
      "essential": true,
      "portMappings": [
        {
          "containerPort": 8080,
          "hostPort": 8080
        }
      ],
      "memory": 512,
      "cpu": 256,
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "${module.ecs_task_logs.log_group_name}",
          "awslogs-region": "${var.aws_region}",
          "awslogs-stream-prefix": "web-api"
        }
      }
    }
  ]
  DEFINITION
  requires_compatibilities = ["FARGATE"]
  network_mode = "awsvpc"
  memory = 2048
  cpu = 1024
  execution_role_arn = "${aws_iam_role.ecsTaskExecutionRole.arn}"
}

• family: This is a name used to group multiple versions of a task definition.

• container_definitions: A JSON block that defines the containers within the task. Here, we specify the container’s name, Docker image, essential status, port mappings, memory, CPU, and log configuration.

• The image is pulled from an ECR repository (var.ecr_repository_url), with a specific tag (var.ecr_repository_tag).

• Port Mappings: Maps container port 8080 to the host port 8080.

• Log Configuration: Uses AWS CloudWatch Logs to capture and store logs, with the log group specified by module.ecs_task_logs.log_group_name.

• requires_compatibilities: Specifies that this task definition is compatible with the Fargate launch type.

• network_mode: Uses awsvpc mode for better security and networking control.

• memory and cpu: Specifies the memory and CPU requirements for the task.

• execution_role_arn: Refers to an IAM role (ecsTaskExecutionRole) that grants the ECS tasks necessary permissions.

CloudWatch Log Group Configuration

resource "aws_cloudwatch_log_group" "ecs_task_logs" {
  name = "ecs-web-api"
}

A Log Group in CloudWatch is a group of log streams that share the same retention, monitoring, and access control settings. A Log Stream represents a sequence of log events that share the same source, such as an ECS task.

• Centralized Logging: The ecs-web-api log group will store all the logs emitted by the ECS tasks running the Node.js application. This helps in centralized logging and monitoring.

• Log Management: CloudWatch Log Groups allow you to manage retention policies, monitor logs, and create alarms for specific patterns (e.g., errors or exceptions).

Logging is essential for zero-downtime deployments as it enables real-time monitoring of the process, facilitates quick identification and resolution of issues, provides insights into application behavior before and after deployment, aids in troubleshooting and potential rollbacks, and supports continuous improvement of the deployment process. By maintaining comprehensive logs, teams can ensure smooth transitions, minimize risks, and optimize future updates, all of which are crucial for maintaining uninterrupted service during deployments.

ECS Cluster and Service

resource "aws_ecs_cluster" "ecs-cluster" {
  name = "ecs-web-api-cluster"
}

resource "aws_ecs_service" "ecs-nodejs-api-service" {
  name = "ecs-nodejs-api-service"
  cluster = "${aws_ecs_cluster.ecs-cluster.id}"
  task_definition = "${aws_ecs_task_definition.ecs-nodejs-api-task-definition.arn}"
  launch_type = "FARGATE"
  desired_count = 1

  load_balancer {
    target_group_arn = "${module.alb.alb_target_group.arn}"
    container_name = "web-api"
    container_port = 8080
  }

  network_configuration {
    subnets = ["${module.vpc.default_subnet_ab}", "${module.vpc.default_subnet_ac}"]
    security_groups = ["${module.alb.ecs_service_security_group_id.id}"]
    assign_public_ip = true
  }
}

• ECS Cluster: The cluster (ecs-web-api-cluster) is the container orchestration environment where our ECS tasks will run.

• ECS Service:

• name: Name of the ECS service.

• cluster: Specifies the cluster where the service runs.

• task_definition: Refers to the ECS task definition that describes how the container should be configured.

• launch_type: Fargate is chosen for serverless compute resources, allowing focus on application development without managing servers.

• desired_count: Sets the number of tasks to run; here, it’s set to 1.

• load_balancer: Associates the ECS service with a target group in an Application Load Balancer (ALB).

• network_configuration: Specifies subnets, security groups, and whether to assign a public IP.

Here is a parameter that plays a major role for Zero-downtime deployment. The desired_count parameter is set to 1 in this example for simplicity, but it plays a crucial role in zero-downtime deployments. In a production environment, you would typically set this to a higher number to ensure high availability and fault tolerance. For zero-downtime deployments, you would:

Start with multiple tasks running (e.g., desired_count = 2 or higher).
When deploying a new version, ECS will gradually replace old tasks with new ones, ensuring that there's always at least one healthy task running.
The ALB continues to route traffic to healthy tasks during this process, preventing any downtime.
Once all tasks are updated and healthy, the deployment is complete without any service interruption.

This approach ensures continuous service availability during updates, which is the essence of zero-downtime deployments. Adjusting the desired_count based on your application's needs and traffic patterns is key to optimizing this process.

3. Configuring the Application Load Balancer (ALB)

The alb/main.tf file configures the Application Load Balancer, which distributes incoming traffic to the ECS tasks for high availability.

Load Balancer Security Group

resource "aws_security_group" "load_balancer_sg" {
  vpc_id = "${module.vpc.vpc.id}"

  ingress {
    from_port = 0
    to_port = 0
    protocol = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port = 0
    to_port = 0
    protocol = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

This security group allows inbound and outbound traffic from any IP address. In a real-world scenario, it’s advisable to restrict these to specific IPs or ranges for security.

It is important to note that the security group configuration shown here is for demonstration purposes only. In a production environment, it is absolutely essential to implement strict security measures. Allowing unrestricted inbound and outbound traffic (0.0.0.0/0) poses significant security risks and should never be used in a real-world scenario. Instead, you should:

Limit inbound traffic to only necessary ports and protocols (e.g., HTTP/HTTPS for web traffic).
Restrict inbound access to known IP ranges or VPCs where possible.
Configure outbound rules to allow only required connections, adhering to the principle of least privilege.
Regularly audit and update security group rules to maintain a strong security posture.

Implementing these security best practices is critical for protecting your infrastructure and data in production environments.

ALB Target Group

resource "aws_lb_target_group" "alb_target_group" {
  port = 8080
  protocol = "HTTP"
  target_type = "ip"
  name_prefix = "alb-tg"
  vpc_id = "${module.vpc.vpc.id}"

  health_check {
    path = "/health"
  }

  lifecycle {
    create_before_destroy = true
  }
}

• port and protocol: Specifies that the target group listens on HTTP port 8080.

• target_type: Set to ip for IP-based routing.

• name_prefix: Allows Terraform to generate a unique name based on this prefix.

• health_check: Ensures that only healthy targets receive traffic.

• lifecycle - create_before_destroy: Ensures a new target group is created before destroying the old one to prevent downtime during updates.

Load Balancer Listener

resource "aws_lb_listener" "listener" {
  load_balancer_arn = "${aws_alb.app_load_balancer.arn}"
  port              = 80
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = "${aws_lb_target_group.alb_target_group.arn}"
  }

  depends_on = [aws_lb_target_group.alb_target_group]
}

• port and protocol: The listener listens for incoming HTTP traffic on port 80.

• default_action: Forwards incoming traffic to the target group (alb_target_group).

Application Load Balancer

resource "aws_alb" "app_load_balancer" {
  name = "ecs-web-api-alb"
  load_balancer_type = "application"

  subnets = [
    "${module.vpc.default_subnet_ab}",
    "${module.vpc.default_subnet_ac}"
  ]

  security_groups = [
    "${aws_security_group.load_balancer_sg.id}",
  ]
}

• load_balancer_type: Specifies that this is an Application Load Balancer.

• subnets: Subnets where the ALB is deployed.

• security_groups: Associates the ALB with the load_balancer_sg security group defined earlier.

The ECS Cluster and Service are tightly integrated with the ALB for traffic distribution. The security groups and VPC settings ensure proper networking and isolation, while the use of CloudWatch provides observability into the application’s performance and logs.

Now that we have all the resources to create our AWS ECS environment, let's deploy our Terraform module to provision the infrastructure. The process involves three key steps:

Run terraform init to download the necessary provider plugins and set up the local environment for managing resources.
Use terraform plan to generate an execution plan. This outlines the changes Terraform will make to achieve the desired state defined in your configuration files.
After reviewing and approving the plan, execute terraform apply. This provisions the resources on AWS, creating a fully configured environment based on your code.

By following these steps, you'll transform your Terraform configuration into a live, functioning AWS ECS infrastructure.

It’s important to thoroughly review the plan output before executing terraform apply. This review step allows you to:

Verify that the planned changes align with your intentions and requirements
Identify any potential issues or unintended modifications
Ensure that critical resources are not accidentally deleted or altered
Catch any configuration errors before they impact your live environment.

Checkout the complete code here.

Conclusion

AWS ECS (Elastic Container Service) offers a robust solution for running containerized applications, providing a highly scalable, secure, and reliable environment with minimal operational overhead. By leveraging ECS with Terraform, you can achieve zero-downtime deployments for Node.js applications—ensuring seamless updates without service interruptions. Dockerizing the application and deploying it on ECS with Fargate allows for serverless management of containers, simplifying infrastructure requirements and reducing costs.

Integrating CloudWatch for logging enhances monitoring and troubleshooting capabilities, offering comprehensive insights into application performance. This approach—combining ECS, Terraform, Docker, and CloudWatch—provides a streamlined and efficient way to manage modern applications, reinforcing best practices in DevOps and cloud-native architectures.

Tired of building CRUD Apps?. Here's a way to make you stand out in the job market

GaneshMani — Fri, 26 Mar 2021 07:35:57 +0000

A question that most of us have in our minds is, "I know how to create a CRUD App with X/Y technology, now what?. How can I make myself stand out in this competitive job market? "

Well, I had this question too in my mind and kept asking other developers and mentors. Honestly, I couldn't find a proper answer from anywhere.

After so many experiments, I found a way that actually worked for me to get job opportunities. I am going to show you the way that can help you to stand out in the job market. Because, after applying this technique, I saw some good results for my actions.

Doing CRUD Apps are not bad

I am not saying that practicing CRUD Applications are bad. It's actually a good way to start learning a programming language or technology. I recommend you to start with that.

But once, you learn how to do it with a particular language or technology. Don't repeat yourself doing CRUD Applications again and again.

Try to spend less time learning a programming language by doing CRUD. Once you feel you're comfortable, start to move on.

What next?

Once you become an experienced developer or intermediate on web/mobile development. People/companies will start to expect more from you than just doing CRUD kind of applications. Let me clarify one thing about development.

As a developer, our responsibility is not just about building features and deploying them to server. It involves understanding the requirement and thinking about an effective solution for the problem statement and then finally implementing them as a feature or product.

People value this skill more than just knowing how to implement a CRUD or any technical specification.

When i realized this, i started thinking about how to improve/ practice this skill.

War field ≠ Practice field

This is such a strong statement. For example, If a guy practices GoLang for 6 months on his personal projects, it is not equal to a guy working on GoLang for production applications or a company. A practice field will never be a war field

So, I started building products rather than building a Facebook Clone, Netflix Clone, and any product clone just for the sake of portfolio.

Finding Product Ideas, The Secret Recipe

I have seen many people stuck in this phase. It becomes a never-ending loop for them, including me. I overcome this stage by start building asap.

Firstly, write down the problems that you have in your daily life. it can be from,

Automating boring tasks in your day job.
Some repetitive tasks in your hobby.
Your freelancing client's repetitive requirement.

Here's an interesting article that explains finding ideas. If you think that finding an idea is difficult for you. I recommend you to check this newsletter

I did the same process and came up with a problem statement that I was facing for a long time. It's about blogging and sharing them across social platforms. It was a manual process and time-consuming. I wanted to spend more time on producing high quality content rather than marketing them.

When I researched about it, I couldn't find an affordable product offering a solution. So, I decided to build. You can follow the same way and try to find a problem statement that you actually face on a daily basis.

Once you define the problem statement. It is important to define a scope and deadline for it. Try to make it a 1-month roadmap to develop a complete application. It's good to make it short rather than taking it too long to build it.(it can be a MVP or initial version of the product).

Launch and Market it

Once you build the product and its features. it is important to launch it and market it. Marketing is an essential step in this process.

Here's the product that I built like that,

Once I built it, I launched it on ProductHunt, and it went viral and became #2 Product of the Day.

You might be thinking ,"why I am asking you to build a complete product just to stand out in the job market or to get job opportunities".

Honestly, I never thought that building a product like this and market it brings job opportunities. But, it brings me a lot of job opportunities. Many startup founders, Company's HR professional in a similar domain contacted me to ask if I am looking for a job opportunity.

Building products like this will actually prove that you can build and ship a product in confidence. More than that, it proves that you can understand problem statements well and ship them as features.

I hope this article helps you to find a way to stand out in the job market. If you would like to read more articles, consider subscribing to the newsletter. we will send interesting reads and articles right to your inbox

Modern React Redux Toolkit - Login & User Registration Tutorial and Example

GaneshMani — Wed, 10 Feb 2021 12:37:30 +0000

User Authentication is one of the common workflow in web applications. In this tutorial, we will see how to build a User Login and Signup workflow with Modern react redux toolkit.

Demo

Let's scaffold an application using the command,

npx create-react-app redux-workflow --template redux

If you're completely new to redux-toolkit, checkout this article to learn the basic concepts of redux toolkit.

Let me give you a glimpse about the concepts of redux toolkit. Everything in toolkit is grouped as Features. it's called duck pattern.

Action and Reducers are combined in redux toolkit as Slice. To make HTTP API call, we will be using createAsyncThunk. We will discuss about it in detail in the later part of the article.

Create App.js

import React from 'react';
import './App.css';
import { BrowserRouter as Router, Switch, Route, Link } from 'react-router-dom';
import Login from './features/User/Login';
import Signup from './features/User/Signup';
import Dashboard from './features/User/Dashboard';
import { PrivateRoute } from './helpers/PrivateRoute';

function App() {
  return (
    <div className="App">
      <Router>
        <Switch>
          <Route exact component={Login} path="/login" />
          <Route exact component={Signup} path="/signup" />
          <PrivateRoute exact component={Dashboard} path="/" />
        </Switch>
      </Router>
    </div>
  );
}

export default App;

Before creating components for the workflow. let's create redux slice for our User section. create UserSlice.js inside features/User directory,

import { createSlice, createAsyncThunk } from '@reduxjs/toolkit';

export const userSlice = createSlice({
  name: 'user',
  initialState: {
    username: '',
    email: '',
    isFetching: false,
    isSuccess: false,
    isError: false,
    errorMessage: '',
  },
  reducers: {
      // Reducer comes here
  },
  extraReducers: {
       // Extra reducer comes here
  },
});

export const userSelector = (state) => state.user;

Here, we use createSlice which handles the action and reducer in a single function. After that, add the reducer in redux store

app/store.js

import { configureStore } from '@reduxjs/toolkit';
import { userSlice } from '../features/User/UserSlice';
export default configureStore({
  reducer: {
    user: userSlice.reducer,
  },
});

Signup Functionality

Once we create a basic structure for redux and store. it's time to create components for the application. Create Signup.js inside features/User directory,

import React, { Fragment, useEffect } from 'react';
import { Link } from 'react-router-dom';
import { useForm } from 'react-hook-form';
import { useSelector, useDispatch } from 'react-redux';
import { signupUser, userSelector, clearState } from './UserSlice';
import { useHistory } from 'react-router-dom';
import toast from 'react-hot-toast';

const Signup = () => {
  const dispatch = useDispatch();
  const { register, errors, handleSubmit } = useForm();
  const history = useHistory();

  const { isFetching, isSuccess, isError, errorMessage } = useSelector(
    userSelector
  );
  const onSubmit = (data) => {
    dispatch(signupUser(data));
  };

  useEffect(() => {
    return () => {
      dispatch(clearState());
    };
  }, []);

  useEffect(() => {
    if (isSuccess) {
      dispatch(clearState());
      history.push('/');
    }

    if (isError) {
      toast.error(errorMessage);
      dispatch(clearState());
    }
  }, [isSuccess, isError]);

  return (
    <Fragment>
      <div className="min-h-screen bg-gray-50 flex flex-col justify-center py-12 sm:px-6 lg:px-8">
        <div class="sm:mx-auto sm:w-full sm:max-w-md">
          <h2 class="mt-6 text-center text-3xl font-extrabold text-gray-900">
            Sign Up to your account
          </h2>
        </div>
        <div className="mt-8 sm:mx-auto sm:w-full sm:max-w-md">
          <div className="bg-white py-8 px-4 shadow sm:rounded-lg sm:px-10">
            <form
              className="space-y-6"
              onSubmit={handleSubmit(onSubmit)}
              method="POST"
            >
             {*/ Form Comes Here  */}
            </form>
            <div class="mt-6">
              <div class="relative">
                <div class="relative flex justify-center text-sm">
                  <span class="px-2 bg-white text-gray-500">
                    Or <Link to="login"> Login</Link>
                  </span>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </Fragment>
  );
};

export default Signup;

Here, we use React Hook Form to handle Form validation. Whenever we want to dispatch an action in redux, we use useDispatch provided by react-redux.

 const dispatch = useDispatch();

We can access redux state in component using hooks, useSelector

const { isFetching, isSuccess, isError, errorMessage } = useSelector(
    userSelector
  );

Now, when an user submits a signup form, we need to dispatch an action by passing required data.

const onSubmit = (data) => {
    dispatch(signupUser(data));
  };

Let's create that action in UserSlice.js

export const signupUser = createAsyncThunk(
  'users/signupUser',
  async ({ name, email, password }, thunkAPI) => {
    try {
      const response = await fetch(
        'https://mock-user-auth-server.herokuapp.com/api/v1/users',
        {
          method: 'POST',
          headers: {
            Accept: 'application/json',
            'Content-Type': 'application/json',
          },
          body: JSON.stringify({
            name,
            email,
            password,
          }),
        }
      );
      let data = await response.json();
      console.log('data', data);

      if (response.status === 200) {
        localStorage.setItem('token', data.token);
        return { ...data, username: name, email: email };
      } else {
        return thunkAPI.rejectWithValue(data);
      }
    } catch (e) {
      console.log('Error', e.response.data);
      return thunkAPI.rejectWithValue(e.response.data);
    }
  }
);

Main purpose of using createAsyncThunk is it provides the API state out of the box. In traditional redux way, we need to handle the api state such as loading, success and failed.

createAsyncThunk provides us those states out of the box. To implement it, we just need to use the action name and the state of it.

Image Source

createAsyncThunk takes two argument,

Name that helps to identify action types.
A callback function that should return a promise

Further, callback function take two arguments. first, is the value that we pass from dispatched action and second argument is Thunk API config.

Once it returns a promise, either it will resolve or reject the promise. By default it provides us three state which are pending, fulfilled and rejected.

extraReducers: {
[signupUser.fulfilled]: (state, { payload }) => {
      state.isFetching = false;
      state.isSuccess = true;
      state.email = payload.user.email;
      state.username = payload.user.name;
    },
    [signupUser.pending]: (state) => {
      state.isFetching = true;
    },
    [signupUser.rejected]: (state, { payload }) => {
      state.isFetching = false;
      state.isError = true;
      state.errorMessage = payload.message;
    }
}

It updates the redux state which will update our component using hook useSelector. Once the signup successfully, it redirects to dashboard component.

useEffect(() => {
    if (isSuccess) {
      dispatch(clearState());
      history.push('/');
    }

    if (isError) {
      toast.error(errorMessage);
      dispatch(clearState());
    }
  }, [isSuccess, isError]);

Login Functionality

Most of the logic will be similar to login workflow. create Login.js inside features/User directory and add the following code,

import React, { Fragment, useEffect } from 'react';
import { Link } from 'react-router-dom';
import { useForm } from 'react-hook-form';
import { useSelector, useDispatch } from 'react-redux';
import { loginUser, userSelector, clearState } from './UserSlice';
import toast from 'react-hot-toast';
import { useHistory } from 'react-router-dom';

const Login = ({}) => {
  const dispatch = useDispatch();
  const history = useHistory();
  const { register, errors, handleSubmit } = useForm();
  const { isFetching, isSuccess, isError, errorMessage } = useSelector(
    userSelector
  );
  const onSubmit = (data) => {
    dispatch(loginUser(data));
  };

  useEffect(() => {
    return () => {
      dispatch(clearState());
    };
  }, []);

  useEffect(() => {
    if (isError) {
      toast.error(errorMessage);
      dispatch(clearState());
    }

    if (isSuccess) {
      dispatch(clearState());
      history.push('/');
    }
  }, [isError, isSuccess]);

  return (
    <Fragment>
      <div className="min-h-screen bg-gray-50 flex flex-col justify-center py-12 sm:px-6 lg:px-8">
        <div class="sm:mx-auto sm:w-full sm:max-w-md">
          <h2 class="mt-6 text-center text-3xl font-extrabold text-gray-900">
            Sign in to your account
          </h2>
        </div>
        <div className="mt-8 sm:mx-auto sm:w-full sm:max-w-md">
          <div className="bg-white py-8 px-4 shadow sm:rounded-lg sm:px-10">
            <form
              className="space-y-6"
              onSubmit={handleSubmit(onSubmit)}
              method="POST"
            >
             {*/ Login Form Comes Here */}
            </form>
            <div class="mt-6">
              <div class="relative">
                <div class="relative flex justify-center text-sm">
                  <span class="px-2 bg-white text-gray-500">
                    Or <Link to="signup"> Signup</Link>
                  </span>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </Fragment>
  );
};

export default Login;

Here, we dispatch loginUser action which makes HTTP call in the redux slice.

const onSubmit = (data) => {
    dispatch(loginUser(data));
  };

create an AsyncThunk function inside UserSlice.js and add the following code,

export const loginUser = createAsyncThunk(
  'users/login',
  async ({ email, password }, thunkAPI) => {
    try {
      const response = await fetch(
        'https://mock-user-auth-server.herokuapp.com/api/v1/auth',
        {
          method: 'POST',
          headers: {
            Accept: 'application/json',
            'Content-Type': 'application/json',
          },
          body: JSON.stringify({
            email,
            password,
          }),
        }
      );
      let data = await response.json();
      console.log('response', data);
      if (response.status === 200) {
        localStorage.setItem('token', data.token);
        return data;
      } else {
        return thunkAPI.rejectWithValue(data);
      }
    } catch (e) {
      console.log('Error', e.response.data);
      thunkAPI.rejectWithValue(e.response.data);
    }
  }
);

Promise will either be resolved or rejected based on HTTP call, let's handle it inside our reducer with the states,

[loginUser.fulfilled]: (state, { payload }) => {
      state.email = payload.email;
      state.username = payload.name;
      state.isFetching = false;
      state.isSuccess = true;
      return state;
    },
    [loginUser.rejected]: (state, { payload }) => {
      console.log('payload', payload);
      state.isFetching = false;
      state.isError = true;
      state.errorMessage = payload.message;
    },
    [loginUser.pending]: (state) => {
      state.isFetching = true;
    },

Once it updates our redux state, we will use it inside our component to render the result.

const { isFetching, isSuccess, isError, errorMessage } = useSelector(
    userSelector
  );

// Update UI based on the redux state(Success or Error)
useEffect(() => {
    if (isError) {
      toast.error(errorMessage);
      dispatch(clearState());
    }

    if (isSuccess) {
      dispatch(clearState());
      history.push('/');
    }
  }, [isError, isSuccess]);

Finally our Dashboard.js will be rendered with update user state from redux,

import React, { Fragment, useEffect } from 'react';
import { useSelector, useDispatch } from 'react-redux';
import { userSelector, fetchUserBytoken, clearState } from './UserSlice';
import Loader from 'react-loader-spinner';
import { useHistory } from 'react-router-dom';

const Dashboard = () => {
  const history = useHistory();

  const dispatch = useDispatch();
  const { isFetching, isError } = useSelector(userSelector);
  useEffect(() => {
    dispatch(fetchUserBytoken({ token: localStorage.getItem('token') }));
  }, []);

  const { username, email } = useSelector(userSelector);

  useEffect(() => {
    if (isError) {
      dispatch(clearState());
      history.push('/login');
    }
  }, [isError]);

  const onLogOut = () => {
    localStorage.removeItem('token');

    history.push('/login');
  };

  return (
    <div className="container mx-auto">
      {isFetching ? (
        <Loader type="Puff" color="#00BFFF" height={100} width={100} />
      ) : (
        <Fragment>
          <div className="container mx-auto">
            Welcome back <h3>{username}</h3>
          </div>

          <button
            onClick={onLogOut}
            className="bg-red-500 hover:bg-red-700 text-white font-bold py-2 px-4 rounded"
          >
            Log Out
          </button>
        </Fragment>
      )}
    </div>
  );
};

export default Dashboard;

Complete source code is available here

Building Nodejs Microservice - A Cloud-Native Approach - Part 1

GaneshMani — Tue, 19 Jan 2021 12:45:56 +0000

If you're reading this article, I assume that you know how to build an Application using Nodejs. few may know how to build the frontend as well.

Well, I have a task for you before getting into this article. Build me a Project Management Application using Nodejs.

if you implement something like this,

Then, you are not probably in 2021. Don't get me wrong. there is nothing wrong with above approach. i still works well for lot of application requirements.

But, let me tell you how it's going to make difference in application development. Let's say that you implement your project using Monolith Architecture and your application starts to evolve, continous iteration and building features on top of it.

At some point of it, you will start to feel uncomfortable and your code become unmaintainable. it makes the application overly complicated and other developers fears to build features or maintain it.

Here are the side effects of it,

Application gets overly complicated and hard to maintain
Adaptation for new technology will not be an option.
Implementing a new feature become a time consuming process etc.

That's when the Microservices comes into picture,

Let's implement the sample application architecture in microservice way,

Now, the application modules are decomposed into isolates microservices. each services will be independent with it's own code and dependancy.

So far, we have seen the difference between Monolith and Microservices. If you watch it carefully, i introduced an another term called Cloud Native Approach .

Well, let's see what does it mean by that,

What is a Cloud-Native Application?

Cloud-Native is a modern way to build a Large scale system. it is a systematic approach to build a large system that can change rapidly with zero downtime and resilient at the same time.

There are a lot of open source applications that evolved over time to make it possible. tools such as Docker, Kubernetes, Helm , Prometheus and gRPC helps us to build such applications.

If somebody asks you, what does it mean by Cloud Native Application Development ?. just tell them that,

Cloud native application development is an approach to building and deploying applications quickly, while improving the quality and reducing risk.it is just a way to build scalable, resilient and fault-tolerant applications with zero down-time in deployment.

To learn more about Cloud-native Application, check this awesome docs from Microsoft

Cloud-based approach follow 12 factor methodology which describes set of principle and best practices that we need to follow while building a cloud-native application.

Here we are going to implement two simple micro-services which are project and task services. it will be a simple Express application.

The main purpose of this article is to make you understand how to build a Microservices in cloud-native approach. we will not be focusing on the business logic of each microservices.

Once you understand the outer layer. you can easily build your own business logic inside each service.

Note: I assume that you have basic knowledge on Docker and Kubernetes. if you are new to those topics. i suggest you to check these articles

Enough of the theory. let's implement a Nodejs Microservices and see it in action

Project Service

Create a simple Express Application with the basic boilerplate code.

const express = require("express");

const bodyParser = require("body-parser");

app.use(bodyParser.json());

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

app.get("/project", (req, res) => {

 res.send("Welcome to ProjectService");

 console.log("Listening on PORT 4500");

Now, let's dockerize our Nodejs Application. create a Dockerfile inside your project service directory.

Don't forgot to add .dockerignore inside your root directory

Task Service

Do the same for Task service,

Create a Simple Express Application
Dockerize your task service
add .dockerginore inside your task service

const express = require("express");

const bodyParser = require("body-parser");

app.use(bodyParser.json());

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

app.get("/task", (req, res) => {

 res.send("Welcome to TaskService");

 console.log("Listening on PORT 4501");

Once you complete the docker configuration. you can build docker images using the command,

Now, we have our containerized microservices. if you run the docker container, each containers will be running in a separate ports.

But wait, we want our application to run in a single port. right?

To achieve this, we need kubernetes. Kubernetes is a orchestration tool that helps us to manage our docker containers and load balance between them etc.

Infrastructure

Here, we want to route our the request to appropriate docker containers. let's implement kubernetes on top of our Nodejs Microservices.

Note: If you're new to Kubernetes, i recommend you to check this article to understand the basics of kubernetes

To explain it simpler, Kubernetes requires Service and Deployment to manage the pods inside Nodes.

Let's create Service and Deployment config for each micro-services,

 image: ganeshmani009/projectservice

 name: project-srv-clusterip

Let's break down Deoployment config to understand it better,

 image: ganeshmani009/projectservice

metadata name specifies the name of deployment.

matchLabels creates Pod with the specified name here. After that we create Pod with template

 image: ganeshmani009/projectservice

### Kubernetes Services

 name: project-srv-clusterip

Here, we specify the kind as Service, then metadata name as project-srv-clusterip.

selector specifies which pod that needs to be mapped with Service. here, it's mentioned as projects.

port specifies the incoming port on the request. targetPort specifies the port to which the request needs to be forwarded to.

### Task Service Infrastructure

 image: ganeshmani009/taskservice

 name: task-clusterip-srv

To run the kubernetes cluster, we can use the command kubectl apply -f

One final thing that we need to set in kubernetes configuration is a controller to handle the request from outside world to kubernetes clusters. because, we can't access the kuberetes clusters directly.

To do that, we need ingress control to access the clusters. let's set ingress controller,

create ingress-srv.yml inside the infra directory and add the following config,

apiVersion: networking.k8s.io/v1beta1

 kubernetes.io/ingress.class: nginx

 serviceName: project-srv-clusterip

 serviceName: task-clusterip-srv

Here, we use nginx as ingress controller. there are other controller that you can use in our kubernetes applications.

apiVersion: networking.k8s.io/v1beta1

 kubernetes.io/ingress.class: nginx

On the above code, we specify apiVersion and king of configuration. then, we set some meta-data. important thing to note here is the annotation which is nginx here. if we want any other controller, our configuration will change based on that.

 serviceName: project-srv-clusterip

 serviceName: task-clusterip-srv

After that, we have rules which specifies host and http paths mainly. host is your application DNS. here, we specify our local server domain set in [hosts](https://setapp.com/how-to/edit-mac-hosts-file) config file.

Two important things to note here is,

path : it specifies the path that we want to access our particular microservices. let's say that we want to access our Project Microservice in route /project-api we need to specify it in the path.
backend : it specifies the kubernetes cluster that we want to access in the specified route.

Now, to run the ingress controller. we need to use the following command,

Finally, That complete our Microservice Configuration and setup.

Let's access our microservice application routes in the browser and see whether it works or not,

It works as we expected. Now, we can build many microservices by following the same process and implement our business logics inside the microservices.

complete source can be found here

I built a tool to Crosspost my blog to Dev.to, Medium, LinkedIn and Twitter in one click

GaneshMani — Fri, 08 Jan 2021 11:15:27 +0000

This blog is about how I built a Micro-SaaS product for the problem statement that I have been facing for quite some time.

Before getting into the explanation about the tool and the intention behind it. let me give you a quick into about myself. I am a developer who is interested in blogging and sharing my technical knowledge with the community.

I started blogging when dev.to becoming popular and a lot of developers were inspired to write at least one article a week on dev.to platforms. I am one of them. I started writing on dev.to consistently. Every week, I publish at least one article.

As a result,

Everything started with dev.to and being consistent about publishing a blog per week on this platform. It gave me a lot of opportunities such as paid writing gigs, job opportunities, and meetup talks.

My workflow at that time was, I write an article on my personal site and Crosspost it to Medium, dev.to with the content(by providing canonical URL to avoid duplicate content). Then, share the blog URL across Twitter, Facebook Groups, and Reddit. It gave me a good amount of traction and visitors.

Over a while, I find myself repeating the same task of Crossposting the content again and again to several social platforms and it was a time-consuming process.

Even though it was giving me more traction and audience engagement. I was spending more time on marketing and distributing my content than writing quality articles. As a developer, i wanted to avoid this repetitive work and automate this process.

That's how my product https://crossxpost.app/ came into the picture. i wanted a simple solution where a blogger/any content creators can share their content to social platforms from one place in one click.

If you've been facing this problem or have any feedback improve the product. feel free to reach out to me.

https://twitter.com/ganeshmani009

Checkout the Product https://crossxpost.app/

Everything you need to know about docker volumes - Docker tips and tricks

GaneshMani — Sat, 12 Dec 2020 12:46:55 +0000

Consider a scenario where you develop a Nodejs Application with MongoDB as a database. your application stores the data in MongoDB and everything goes well.

After some point of time, you want to automate the process of deployment. so, everytime Pull request is merged into master branch. you want to create a new docker container to serve your application.

One of the main challenges that you face here is, everytime you delete an existing container. your mongodb data will also be deleted. it will be a problem while using a docker.

To overcome this problem, we need to use Docker Volumes. Let's learn everything about docker volumes in this guide.

What is Docker volume

Docker volume is a persistent data storage mechanism to store the data in docker. before volumes, docker uses bind mounts to store data in the container. bind mounts are dependent on the directory structure of host machine.

Let's look at this in detail to understand it further. As you know, docker runs a isolated containers with separate process that shares the file system and hardware from the host machine . Whenever you create a container, it mounts a directory with the container to run our application.

File system managed by container can not be shared with other containers. To create a directory managed by container. we use bind mounts.

problem with bind mounts is, it is not persistent. once we remove the container, docker deleted the respective file directory of the respective container.

To solve this, we use docker volumes, one of the main differences are docker manages volume directly. In that way, even if you delete the container. data will be persistent.

Getting started with docker volume

Create a Volume

To create a volume in docker, use the command,

1docker volume create

Note: warning will not occur for your docker configuration.

List Volume

Once you create a volume, you can list all the docker volume using the command,

Remove a volume

To remove a volume from docker, you can use the follow command,

Remove all unused volume

you can also remove all unused volume from docker using the command,

docker volume - example

Let's take an example to learn about docker volumes. here, we will take a two nodejs application which shares a same docker volume. both will contains API to write and read a file. let's see if docker volume can be shared between two container.

At the end of this guide, i have a real world example as an exercise for you. so, stay tuned

let's build this application and use docker volume to store the data. create a application with npm init and add app.js

1const express = require("express")

2const bodyParser = require("body-parser")

3const path = require("path")

7app.use(bodyParser.json())

8app.use(bodyParser.urlencoded({ extended: false }))

10const dataPath = path.join(process.env.DATA_PATH || "./data.txt")

12app.get("/", (req, res) => {

13 res.send("Welcome To docker volume")

16app.get("/data", (req, res) => {

17 let data = fs.readFileSync(dataPath)

19 res.status(200).send(data)

22app.post("/add", (req, res) => {

23 const data = req.body.text

24 fs.writeFileSync(dataPath, data)

26 res.status(201).send({ success: true })

31 console.log(Server is running on PORT ${3001}\)

Here, we add two API's add and data where add writes the request data to file. and data GET API returns the data.

let's create a Dockerfile for our application.

If you're beginner to docker world, i recommend you to checkout this article

After that, you need to build docker image for our application to run it in container.

1docker build -t .

once you build docker image for our app. you need to run it in the container. here's where you need to mount docket volume for your application container.

Mounting a docker volume

To mount a docker volume with container, you need to add the --mount flag in docker run command.

1docker run --mount source=[volume_name],destination=[path_in_container] [docker_image]

source specifies the name of the volume and destination specifies the path in container.

For the above application, you need to specified it as,

1docker run -d --env DATA_PATH=/data/data.txt --mount type=volume,src=file-st,target=/data -p 3001:3001

it will mount the volume with specified container path. now, anything you write and read will be from the docker volume.

Let's create an another application which shares the same docker volume to check whether it is working. you can use the same setup by changing the port in the application and docker container.

2 console.log(Server is running on PORT ${3002}\)

docker run command will be

1docker run -d --env DATA_PATH=/data/data.txt --mount type=volume,src=file-st,target=/data -p 3002:3002 ganeshmani009/volume-app-two:latest

Now, that we have a two application running with shared docker volume. let's try to write a file and see if it gets reflected in the another application.

Alright. our applications works the way we expected. now, it's time to do our exercise with a real world example.

Real world Example

Here's the task that you need to do,

Create a Simple Todo Nodejs Application with MongoDB connection to store the data.
Pesist the Mongodb Data with Docker volume.
Create an another Nodejs Application to read the Todo from MongoDB and show it as logs.

Conclusion

i recommend you to try this real world scenario to get hands-on experience on the docker volumes. having a knowledge on docker as a web developer become vital in the current software development world. Happy coding :-)

Want to stand out from the Crowd?

Don't get stuck in the tutorial loop. Learn React.js and Nodejs by practicing real world scenarios and get a job like a boss. Subscribe and get the real world problem scenarios in your inbox for free

No spam, ever. Unsubscribe anytime.

I Accidentally wiped the entire dataset in the Production database. Here's what happened next

GaneshMani — Tue, 17 Nov 2020 18:33:02 +0000

One of the tragic accident in my job turned out to be good learning for me in recent days. Yes, I accidentally wiped the entire dataset in the production database.

Before, getting into the details of it. let me tell you a bit about myself, I am a Full Stack Engineer specialized in React, Nodejs. I am working in a startup where we use Nodejs, Postgres in production.

Recently, i was working in an API which updates the database table. table has structure like this

module.exports = (sequelize, Sequelize) => {
    const User = sequelize.define("user", {
      name: {
        type: Sequelize.STRING
      },
      email: {
        type: Sequelize.STRING
      },
      data : Sequelize.JSON,
    });

    return User;
  };

an important thing to note here is the data that is in the JSON structure. API that I built should update the data object in the table.

To give you an example, Here's the structure of data on GET request

it contains the data in JSON structure which has fields such as phone, address, country, and postal code.

So, I need to write an API to change the phone number inside of the data. I thought it's kind of easy one to do and did that in a few steps.

app.post('/phone-number/update/:id',async (req,res) => {
    try {
        const id = req.params.id;
        const phonenumber = req.body.phonenumber

        const user = await User.update({ "data.phone" : phonenumber  },{
            where : {
                id
            }
        })

        res.status(200).json(user)
    }
    catch(e){
        res.status(500).json(null)
    }   
})

it updates the phone number inside of the data object. everything looks good so far. After that, I wrote a test-case to cover the scenario where the updated phone number is stored in the DB and it passed.

Everything looks good so far. So, it went to production. i didn't realize the disaster that is going to happen on production. i was in my home like,

Here's what happened in production, the API entirely wiped the JSON data replacing them with just phone number. i was shocked to see this,

To give you an example, Here's the data before and after the API

After the API update,

Then, i realized that postgres update on JSON shouldn't work like this. Luckily, our database took a backup exactly before this came up. so, i just rolled back the database data and commented out the functionality in this API.

but, my CTO noted this issue and helped me to resolve this one. In the meantime, I found an another way to fix the API functionality. it will be something like,

app.post('/phone-number/update/:id',async (req,res) => {
    try {
        const id = req.params.id;
        const phonenumber = req.body.phonenumber

        let user = await User.findOne({ id })

        user.data = { ...user.data,phone : phonenumber }
        await user.save()

        res.status(200).json(user)
    }
    catch(e){
        res.status(500).json(null)
    }   
})

I know it doesn't look like an effective solution. but at that moment, I wanted a working solution that should be deployed. I quickly wrote test-cases to cover the scenario and raised a PR. CTO personally looked into this code and reviewed it and gave some feedback. finally, the patch was merged into production that day.

it may look like a small & silly issue. but, it has the potential to wipe out the entire dataset. Instead of worrying about this incident. I took it as good learning for me. they are,

Even if we write test cases to cover the situation. it's always one step better if we can manually test the situation.
Never get stressed if your code broke the production server. I know it shouldn't happen. In some worst cases, it will. So, take it as a learning curve and avoid that mistake in the future.
Things like this will happen, At that moment, Having a supporting colleague or seniors will help a lot. That comes along in our careers.

I hope you learned something from this real-world experience. I wanted to share my experience so that you can get that experience without you need to undergo the same situation. we will see in another real-time experience. until then, Happy Coding :-)

List of Docker Container Commands you should know - Docker tips and tricks

GaneshMani — Wed, 11 Nov 2020 14:18:55 +0000

List of Docker Container Commands you should know - Docker tips and tricks

This article covers list of commands that you should know to manage docker containers in your local machine or server. some of the important commands are docker list containers, start a container and stop container from docker.

What is Docker Container

Docker container is an isolated packages of software that you can use to run your application, code or any infrastructure. basically, it helps to manage your application code without conflicting with your current machine/server setup.

Commands

There are few commands that you need to know to manage docker container. let's start with basic commands.

Start/Stop Container

To start/stop a docker container, you can do that using the command,

docker container start [OPTIONS] <Container id>

Note: you can specify the name or you can just specify the first two digits of the container id.

docker stop container

To stop the container, you need to specify the stop in the docker container command.

docker container stop [OPTIONS] <Container id>

docker stop all container

To stop all the running container, you can use the command,

docker stop $(docker ps -a -q)

Remove all stopped containers

Once you stop all containers, you can remove it using the command,

docker container prune

Docker list containers

To list all the docker container, you can do that using the command,

docker container ls [OPTIONS]

you can add options such as

--all or -a it shows all the containers in the docker
--size or -s , displays the container along with size
--latest or -l shows latest container first
--last or -n it shows the lastly created containers

Kill Container

To kill a docker container, you can use the command

docker container kill [OPTIONS] <Container ID>

there is a difference between docker stop and docker kill container commands. docker stop will send a signal SIGTERM and then after some grace period it sends the signal SIGKILL to stop the containers whereas in docker kill command, it sends the SIGKILL command directly.

you need to be careful with docker kill command, my personal suggestion would be to use docker stop command. to explain it a simple way, difference is like shutting down your computer vs forcefully removing the plug from socket to turn off the machine.

Conclusion

So far, we have seen the important command that you need to know for docker containers. try to use the above commands and play with it to get hands-on experience. if you feel like any important commands are missing, let me know in the comments below. Happy Coding 🙂

Checkout more blog like this here https://cloudnweb.dev/

React semantic UI tutorial for beginners

GaneshMani — Fri, 18 Sep 2020 07:27:43 +0000

Semantic UI is a framework to develop responsive applications. In this tutorial, we are going to see how to build a react application with react semantic UI library.

Install and Setup

we will be using react semantic ui library for our application which a wrapper of semantic ui to use in react applications. we will create our react application using create-react-app

npx creat-react-app react-semantic-recipe

Let's install semantic ui in our application

npm install semantic-ui-react semantic-ui-css

Once, you install the package. import the css of semantic ui in your index.js

import "semantic-ui-css/semantic.min.css"

Now, you can use semantic ui in your react components.

Building semantic ui react application

To learn how to build a react application with semantic ui. we will build a recipe application using MealDB API

reactjs semantic ui wireframe

Functionalities

User can search a Meal from the selected category
User can change the meal category and it will show the meal based on the category
User can click and read more information about a particular meal recipe.

Demo

Now, let's see how to build an application like this in this tutorial using reactjs semantic ui.

Firstly, let's split the wireframe into react components and implement them in our application.

On the left side screen, we have search and filter functionality. then, we have Meal cards which displays thumbnail and meal details.

the components would be Card,Input and Dropdown components.

Add the following code in App.js

import React, { useState, useEffect, Fragment } from "react"
import "./App.css"
import {
  Container,
  Input,
  Button,
  Dropdown,
  Loader,
  Dimmer,
  Card,
} from "semantic-ui-react"

import { useQuery } from "react-query"

function App() {
  const [currentCategory, setCurrentCategory] = useState(0)
  const [selectedMealId, setSelectedMealId] = useState(null)

  const { isLoading, error, data: categories } = useQuery(
    "categories",
    async () => {
      let result = await fetch(
        "https://www.themealdb.com/api/json/v1/1/categories.php"
      ).then(res => res.json())
      result = result.categories.map(item => {
        return {
          key: item.idCategory,
          text: item.strCategory,
          value: item.idCategory,
          image: item.strCategoryThumb,
        }
      })
      return result
    }
  )

  const { data: meals } = useQuery(
    ["meals", currentCategory, categories],
    async (key, currentCategory, data) => {
      let result = await fetch(
        `https://www.themealdb.com/api/json/v1/1/filter.php?c=${data[currentCategory].text}`
      ).then(res => res.json())

      return result.meals
    },
    {
      enabled: categories,
    }
  )

  if (isLoading)
    return (
      <Dimmer active inverted>
        <Loader inverted content="Loading" />
      </Dimmer>
    )
  return (
    <Container className="container" textAlign="center">
      // Container Logic comes Here
    </Container>
  )
}

export default App

Here, we have the semantic ui Container which sets the responsive width for the component.

secondly, we fetch the meals and categories data from the mealdb API. we are using react-query to fetch the data from API.

When fetching the data, we need to show loader inside our component. To do that, we will be using Loader from semantic ui.

if (isLoading)
  return (
    <Dimmer active inverted>
      <Loader inverted content="Loading" />
    </Dimmer>
  )

Then, we use the meal data to render it in the Card Components. categories data to render it inside DropDown.

Let's implement Search bar and Categories filter first.

<div className="row">
  <Input
    className="search-input"
    size="large"
    value={searchTerm}
    onChange={onSearchChange}
    placeholder="Search Meal"
  />
  <Button onClick={onSearch} secondary>
    Search
  </Button>
  <Dropdown
    className="drop-down"
    placeholder="Filter Category"
    fluid
    search
    selection
    value={categories[currentCategory].value}
    onChange={(e, { value }) => {
      setCurrentCategory(value[0] - 1)
    }}
    options={categories}
  />
</div>

react semantic ui input

Here, we use Input from semantic UI as a search input. we can add different props to change the behaviour of input.

focus - it adds the focus border around the input box
loading - it adds a loader inside of the input box
disabled - it disables the option to edit our input.
error - it shows the validation error inside of it.
icon - it adds icon inside the input box.

There are all the major props inside the semantic UI Input Components.

react semantic ui button

After that, we add button for search functionality. Let's see some of the important props in semantic ui to change the default button behaviour.

primary - changes the color of button to primary color.
secondary - it changes the color of button to secondary color.
active - it shows the button active state.
disabled - it shows the button disabled state.
loading - you can add loader inside the button which is a nice way to show the progress or API call fetch.

react semantic ui dropdown

Sematic UI adds lots of variation in the dropdown. few important one's are Searchable Dropdown, Multi Selection, clearable selection.

search - it makes the default dropdown searchable.
multiple - it makes the default dropdown a multiple selection one.
clearable - it makes it clearable dropdown.

Now, we have implemented top part of our application. it's time to implment the Card component and show the Meal inside of it.

create MealCard/index.js and add the following code to create semantic UI Card.

import React from "react"
import { Card, Image, Icon, Grid } from "semantic-ui-react"
const MealCard = ({ imageUrl, title, onClick }) => {
  return (
    <Card onClick={onClick}>
      <Image src={imageUrl} wrapped ui={false} />
      <Card.Content>
        <Card.Header>{title}</Card.Header>
      </Card.Content>
    </Card>
  )
}

export default MealCard

Here, we add the Card from semantic UI which takes Content,Header and body.Also, we use only Content and Header from the semantic UI Card.

Once you implement this component. we can use it inside App.js.

{
  meals &&
    meals.map(meal => {
      return (
        <MealCard
          title={meal.strMeal}
          onClick={() => {
            console.log("meal.idMeal", meal.idMeal)
            setSelectedMealId(meal.idMeal)
          }}
          imageUrl={meal.strMealThumb}
        />
      )
    })
}

we loop through meals from the API fetch data and render our MealCard inside it.

Now, that we have rendered our Meal inside the card. When user clicks the card, we need to show all the details about the Meal.

Let's implement the functionalities inside a component MealDetails/index.js inside out components directory.

import React from "react"
import { useQuery } from "react-query"
import {
  Container,
  Input,
  Button,
  Dropdown,
  Loader,
  Dimmer,
  Header,
  Grid,
} from "semantic-ui-react"
const MealDetails = ({ mealId, onBackButtonClick }) => {
  const { isLoading, error, data: meals } = useQuery(
    ["categories", mealId],
    async (key, mealId) => {
      console.log("mealId", mealId)
      let result = await fetch(
        `https://www.themealdb.com/api/json/v1/1/lookup.php?i=${mealId}`
      ).then(res => res.json())
      console.log("result", result)
      return result.meals
    }
  )

  if (isLoading)
    return (
      <Dimmer active inverted>
        <Loader inverted content="Loading" />
      </Dimmer>
    )

  if (meals) {
    console.log("meals", meals)
  }
  return (
    <Container>
      <Button secondary onClick={onBackButtonClick}>
        Back
      </Button>
      <h4>{meals[0].strMeal}</h4>

      <Grid divided="vertically">
        <Grid.Row columns={2}>
          <Grid.Column>
            <Header as="h3">Category:</Header>
          </Grid.Column>
          <Grid.Column>
            <p>{meals[0].strCategory}</p>
          </Grid.Column>
        </Grid.Row>
        <Grid.Row columns={2}>
          <Grid.Column>
            <Header as="h3">Instruction:</Header>
          </Grid.Column>
          <Grid.Column>
            <p>{meals[0].strInstructions}</p>
          </Grid.Column>
        </Grid.Row>
        <Grid.Row columns={2}>
          <Grid.Column>
            <Header as="h3">Source:</Header>
          </Grid.Column>
          <Grid.Column>
            <a href={meals[0].strSource}>Source</a>
          </Grid.Column>
        </Grid.Row>

        <Grid.Row columns={2}>
          <Grid.Column>
            <Header as="h3">Video:</Header>
          </Grid.Column>
          <Grid.Column>
            <a href={meals[0].strYoutube}>Video</a>
          </Grid.Column>
        </Grid.Row>
      </Grid>
    </Container>
  )
}

export default MealDetails

Here, we take two props which are mealId and back button click function as props.

based on the mealId, we need to show the details. we use Semantic UI Grid to show the data. if you see the wireframe, we have property name in the left side and value in the right side.

For example, Instruction key in the left side and value for that will be in the right side.

you can use Grid to achieve any kind of alignment in the web application.

react semantic ui grid

Concept of react semantic ui grid is simple. There are rows and columns. you just need to specify the number of columns inside the Row and add the component inside the Grid.Column

For example,

<Grid.Row columns={2}>
  <Grid.Column>
    <Header as="h3">Category:</Header>
  </Grid.Column>
  <Grid.Column>
    <p>{meals[0].strCategory}</p>
  </Grid.Column>
</Grid.Row>

Here we specify two columns and add our component Header inside the Grid.Column.

react semantic ui header is straight forward. so, i leave it upto you to implement it.

Now, we need to add the component inside our App.js.There are two ways to implement this functionality.

We can have a router, which routes to the meal details page based on the selected meal id. For example, it redirects to /meal/12 and we can get the id from there.
we can store the selected meal id in the state and use it to conditional render the Meal details component inside App.js.

In this application , we will be using second approach because, our application is small and simple. if you're building a larger application. first approach is more appropriate.

our final App.js would look like,

import React, { useState, useEffect, Fragment } from "react"
import "./App.css"
import {
  Container,
  Input,
  Button,
  Dropdown,
  Loader,
  Dimmer,
  Card,
} from "semantic-ui-react"

import { useQuery } from "react-query"

import MealCard from "./components/MealCard"
import MealDetails from "./components/MealDetails"

function App() {
  const [currentCategory, setCurrentCategory] = useState(0)
  const [selectedMealId, setSelectedMealId] = useState(null)
  const [searchTerm, setSearchTerm] = useState("")
  const [isSearch, setSearch] = useState(false)

  const { isLoading, error, data: categories } = useQuery(
    "categories",
    async () => {
      let result = await fetch(
        "https://www.themealdb.com/api/json/v1/1/categories.php"
      ).then(res => res.json())
      result = result.categories.map(item => {
        return {
          key: item.idCategory,
          text: item.strCategory,
          value: item.idCategory,
          image: item.strCategoryThumb,
        }
      })
      return result
    }
  )

  const { data: meals } = useQuery(
    ["meals", currentCategory, categories],
    async (key, currentCategory, data) => {
      let result = await fetch(
        `https://www.themealdb.com/api/json/v1/1/filter.php?c=${data[currentCategory].text}`
      ).then(res => res.json())

      return result.meals
    },
    {
      enabled: categories,
    }
  )

  const { data: searchResults } = useQuery(
    ["searchMeals", isSearch, searchTerm],
    async (key, isSearch, searchTerm) => {
      if (isSearch) {
        let result = await fetch(
          `https://www.themealdb.com/api/json/v1/1/search.php?s=${searchTerm}`
        ).then(res => res.json())
        console.log("result", result)
        return result.meals
      } else {
        return []
      }
    }
  )

  const onSearch = () => {
    setSearch(true)
  }

  const onSearchChange = e => {
    setSearchTerm(e.target.value)
  }

  if (isLoading)
    return (
      <Dimmer active inverted>
        <Loader inverted content="Loading" />
      </Dimmer>
    )
  return (
    <Container className="container" textAlign="center">
      {selectedMealId ? (
        <MealDetails
          mealId={selectedMealId}
          onBackButtonClick={() => setSelectedMealId(null)}
        />
      ) : (
        <Fragment>
          <div className="row">
            <Input
              className="search-input"
              size="large"
              value={searchTerm}
              onChange={onSearchChange}
              placeholder="Search Meal"
            />
            <Button onClick={onSearch} secondary>
              Search
            </Button>
            <Dropdown
              className="drop-down"
              placeholder="Filter Category"
              fluid
              search
              selection
              value={categories[currentCategory].value}
              onChange={(e, { value }) => {
                setCurrentCategory(value[0] - 1)
              }}
              options={categories}
            />
          </div>

          <Container className="container" textAlign="center">
            <Card.Group itemsPerRow={4}>
              {searchTerm && isSearch ? (
                searchResults &&
                searchResults.map(meal => {
                  return (
                    <MealCard
                      title={meal.strMeal}
                      onClick={() => {
                        console.log("meal.idMeal", meal.idMeal)
                        setSelectedMealId(meal.idMeal)
                      }}
                      imageUrl={meal.strMealThumb}
                    />
                  )
                })
              ) : (
                <Fragment>
                  {meals &&
                    meals.map(meal => {
                      return (
                        <MealCard
                          title={meal.strMeal}
                          onClick={() => {
                            console.log("meal.idMeal", meal.idMeal)
                            setSelectedMealId(meal.idMeal)
                          }}
                          imageUrl={meal.strMealThumb}
                        />
                      )
                    })}
                </Fragment>
              )}
            </Card.Group>
          </Container>
        </Fragment>
      )}
    </Container>
  )
}

export default App

Checkout the Source code here