DEV Community: Shubham_Baghel

7 System Design Concepts I Wish I Had Learned Earlier

Shubham_Baghel — Tue, 20 Oct 2026 14:19:28 +0000

When we start building backend applications, we usually focus on writing APIs, connecting databases, and making everything work.

And honestly, that's enough for many small applications.

But things start getting interesting when more users come in.

Suddenly, APIs become slow. The database gets overloaded. One service going down starts affecting other services. Sometimes the same request gets processed twice.

That's when we start thinking about system design.I've been exploring different architecture concepts, and I wanted to share some of the things I think every backend developer should understand.

Not with complicated definitions, but with examples we can relate to.

1. Load Balancer — What Happens When One Server Is Not Enough?

Imagine you open an online shopping website during a big sale.

Thousands of people are trying to use it at the same time.

If all requests go to one server, that server might struggle to handle the traffic.

One solution is to run multiple instances of the application and distribute requests between them.

That's basically what a load balancer does.

           Users
              |
              v
        Load Balancer
         /    |    \
        v     v     v
      API 1  API 2  API 3

Instead of depending on one server, we have multiple instances handling requests.

If one instance becomes unhealthy, the load balancer can stop sending traffic to it, assuming health checks and routing are configured correctly.

Of course, running three servers isn't automatically enough. We also need to think about the database, shared state, and other dependencies.

But the basic idea is simple: don't make one server do all the work when it doesn't have to.

2. API Gateway — One Door for Your Application

Let's say you're building an application with separate services for users, orders, payments, and notifications.

Without a common entry point, the frontend might need to know where each service lives and how to communicate with it.

An API gateway can simplify that.

          Frontend
              |
              v
          API Gateway
          /    |    \
         v     v     v
       Users  Orders Payments
       Service Service Service

The frontend sends a request to the gateway, and the gateway routes it to the appropriate service.

It can also help with authentication integration, rate limits, and other shared API concerns.

Think of it like the reception desk in an office. You don't need to know where everyone sits; you explain what you need, and the receptionist directs you to the right person.

One thing I've learned is that not every application needs an API gateway. For a small application, it might just add unnecessary complexity.

3. Message Queues — Why Make Users Wait for Everything?

Imagine a customer places an order.

Your application needs to save the order, send an email, update analytics, and notify another service.

Should the customer wait until every single task finishes?

Probably not.

Some work can happen in the background.

          Order Service
                |
                v
            Save Order
                |
                v
           Message Queue
            /        \
           v          v
      Email Worker  Analytics Worker

The order service can publish a message, and other components can process it separately.

Tools like Amazon SQS, RabbitMQ, and Kafka help with different kinds of messaging requirements.

The benefit is that the user doesn't need to wait for every background task to finish.

But there's a catch: messages can sometimes be delivered more than once, consumers can fail, and processing might be delayed.

That's why retries, error handling, and idempotency matter.

4. Caching — Do We Really Need to Query the Database Every Time?

Imagine your application displays a list of product categories.

Thousands of users request the same information every day, but the categories rarely change.

Does it make sense to query the database every time?

Sometimes, no.

We can keep frequently requested data in a cache, such as Redis, and return it without making another database query.

       API Request
            |
            v
        Redis Cache
         /       \
      Found     Not Found
        |           |
        v           v
     Return      Database
                  |
                  v
              Store in Cache

This can reduce database load and improve response times.

But caching isn't always straightforward.

What happens when the price of a product changes? What if the cache still contains the old price?

Now we have another problem to solve: keeping cached data reasonably up to date.

Caching can be very useful, but adding it without understanding the data and its update patterns can create confusing bugs.

5. Circuit Breaker — What If Another Service Stops Responding?

Imagine your order service depends on a payment service.

The payment service suddenly becomes slow.

Your order service keeps calling it, waiting for responses, and consuming resources.

Soon, your own service might start struggling too.

A circuit breaker helps limit this situation.

Think of an electrical circuit breaker at home. When something goes wrong, it interrupts the connection to prevent further problems.

In software, a circuit breaker generally has three states:

Closed: Requests are allowed through.
Open: Calls are blocked temporarily because the dependency has been failing.
Half-open: A few calls are allowed to check whether the dependency has recovered.

This doesn't fix the payment service. It helps stop that failure from causing even more trouble elsewhere.

We still need sensible timeouts, retry policies, monitoring, and proper handling of failed payments.

6. Database Replication vs Sharding — They're Not the Same Thing

As an application grows, the database can become a bottleneck.

Two terms that often come up in system design discussions are replication and sharding.

Replication means keeping copies of data on multiple database instances.

For example, a primary database might handle writes while replicas handle some read traffic.

Sharding means splitting data across multiple database partitions or servers.

Imagine a shopping application with millions of customers. Instead of storing every customer record on one database server, records can be distributed across multiple shards.

Here's the simple difference:

Replication gives you copies of data.
Sharding divides data across different places.

Both can help with particular scaling problems, but both add complexity.

Replicas can have delays before receiving new changes, and sharding introduces questions about how data should be distributed and queried.

So before reaching for either solution, I'd first want to understand what is actually causing the database problem.

7. Monitoring and Logs — How Do We Know What's Going Wrong?

Your application works perfectly on your laptop.

You deploy it to production, and suddenly a customer reports that placing an order takes 15 seconds.

Now what?

Is the API slow? Is the database struggling? Is another service timing out?

Without useful logs and metrics, debugging becomes guesswork.

This is why observability matters.

The three things I try to distinguish are:

Logs: What happened?
Metrics: How is the system performing?
Traces: Where did a request spend its time across different services?

Tools such as CloudWatch, Grafana, and OpenTelemetry can help collect and investigate this information.

The goal isn't to collect as much data as possible. It's to collect information that helps us understand what went wrong and where to look.

One Last Thing: Don't Overcomplicate Your Architecture

Something worth remembering is that we don't need all these components from day one.

A small application with a single backend and a database might be perfectly fine.

Adding Kafka, Redis, multiple microservices, and an API gateway just because they are popular can make the application harder to maintain.

I'd rather start with a simple design, understand where the real problems are, and introduce additional components when they solve a specific problem.

For me, that's the interesting part of system design: understanding the trade-offs, not just knowing the names of different technologies.

I'm curious to hear from other backend developers:

What's one system design problem you've faced in a real project, and how did you solve it?

TypeScript Tricks That Feel Like Cheating

Shubham_Baghel — Wed, 14 Oct 2026 16:35:00 +0000

TypeScript looks simple when you're writing basic types and interfaces.But once you start exploring its advanced features, you realize it can do much more than just check whether a variable is a string or a number.

Some TypeScript features can help you catch mistakes at compile time, build smarter APIs, and even calculate types based on other types.

Here are 8 TypeScript tricks that made me appreciate its type system a lot more.

1. Create Types From Existing Objects Using `typeof`

What if you could create a TypeScript type directly from a JavaScript object instead of maintaining both separately?

You can.

const config = {
  environment: "production",
  retries: 3,
  debug: false,
};

type Config = typeof config;

Now Config represents the structure inferred from config.

But there is an important detail: environment is inferred as string, not specifically "production".

If you want to preserve literal values, use as const:

const config = {
  environment: "production",
  retries: 3,
  debug: false,
} as const;

type Config = typeof config;

Now the properties have literal types, and they become readonly in the inferred type.

Why this is useful: Configuration objects, shared constants, and avoiding duplicate type definitions.

2. Turn an Array Into a Union Type

Imagine you have a list of supported payment methods.

You want the list to be the source of truth, rather than maintaining a separate union type.

const paymentMethods = [
  "card",
  "paypal",
  "bank-transfer",
] as const;

type PaymentMethod =
  (typeof paymentMethods)[number];

The resulting type is:

type PaymentMethod =
  "card" | "paypal" | "bank-transfer";

Let's break it down:

typeof paymentMethods gets the array's type.
[number] extracts the type of its elements.
as const preserves each string as a literal type.

Now this works:

const method: PaymentMethod = "card";

But this fails:

const method: PaymentMethod = "crypto";
// TypeScript error

Why this is useful: Roles, permissions, status values, supported features, and configuration options.

3. Use `satisfies` Without Losing Type Inference

This is one of my favorite TypeScript features.

Sometimes you want to verify that an object follows a specific structure without replacing its inferred type with that structure.

That's what satisfies helps with.

type Route = {
  path: string;
  requiresAuth: boolean;
};

const routes = {
  home: {
    path: "/",
    requiresAuth: false,
  },
  dashboard: {
    path: "/dashboard",
    requiresAuth: true,
  },
} satisfies Record<string, Route>;

TypeScript checks that every route matches the required structure.

But unlike a straightforward type annotation, the satisfies operator preserves useful details from the expression's inferred type.

For example:

routes.dashboard.requiresAuth;
// Inferred as boolean

The expression retains its property information, while the satisfies check ensures that the object conforms to Record<string, Route>.

Why this is useful: Route configurations, feature flags, application settings, and event maps.

4. Make Impossible States Impossible

Imagine an API request can be in one of three states: loading, successful, or failed.

A poorly designed type might allow contradictory combinations, such as a failed request that also contains successful data.

A discriminated union can model the valid states more clearly.

type ApiState<T> =
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; message: string };

Now you can write:

function handleState<T>(state: ApiState<T>) {
  switch (state.status) {
    case "loading":
      return "Please wait";

    case "success":
      return state.data;

    case "error":
      return state.message;
  }
}

TypeScript knows which properties are available in each branch.

You cannot accidentally access data on the loading state without checking which state you're dealing with.

Why this is useful: API responses, authentication flows, payment processing, and background jobs.

5. Use `never` to Catch Missing Cases

Suppose you handle every order status in a switch statement.

Later, someone adds another status, but forgets to update your function.

You can make TypeScript catch that mistake.

type OrderStatus =
  | "pending"
  | "shipped"
  | "delivered";

function assertNever(value: never): never {
  throw new Error(`Unexpected value: ${value}`);
}

function getMessage(status: OrderStatus): string {
  switch (status) {
    case "pending":
      return "Order is pending";

    case "shipped":
      return "Order has shipped";

    case "delivered":
      return "Order delivered";

    default:
      return assertNever(status);
  }
}

Now add "cancelled" to OrderStatus.

TypeScript reports an error at assertNever(status) because status can now be "cancelled" instead of being narrowed to never.

You are forced to handle the new case.

Why this is useful: Business workflows, payment states, event handlers, and large applications where missing a case can cause bugs.

6. Build Types From Strings Using Template Literal Types

TypeScript can generate new string types from existing ones.

For example, imagine you have a list of application events.

type EventName = "user" | "order" | "payment";

type EventHandler = `on${Capitalize<EventName>}`;

The resulting type becomes:

type EventHandler =
  | "onUser"
  | "onOrder"
  | "onPayment";

You can even create event names dynamically at the type level:

type Action = "create" | "delete";
type Entity = "user" | "order";

type Permission = `${Action}:${Entity}`;

This generates:

type Permission =
  | "create:user"
  | "create:order"
  | "delete:user"
  | "delete:order";

Why this is useful: Permission systems, event naming conventions, typed API endpoints, and reusable libraries.

7. Use `keyof` to Build Safer Generic Functions

Suppose you want a function that retrieves a property from an object.

A naive implementation might accept any string as the property name, which can lead to mistakes.

Here's a safer version:

function getProperty<T, K extends keyof T>(
  object: T,
  key: K
): T[K] {
  return object[key];
}

const user = {
  id: 101,
  name: "Alex",
  active: true,
};

const name = getProperty(user, "name");
const active = getProperty(user, "active");

TypeScript infers name as string and active as boolean.

But this fails:

getProperty(user, "email");
// TypeScript error

Why?

keyof T produces the valid keys of an object type.
K extends keyof T restricts the key argument.
T[K] represents the type of the selected property.

Why this is useful: Reusable utility functions, form libraries, state management, and object mapping.

8. Use Recursive Conditional Types to Transform Types

This one is more advanced.

TypeScript can define types that refer back to themselves, allowing recursive transformations.

For example, you can create a type that makes every nested object property readonly.

type DeepReadonly<T> =
  T extends (...args: any[]) => any
    ? T
    : T extends readonly unknown[]
      ? { readonly [K in keyof T]: DeepReadonly<T[K]> }
      : T extends object
        ? { readonly [K in keyof T]: DeepReadonly<T[K]> }
        : T;

Now consider:

type Settings = {
  app: {
    theme: string;
    notifications: {
      email: boolean;
    };
  };
};

type ReadonlySettings = DeepReadonly<Settings>;

Properties such as app.theme and app.notifications.email become readonly at the type level.

This means TypeScript will reject assignments to those properties.

A couple of important details:

This is a compile-time transformation, not runtime freezing.
Recursive types can become expensive or difficult for the compiler to evaluate when used with very complex structures.

Why this is useful: Configuration models, immutable state, and advanced type utilities.

Bonus: TypeScript Types Don't Validate Runtime Data

This is an important distinction that even experienced developers sometimes overlook.

interface User {
  id: number;
  name: string;
}

const user = JSON.parse('{"id":"wrong","name":123}') as User;

TypeScript accepts the assertion, but the actual object still contains a string for id and a number for name.

Why? Because as User tells the compiler to treat the value as that type. It doesn't validate the object.

When dealing with external data, use runtime validation with a schema or explicit checks.

Types make development safer, but they don't replace runtime validation.

Final Thoughts

TypeScript becomes much more interesting when you move beyond basic types and interfaces.

Features like satisfies, keyof, template literal types, discriminated unions, and recursive conditional types allow you to catch mistakes and express complex rules directly in your code.

My suggestion: don't use advanced types just because you can. Use them when they make your code safer, clearer, and easier to maintain.

Which TypeScript trick do you use most in your projects? Did I miss one worth sharing?

Let's discuss in the comments.

# TypeScript Made Simple: 7 Concepts Every Developer Should Know

Shubham_Baghel — Mon, 12 Oct 2026 16:30:00 +0000

If you have worked with JavaScript, you have probably faced situations where your code looked perfectly fine but failed because of a small mistake.

Maybe you passed a string instead of a number. Maybe an API returned something you were not expecting. Or maybe you spent 20 minutes debugging a property that did not exist.

This is one of the reasons I enjoy working with TypeScript.

TypeScript does not magically eliminate bugs, but it helps us catch many common mistakes before our code even runs.

Let's understand seven useful TypeScript concepts with simple examples.

1. Type: Tell TypeScript What You Expect

Imagine you are building an application where every user has a name and an age.

In JavaScript, you can accidentally assign the wrong value without getting an immediate warning.

TypeScript helps you define what values are expected.

let userName: string = "Alex";
let age: number = 25;

age = "twenty-five"; // TypeScript error

Think of types as basic rules for your data.

They help you catch mistakes while writing code instead of discovering them later.

2. Interface: Define the Shape of an Object

Suppose your application receives user information from an API.

Instead of guessing which properties the user object should contain, you can define its structure.

interface User {
  id: number;
  name: string;
  email: string;
}

const user: User = {
  id: 1,
  name: "Alex",
  email: "alex@example.com",
};

Now TypeScript can warn you if you forget a required property or provide an incorrect type.

In simple words: An interface describes what an object should look like.

3. Type vs Interface: Are They the Same?

This is one of the most common questions developers ask.

Both can describe an object's structure.

interface Product {
  name: string;
  price: number;
}

type Customer = {
  name: string;
  email: string;
};

So, why have both?

The main difference becomes clearer when you need more advanced features.

For example, type can represent a union of different values:

type Status = "pending" | "success" | "failed";

An interface is often a natural choice for object contracts, while a type alias is particularly useful for unions, intersections, and other type combinations.

There is some overlap, so you do not need to overthink the choice for every object.

4. Union Types: Allow More Than One Possibility

Imagine an API that returns a user ID as either a number or a string.

You can represent both possibilities with a union type.

let userId: string | number;

userId = 101;
userId = "USER-101";

The | symbol means the value can be one type or another.

You can also use this for application states:

type OrderStatus =
  | "pending"
  | "shipped"
  | "delivered"
  | "cancelled";

This is much safer than allowing any random string.

For example, "shiped" would be rejected because it is not one of the allowed values.

5. Generics: Write Code That Works With Different Types

Suppose you need a function that returns whatever value you pass to it.

You could write separate functions for strings, numbers, and objects. But that would create unnecessary repetition.

Generics solve this problem.

function getValue<T>(value: T): T {
  return value;
}

const name = getValue("Alex");
const age = getValue(25);

Here, T is a placeholder for a type.

TypeScript can infer that name is a string and age is a number.

You get reusable code without losing type information.

Think of generics as a way to make one function work with different data types while still respecting their types.

6. Utility Types: Reuse Existing Types

Sometimes you already have a type but need a slightly different version of it.

For example, you have a user model but want to create a user without requiring every property.

interface User {
  id: number;
  name: string;
  email: string;
}

type CreateUser = Omit<User, "id">;

Now CreateUser contains only name and email.

Here are a few useful utility types:

Partial<T> — makes all properties optional.
Pick<T, K> — selects specific properties.
Omit<T, K> — removes specific properties.
Required<T> — makes all properties required.
Readonly<T> — makes properties read-only at the type level.

These become especially useful when working with API requests, database models, and update operations.

7. Type Narrowing: Check Before You Use a Value

Imagine a function accepts either a string or a number.

You cannot safely call string-specific methods until you know that the value is actually a string.

function printValue(value: string | number) {
  if (typeof value === "string") {
    console.log(value.toUpperCase());
  } else {
    console.log(value.toFixed(2));
  }
}

TypeScript understands the condition and narrows the type inside each branch.

This makes your code safer and easier to understand.

You can also narrow types using checks such as in, equality comparisons, and custom type guards.

One Important Thing to Remember

TypeScript checks types during development and compilation, but its types do not automatically validate incoming data at runtime.

For example, an API response can still contain unexpected data even if you have defined an interface for it.

For external data, use runtime validation when necessary.

TypeScript helps you write safer code, but it is not a replacement for proper validation and testing.

Final Thoughts

You do not need to master every advanced TypeScript feature to start using it effectively.

Start with basic types, interfaces, union types, and type narrowing. Once you are comfortable with those, explore generics and utility types.

The goal is not to write complicated types everywhere. The goal is to make your code easier to understand, maintain, and debug.

What TypeScript concept took you the longest to understand? Share your experience in the comments. It might help another developer who is learning the same thing.

[Boost]

Shubham_Baghel — Tue, 28 Oct 2025 11:15:12 +0000

Shubham_Baghel

Oct 28 '25

𝐒𝐨𝐥𝐯𝐢𝐧𝐠 𝐂𝐨𝐥𝐝 𝐒𝐭𝐚𝐫𝐭𝐬 𝐢𝐧 𝐀𝐖𝐒 𝐒𝐞𝐫𝐯𝐞𝐫𝐥𝐞𝐬𝐬 (𝐋𝐚𝐦𝐛𝐝𝐚)

#webdev #programming #aws #devops

2 min read

𝐒𝐨𝐥𝐯𝐢𝐧𝐠 𝐂𝐨𝐥𝐝 𝐒𝐭𝐚𝐫𝐭𝐬 𝐢𝐧 𝐀𝐖𝐒 𝐒𝐞𝐫𝐯𝐞𝐫𝐥𝐞𝐬𝐬 (𝐋𝐚𝐦𝐛𝐝𝐚)

Shubham_Baghel — Tue, 28 Oct 2025 09:25:21 +0000

One of the most common performance challenge in serverless app is the Lambda cold start that small delay when AWS spins up a fresh execution environment after inactivity.

Some easy tricks to make Lambda functions start faster in production:

1.𝐔𝐬𝐞 𝐏𝐫𝐨𝐯𝐢𝐬𝐢𝐨𝐧𝐞𝐝 𝐂𝐨𝐧𝐜𝐮𝐫𝐫𝐞𝐧𝐜𝐲

Keeps a set number of Lambda instances always warm.

AWS pre-initialise execution environments for you so no first-call delay.

Configure via Console, CLI, or CDK:
AWS Docs: AWS provisioned concurrency

Tip: Perfect for APIs or real-time workloads (e.g., login or payment endpoints).

2.𝐊𝐞𝐞𝐩 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧𝐬 𝐖𝐚𝐫𝐦 𝐰𝐢𝐭𝐡 𝐚 𝐒𝐜𝐡𝐞𝐝𝐮𝐥𝐞𝐫

Trigger your function periodically (every 5–10 mins) to prevent it from going cold.

Use Amazon EventBridge or CloudWatch Schedule for simple pinging.

EventBridge Docs:EventBridge

Tip: Combine this with a lightweight health-check lambda endpoint (like /ping). This is useful in microservices setups for example, after a new deployment, you can quickly test and verify that all functions are warm and responding correctly.

3.𝐎𝐩𝐭𝐢𝐦𝐢𝐳𝐞 𝐃𝐞𝐩𝐥𝐨𝐲𝐦𝐞𝐧𝐭 𝐏𝐚𝐜𝐤𝐚𝐠𝐞 𝐒𝐢𝐳𝐞

The bigger your Lambda zip, the longer AWS takes to initialize it.

Bundle only what’s needed (exclude dev dependencies).

Use tools like esbuild, webpack, or AWS SAM build.

Tip: For Node.js avoid installing large libraries like aws-sdk (it’s pre-included) and remove unused packages with library called depcheck.

4.𝐂𝐡𝐨𝐨𝐬𝐞 𝐭𝐡𝐞 𝐑𝐢𝐠𝐡𝐭 𝐑𝐮𝐧𝐭𝐢𝐦𝐞

Cold start time depends heavily on the runtime.

Node.js and Python start up faster than Java or .NET.

AWS SnapStart Doc:AWS SnapStart

Tip: If you need Java, enable AWS Lambda SnapStart
to pre-initialise the function state.

5.𝐁𝐞 𝐂𝐚𝐫𝐞𝐟𝐮𝐥 𝐰𝐢𝐭𝐡 𝐕𝐏𝐂 𝐂𝐨𝐧𝐟𝐢𝐠𝐮𝐫𝐚𝐭𝐢𝐨𝐧

Putting Lambdas inside a VPC adds ENI (Elastic Network Interface) setup time.

Avoid VPC unless you truly need private resources (like RDS).

If required, use VPC endpoints or NAT optimization.
Best Practices for VPC Lambda Networking: VPC configuration

Tip: For DynamoDB, S3, or SNS we can go without a VPC entirely.

6.𝐒𝐩𝐥𝐢𝐭 𝐋𝐚𝐫𝐠𝐞 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧𝐬

Monolithic Lambdas = longer cold starts.

Break down your logic into multiple smaller Lambdas (micro-Lambdas).

Tip: This also improves deploy speed and observability.

In one project, our first API call took ~2.4s (cold Lambda in VPC).
After making a few changes like
• Removed VPC dependency
• Enabled provisioned concurrency (2 instances)
• Added an EventBridge warm-up every 10 mins

Cold start dropped to ~150ms consistently.

Best way to deploy Nodejs app

Shubham_Baghel — Thu, 27 Mar 2025 15:56:49 +0000

Shubham_Baghel

Mar 27 '25

Deploying a NodeJS Application using Docker on AWS EC2 & Kubernetes (EKS)

#webdev #javascript #aws #docker

3 min read

Deploying a NodeJS Application using Docker on AWS EC2 & Kubernetes (EKS)

Shubham_Baghel — Thu, 27 Mar 2025 15:44:45 +0000

Deploying a Node.js application using Docker, Kubernetes, and AWS is a multi-step process that requires building the Docker image, configuring Kubernetes for deployment, and setting up AWS services. Below is an process and commands involved

I'll walk through the steps of deploying a simple Node.js application using Docker, Kubernetes, and AWS.

Step 1: Set Up Node.js Application
First, create a simple Node.js application. For this example, we'll use a basic Express server.

Create a server.js file:

// server.js
const express = require('express');
const app = express();
const port = 3000;

app.get('/', (req, res) => {
  res.send('First Service from Node.js!');
});

app.listen(port, () => {
  console.log(`Server is running on port ${port}`);
});

Step 2: Dockerize the Node.js Application
Create a Dockerfile:

The Dockerfile defines the environment to run your application.

# Step 1: Use the official Node.js image
FROM node:14

# Step 2: Set the working directory inside the container
WORKDIR /usr/src/app

# Step 3: Copy the application code into the container
COPY . .

# Step 4: Install dependencies
RUN npm install

# Step 5: Expose the application port
EXPOSE 3000

# Step 6: Run the application
CMD ["npm", "start"]

Build the Docker image using below command:

docker build -t node-docker-app .

docker run -p 3000:3000 node-docker-app
Now we can check
our application should now be accessible at http://localhost:3000.

Step 3: Push Docker Image to AWS ECR (Elastic Container Registry)
First, create a repository in ECR on AWS Console:

Go to the ECR section of AWS.

Create a new repository, e.g., node-docker-app.

Then, authenticate Docker with AWS ECR:

aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.us-west-2.amazonaws.com
Reference Link: link:https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html

Tag the Docker image:
docker tag node-docker-app:latest <aws_account_id>.dkr.ecr.us-west-2.amazonaws.com/node-docker-app:latest

Push the Docker image to ECR:

docker push <aws_account_id>.dkr.ecr.us-west-2.amazonaws.com/node-docker-app:latest

Step 4: Create Kubernetes Deployment Configuration
Create a Kubernetes deployment YAML file to manage your Dockerized app.

Create a deployment.yaml file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-docker-app-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: node-docker-app
  template:
    metadata:
      labels:
        app: node-docker-app
    spec:
      containers:
      - name: node-docker-app
        image: <aws_account_id>.dkr.ecr.us-west-2.amazonaws.com/node-docker-app:latest
        ports:
        - containerPort: 3000

Create a Kubernetes service YAML file:

This exposes your application to the outside world.

Create a service.yaml file:

apiVersion: v1
kind: Service
metadata:
  name: node-docker-app-service
spec:
  selector:
    app: node-docker-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
  type: LoadBalancer

Step 5: Set Up Kubernetes on AWS (EKS)
Install kubectl and Install eksctl (for creating an EKS cluster)

brew install kubectl

brew install eksctl

Create an EKS cluster:

eksctl create cluster --name nodejs-cluster --region us-west-2 --nodegroup-name nodegroup --node-type t2.micro --nodes 2

Configure kubectl to use your EKS cluster:

aws eks --region us-west-2 update-kubeconfig --name nodejs-cluster

Step 6: Deploy the Application to Kubernetes
Apply the deployment and service files:

kubectl apply -f deployment.yaml kubectl apply -f service.yaml

Check the status of the deployment:

kubectl get deployments kubectl get pods

Get the LoadBalancer IP:

kubectl get svc node-docker-app-service

The external IP address will be listed under the EXTERNAL-IP column. You can now access the application via the LoadBalancer's IP.

Step 7: Clean Up
When you're done, you can delete the Kubernetes cluster on AWS to avoid any ongoing charges:

`eksctl delete cluster --name nodejs-cluster --region us-west-2

How Lambda will enhance your app scalability

Shubham_Baghel — Sun, 07 May 2023 15:06:22 +0000

Suppose you have an e-commerce site and you need to tune the consumer's behavior for the duration of their visit. You want to recognize how a lot time the purchaser spends on each web page and which pages they go to in what order. This information can help you examine the consumer's hobbies and possibilities and enhance their universal revel in on the website.

One way to reap that is by means of developing a Lambda feature that is caused every time a user visits a web page on your internet site. The function can record the user's consultation facts in a database or file. Here's a pattern code for the Lambda characteristic:

In this case, the Lambda characteristic receives an occasion object that consists of the pageId and sessionId. The pageId is the identifier for the web page that the person is presently visiting, and the sessionId is a unique identifier for the consumer's consultation.

The feature then generates a timestamp and creates an item that includes the sessionId, pageId, and timestamp. It makes use of the AWS SDK to put in writing this object to a DynamoDB table named web page-visit-tracking. Finally, it logs a message indicating that the page visit has been recorded.

This Lambda function can be incorporated together with your internet site's frontend code to ship an occasion item to the Lambda function each time a consumer visits a web page. By doing so, you may music the person's conduct and benefit precious insights into their pursuits and preferences.

Redis with Nodejs

Shubham_Baghel — Mon, 27 Mar 2023 09:38:36 +0000

Introduction

Redis is an in-memory data store that can be used as a database, cache and message broker. The main benefits of using Redis is its speed. Because it's an in-memory database, it can read and write data very quickly with feature like pipeline and transactions, making it a great choice for applications that need to process large volumes of data in real-time. Redis also supports a variety of data structures, including strings, hashes, lists, sets, and sorted sets. This makes it very versatile and useful for a wide range of applications.

To use Redis with node.js,you will need to install "redis" package,We can installed it using below command:

npm install redis

After this lets create Redis client using redis.createclient.This will create a new client that connects to default redis server on localhost:6379.Also we can pass configuration objectin createclient method:


const client = redis.createClient({
    socket: {
        host: '<hostname>',
        port: '<port>'
    },
    password: '<password>'
});

Installation on windows:
Redis installation step for windows

Redis installation step for macOs

Now lets see how we can use client.set() to set a key-value pair in redis,The first argument is key which will be any filed that we need to store and will be consider as KEY and second argument here is actual value and third is callback function that gets executed or called once the execution is complete.


// Set a key-value pair in Redis
client.set('name', 'devtoUser', (error, result) => {
  if (error) {
    console.error(error);
  } else {
    console.log(result); // this will return OK
  }
});

Finally, we use client.get() to get the value of the namekey from Redis.The first argument is the key, and the second argument is a callback function that gets called once the operation is complete. In this example, we log the result to the console if there are no errors.

// Get a value from Redis
client.get('name', (error, result) => {
  if (error) {
    console.error(error);
  } else {
    console.log(result); //this will return devtoUser
  }
});

Redis benefits

Redis also has a number of advanced features that make it a powerful tool for developers. Some of these features include:

Pub/Sub messaging: Redis can be used as a message broker, allowing applications to publish and subscribe to messages. This makes it useful for building real-time applications, such as chat apps or real-time analytics systems.
Lua scripting: Redis has a built-in Lua interpreter, which allows developers to write custom scripts that can be executed on the server. This can be useful for complex data operations that can't be easily performed using built-in Redis commands.
Transactions: Redis supports transactions, allowing developers to group multiple commands together into a single atomic operation. This can help ensure data consistency and prevent race conditions.
Persistence: Redis can be configured to periodically save its data to disk, ensuring that data is not lost if the server crashes or is restarted.

Github Repo:
Redis repo

Additional Radis commands :
Redis commands list

useCallback vs useMemo

Shubham_Baghel — Mon, 06 Mar 2023 14:33:12 +0000

useCallback and useMemo are both React hooks that can be used to optimize the performance of your React application by remembering calculated values in components but there is a slight difference in terms of Return Value, Dependency array. Below is good comparison of both.

Use case: The main use case of useCallback is to remember a function, while the main use case of useMemo is to remember a value.
Return value: useCallback returns a memorized function, while useMemo returns a memorized value.
Dependencies Array:

useCallback takes a dependency array as the second argument, which specifies the values on which the stored function depends. The function will only be recalculated if any value in the dependencies array changes. On the other hand,
useMemo also takes an array of dependencies as the second argument, but it specifies the values on which the remembered value depends. The value will only be recalculated if any value in the dependencies array changes.

Performance Considerations: If you have a computationally expensive function that you need to pass as a prop to a child component, you should use useCallback to remember that function. This will prevent the child component from rendering unnecessarily. If you have a computationally expensive value that you need to use in a component, you should use useMemo to remember that value. This will prevent the value from being unnecessarily recalculated on every new render.

In this example, we use both useMemo and useCallback to remember a value and a function respectively. Expensive value is remembered by useMemo and expensive function is remembered by useCallback. Both hooks depend on the value of the count state and will only recalculate if the count value changes. This can help optimize component performance.

Why to useMemo hook?

Shubham_Baghel — Sun, 05 Mar 2023 12:09:16 +0000

Suppose you have a module that displays a listing of products, each one with its own label and cost. Moreover, you have a separate function that determines the collective price for all the items. This is an illustration of how to employ the useMemo hook to store the result of the total price calculation:


import React, { useMemo } from 'react';

function ItemList({ items }) {
  const totalPrice = useMemo(() => {
    console.log('Calculating total price...');
    return items.reduce((acc, item) => acc + item.price, 0);
  }, [items]);

  return (
    <div>
      <ul>
        {items.map((item) => (
          <li key={item.name}>
            {item.name}: {item.price}
          </li>
        ))}
      </ul>
      <p>Total price: {totalPrice}</p>
    </div>
  );
}

The useMemo hook lets us set up a variable, entitled totalPrice, in this instance. The first piece of the hook is a function that works out the cost of all the items; the second part is an array of dependencies, meaning that React will recalculate the price any time the dependencies alter. In this instance, the only thing that the calculation is reliant on is the items prop.

The useMemo hook memorizes the result of the function, so if the items prop hasn't changed since the last render, React will take the previous result instead of running the function again. This can be helpful for complicated calculations that don't need to be re-run every time the render is executed. For example, if there is a large list of items, figuring out the total cost on every render could be time-consuming; memorizing the result can increase performance.

It is worth noting that useMemo is not a substitute for useEffect. useMemo should be used to store the outcome of a function, while useEffect should be used for completing side effects like obtaining data from an API.

How to Write React Hooks More Effectively

Shubham_Baghel — Sun, 05 Mar 2023 10:30:39 +0000

1.Only call hooks at the top level: Hooks should only be called at the top level of your component or custom hook. Do not call hooks inside loops, conditions, or nested functions

Example:

function MyComponent() {
  const [state, setState] = useState(0);

  function handleClick() {
    setState(state + 1); // This is correct
  }

  return (
    <button onClick={handleClick}>Click me</button>
  );
}

function MyOtherComponent() {
  const [state, setState] = useState(0);

  function handleClick() {
    if (state > 0) {
      setState(state - 1); // This is correct
    }
  }

  return (
    <button onClick={handleClick}>Click me</button>
  );
}

2.Use the state hook for local state: The state hook is the most commonly used hook and should be used for any local state that your component needs.

function MyComponent() {
  const [name, setName] = useState("");

  return (
    <>
      <input value={name} onChange={e => setName(e.target.value)} />
      <p>Hello, {name}</p>
    </>
  );
}

3.Use the effect hook for side effects: The effect hook allows you to synchronize a component with an external system, such as a web API or a browser API.

function MyComponent() {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetch("https://my-api.com/data")
      .then(response => response.json())
      .then(data => setData(data));
  }, []);

  return (
    <ul>
      {data.map(item => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  );
}

4.Avoid unnecessary re-renders: Hooks like useMemo and useCallback can help you avoid unnecessary re-renders by memoizing values and functions.

function MyComponent({ items }) {
  const sortedItems = useMemo(() => items.sort(), [items]);

  return (
    <ul>
      {sortedItems.map(item => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  );
}

5.Keep hooks simple: Each hook should only handle one piece of logic, such as setting up a subscription or measuring the size of an element

function useData(url) {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetch(url)
      .then(response => response.json())
      .then(data => setData(data));
  }, [url]);

  return data;
}

function MyComponent() {
  const data = useData("https://my-api.com/data");

  return (
    <ul>
      {data.map(item => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  );
}

6.Use the context hook to share state: The context hook allows you to share state between components without having to pass props down the component tree.

const MyContext = React.createContext();

function MyProvider({ children }) {
  const [name, setName] = useState("");

  return (
    <MyContext.Provider value={{ name, setName }}>
      {children}
    </MyContext.Provider>
  );
}

function MyComponent() {
  const { name, setName } = useContext(MyContext);

  return (
    <>
      <input value={name} onChange={e => setName(e.target.value)} />
      <p>Hello, {name}</p>
    </>
  );
}

function App() {
  return (
    <MyProvider>
      <MyComponent />
    </MyProvider>
  );
}

In this example, the MyProvider component creates a context and provides the name and setName state to its children via the value prop. The MyComponent component then uses the useContext hook to access the name and setName state from the context.

This way, the name state can be accessed and modified by any component that is a child of the MyProvider component, without having to pass props down the component tree.

7.The handleClick function uses the callback form of the setCount updater, which receives the previous state and returns the new state. This way, the function can update the state based on the previous value, without needing to use a useEffect or useRef to store the previous value.

function MyComponent() {
  const [count, setCount] = useState(0);

  const handleIncrement = useCallback(() => {
    setCount(prevCount => prevCount + 1);
  }, [setCount]);

  const handleDecrement = useCallback(() => {
    setCount(prevCount => prevCount - 1);
  }, [setCount]);

  return (
    <>
      <button onClick={handleIncrement}>Increment</button>
      <button onClick={handleDecrement}>Decrement</button>
      <p>Count: {count}</p>
    </>
  );
}

This approach is useful in situations where the component updates frequently, and you want to prevent unnecessary re-renders caused by changing function references. It also allows to memoize the function, which means it will not recreate the function if the dependencies haven't changed.

8.Use the useEffect hook with a cleanup function: A cleanup function is a function that is executed when a component is unmounted or a hook is re-run

import { useEffect, useState } from 'react';

function MyComponent() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const intervalId = setInterval(() => {
      setCount(count => count + 1);
    }, 1000);
    // Cleanup function
    return () => clearInterval(intervalId);
  }, [setCount]);

  return <p>Count: {count}</p>;
}

In this example, the useEffect hook is used to set up an interval that increments the count state every second. The setInterval function returns an interval ID, which is stored in a variable called intervalId.

The useEffect hook also takes a function as a second argument that is used as a cleanup function. It is executed when the component is unmounted or the hook is re-run. In this case, the cleanup function is used to clear the interval by passing in the intervalId variable to the clearInterval function.

This way, we can ensure that the interval is properly cleared when the component is no longer in use, and avoid memory leaks.

Cleanup functions are a powerful feature of the useEffect hook, they allow you to perform a cleanup operation when a component is unmounted or when a hook is re-run. This makes sure that you don't leave any unnecessary event listeners, timeouts, intervals or other resources that are no longer needed.

9.Always pass the dependencies array to useEffect: This array should include all values that the effect depends on.

import { useEffect, useState } from 'react';

function MyComponent({ userId }) {
  const [userData, setUserData] = useState(null);

  useEffect(() => {
    fetch(`https://jsonplaceholder.typicode.com/users/${userId}`)
      .then(response => response.json())
      .then(data => setUserData(data));
  }, [userId, setUserData]);

  return userData ? (
    <>
      <h2>{userData.name}</h2>
      <p>{userData.email}</p>
    </>
  ) : (
    <p>Loading...</p>
  );
}

In this example, the useEffect hook is used to fetch data from an API based on the userId prop passed to the component. The fetch function is used to make a request to the API, and the then method is used to handle the response and update the userData state.

The second argument passed to the useEffect hook is an array of dependencies, which includes userId and setUserData. These are the values that the effect depends on, so they should be included in the dependencies array.

This way, the effect will only re-run when the userId prop or setUserData state change, and it will not re-run when other props or state values change. This can help to optimize the performance of your component and avoid unnecessary re-renders.

Always passing the dependencies array to the useEffect hook is important because it tells React when the effect should be run again. If you don't specify the dependencies array, React will assume that the effect depends on all the state and props, and will run the effect on every render. This can lead to unexpected behavior and performance issues.

10.Be careful when using hooks in loops: If you want to use a hook in a loop, make sure that each rendered element has its own state

import { useState, useEffect } from "react";

function MyComponent({ items }) {
  return (
    <ul>
      {items.map((item, index) => {
        const [isSelected, setIsSelected] = useState(false);
        return (
          <li key={item.id} onClick={() => setIsSelected(!isSelected)}>
            {item.name} {isSelected ? "Selected" : ""}
          </li>
        );
      })}
    </ul>
  );
}

In this example, My component takes an items prop and maps over it to render a list of items. Each item is rendered as a list item (li) element. Inside the map function, I am using the useState hook to create a isSelected state variable for each item.

By providing a unique key for each item, React can tell which elements are being added, removed, or re-arranged. This way, React can manage the state of each element separately, and you don't have to worry about the hook state being shared across elements.

It is important to be careful when using hooks inside loops, because if you don't provide a unique key for each element, React will not be able to tell which elements are being added, removed or re-arranged, and it will reuse the state of the hook across elements, which can lead to unexpected behavior and bugs.

It's also important to mention that we could use useState inside a callback or inside useEffect instead of directly in the JSX, this way we don't have to worry about different components using the same state.

DEV Community: Shubham_Baghel

7 System Design Concepts I Wish I Had Learned Earlier

1. Load Balancer — What Happens When One Server Is Not Enough?

2. API Gateway — One Door for Your Application

3. Message Queues — Why Make Users Wait for Everything?

4. Caching — Do We Really Need to Query the Database Every Time?

5. Circuit Breaker — What If Another Service Stops Responding?

6. Database Replication vs Sharding — They're Not the Same Thing

7. Monitoring and Logs — How Do We Know What's Going Wrong?

One Last Thing: Don't Overcomplicate Your Architecture

TypeScript Tricks That Feel Like Cheating

1. Create Types From Existing Objects Using typeof

2. Turn an Array Into a Union Type

3. Use satisfies Without Losing Type Inference

4. Make Impossible States Impossible

5. Use never to Catch Missing Cases

6. Build Types From Strings Using Template Literal Types

7. Use keyof to Build Safer Generic Functions

8. Use Recursive Conditional Types to Transform Types

Bonus: TypeScript Types Don't Validate Runtime Data

Final Thoughts

# TypeScript Made Simple: 7 Concepts Every Developer Should Know

1. Type: Tell TypeScript What You Expect

2. Interface: Define the Shape of an Object

3. Type vs Interface: Are They the Same?

4. Union Types: Allow More Than One Possibility

5. Generics: Write Code That Works With Different Types

6. Utility Types: Reuse Existing Types

7. Type Narrowing: Check Before You Use a Value

One Important Thing to Remember

Final Thoughts

[Boost]

𝐒𝐨𝐥𝐯𝐢𝐧𝐠 𝐂𝐨𝐥𝐝 𝐒𝐭𝐚𝐫𝐭𝐬 𝐢𝐧 𝐀𝐖𝐒 𝐒𝐞𝐫𝐯𝐞𝐫𝐥𝐞𝐬𝐬 (𝐋𝐚𝐦𝐛𝐝𝐚)

𝐒𝐨𝐥𝐯𝐢𝐧𝐠 𝐂𝐨𝐥𝐝 𝐒𝐭𝐚𝐫𝐭𝐬 𝐢𝐧 𝐀𝐖𝐒 𝐒𝐞𝐫𝐯𝐞𝐫𝐥𝐞𝐬𝐬 (𝐋𝐚𝐦𝐛𝐝𝐚)

1.𝐔𝐬𝐞 𝐏𝐫𝐨𝐯𝐢𝐬𝐢𝐨𝐧𝐞𝐝 𝐂𝐨𝐧𝐜𝐮𝐫𝐫𝐞𝐧𝐜𝐲

2.𝐊𝐞𝐞𝐩 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧𝐬 𝐖𝐚𝐫𝐦 𝐰𝐢𝐭𝐡 𝐚 𝐒𝐜𝐡𝐞𝐝𝐮𝐥𝐞𝐫

3.𝐎𝐩𝐭𝐢𝐦𝐢𝐳𝐞 𝐃𝐞𝐩𝐥𝐨𝐲𝐦𝐞𝐧𝐭 𝐏𝐚𝐜𝐤𝐚𝐠𝐞 𝐒𝐢𝐳𝐞

4.𝐂𝐡𝐨𝐨𝐬𝐞 𝐭𝐡𝐞 𝐑𝐢𝐠𝐡𝐭 𝐑𝐮𝐧𝐭𝐢𝐦𝐞

5.𝐁𝐞 𝐂𝐚𝐫𝐞𝐟𝐮𝐥 𝐰𝐢𝐭𝐡 𝐕𝐏𝐂 𝐂𝐨𝐧𝐟𝐢𝐠𝐮𝐫𝐚𝐭𝐢𝐨𝐧

6.𝐒𝐩𝐥𝐢𝐭 𝐋𝐚𝐫𝐠𝐞 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧𝐬

Best way to deploy Nodejs app

Deploying a NodeJS Application using Docker on AWS EC2 & Kubernetes (EKS)

Deploying a NodeJS Application using Docker on AWS EC2 & Kubernetes (EKS)

How Lambda will enhance your app scalability

Redis with Nodejs

Introduction

Redis benefits

useCallback vs useMemo

Why to useMemo hook?

How to Write React Hooks More Effectively

1. Create Types From Existing Objects Using `typeof`

3. Use `satisfies` Without Losing Type Inference

5. Use `never` to Catch Missing Cases

7. Use `keyof` to Build Safer Generic Functions