DEV Community: Hamid Shoja

5- AWS Serverless:: Caching and Event-Driven Design

Hamid Shoja — Tue, 16 Jun 2026 20:56:00 +0000

When building high-scale, resilient systems on AWS, performance isn't just about writing fast code, it’s about avoiding unnecessary work. A Engineer’s philosophy often boils down to a simple truth: The fastest code is the code that never executes, and the fastest database query is the one you never have to make.

Let’s unpack caching in AWS piece by piece with a few real-world examples.

Layer 1: Edge Caching (AWS CloudFront)

AWS CloudFront is a Content Delivery Network (CDN). Instead of forcing every user around the world to request data from your main servers (say, located in Virginia), CloudFront replicates data across hundreds of data centers globally, called Edge Locations. If a user in London requests an asset, CloudFront serves it from a London edge server.

There are two types of data cached here:

Static assets: Images, CSS, JavaScript files.
Cacheable API responses: Data from your backend that doesn't change frequently (e.g., a product catalog list).

This is controlled using standard web instructions called Cache-Control HTTP headers sent by your application (e.g., Cache-Control: public, max-age=3600 tells CloudFront to hold onto this data for one hour).

Simple Example:

Imagine an e-commerce store. The logo image (logo.png) and the list of product categories (Shoes, Hats, Shirts) rarely change.

The Flow: When User A requests the category list, CloudFront fetches it from your database once, saves a copy at the Edge, and delivers it. When Users B through Z request the same list, your database is never touched; CloudFront handles it entirely at the edge.
Pipeline Invalidation: When the developers deploy a new version of the website code with a new logo, the deployment pipeline automatically runs a command (aws cloudfront create-invalidation) to forcefully wipe the old logo out of CloudFront's memory globally so users immediately see the new one.

Layer 2: Application Layer Caching (Amazon ElastiCache Redis)

When a request gets past CloudFront and hits your backend compute (AWS Lambda), you don't want the application to immediately hit the primary database if it doesn't have to. we can place Amazon ElastiCache Redis here. Redis is an ultra-fast, in-memory data store.

There are a few specific choices here:

Inside the same VPC: A Virtual Private Cloud (VPC) is your private, isolated network in AWS. Putting Lambda and Redis in the same VPC ensures they can talk to each other securely and with incredibly low latency.
Redis over Memcached: Memcached is a simple key-value cache (e.g., store a string, get a string). Redis is much more powerful. It supports richer data structures (like sorted sets, hashes, and lists) and Pub/Sub (Publish/Subscribe), which allows different parts of your application to broadcast events to each other in real-time.

Simple Example:

Think of a gaming leaderboard or a user's active shopping cart session.
Instead of querying a slow disk-based database every time a player scores a point, you use a Redis Sorted Set. Redis handles the math and sorting instantly in memory. If you want to notify other services that a score changed, you use Redis Pub/Sub to broadcast a message: "Player1 just scored!"

Layer 3: Database Caching (Amazon DAX)

Amazon DynamoDB is a NoSQL database that natively delivers single-digit millisecond latency. For 99% of applications, that is incredibly fast. However, for extreme scale, milliseconds aren't fast enough.

DAX (DynamoDB Accelerator) is a specialized, fully managed write-through cache designed exclusively for DynamoDB. It sits directly in front of your DynamoDB tables. While DynamoDB responds in milliseconds (1/1000th of a second), DAX responds in microseconds (1/1,000,000th of a second). Because it is a "write-through" cache, when you write data to DAX, it automatically saves it to DynamoDB for you, ensuring the cache is always up to date.

Compute Optimization: Lambda Execution Context Reuse

AWS Lambda is serverless. When a request comes in, AWS spins up a tiny container (an invocation), runs your code, and then pauses it.

If a Lambda container is spun up from scratch, it's called a Cold Start.
If a container is reused for a subsequent request, it's called a Warm Start.

If you initialize your database or Redis connection inside the main function handler, your code will open and close a new connection on every single request. This destroys performance. By declaring the Redis client outside the handler function (module scope), AWS keeps that connection alive in memory. When a "warm" invocation happens, the Lambda instantly reuses the existing connection.

Simple Example (Code Context):

Instead of doing this (Bad):

exports.handler = async (event) => {
    const redisClient = connectToRedis(); // Opens a connection EVERY time the function runs
    return await redisClient.get("key");
};

Do this (Good):

const redisClient = connectToRedis(); // Module Scope: Runs ONCE during cold start

exports.handler = async (event) => {
    // Reuses the established connection on all warm starts!
    return await redisClient.get("key");
};

Event-Driven Cache Invalidation

Caching has a legendary problem: How do you know when cached data is old (stale) and needs to be deleted? The engineer uses two strategies to solve this:

TTL-based (Time-to-Live): You set an expiration date on data. For example, "Keep this in Redis for 5 minutes, then delete it automatically."
Event-Driven Invalidation: This is where Event-Driven Design shines. Instead of waiting for a timer to run out, your system reacts to data changes (mutations) in real-time. When a user updates their data, an "event" is triggered. A Lambda function listens to this event and immediately deletes ("invalidates") the old cache key.

Simple Example:

Let's look at a profile update feature:

A user updates their profile bio from "Software Engineer" to "Principal Engineer."
The change is saved to the primary database (DynamoDB).
The Event: DynamoDB emits an event via a feature called DynamoDB Streams saying: "Hey, User 123 just changed their bio!"
The React: An isolated Lambda function wakes up automatically because of that event. It doesn't handle the user's web request; its only job is cache maintenance.
The Lambda runs a command to delete the old cache key for User 123 in Redis (redis.del("user:123")).
The next time anyone views User 123's profile, the application sees the cache is empty, fetches the brand-new data from the database, and repopulates the cache.

Summary

By combining these layers, we can build a system that is incredibly cost-efficient, lightning-fast, and decoupled

I hope you find it helpful
Hash

4- AWS Serverless: Event-Driven Design: SQS, SNS, and EventBridge

Hamid Shoja — Mon, 15 Jun 2026 20:02:00 +0000

When designing modern cloud architectures, Event-Driven Architecture (EDA) is the gold standard for creating decoupled, scalable, and resilient systems. However, choosing the right AWS service for passing messages around can be daunting.

Let’s break down exactly what this means, how each part works, and look at simple real-world examples for each.

Part 1: AWS SQS (Simple Queue Service)

"For resilient pull-based processing with FIFO for ordering guarantees"

What it means

Pull-Based Processing: Instead of pushing an event directly onto a consumer (which might overwhelm it), messages sit safely in a storage queue. The consumer "pulls" (polls) messages from the queue only when it has the capacity to process them.
Resilient: If your consumer service crashes or experiences a sudden traffic spike, the messages aren’t lost. They wait in the queue until the service recovers.
FIFO (First-In, First-Out): Standard queues process messages roughly in order, but sometimes duplicate or out-of-order messages happen. A FIFO queue guarantees strict ordering (Message A will always be processed before Message B if A arrived first) and exactly-once processing.

Simple Example: The Coffee Shop

Imagine a busy coffee shop. Customers place orders, and instead of shouting them directly at one overworked barista (push-based), the orders are printed on paper tickets and lined up on a rail (the queue).

The barista pulls the next ticket from the rail only when they finish the current drink (pull-based processing). If the barista steps away for a moment, the tickets don't vanish; they just wait on the rail (resilient).

Why FIFO matters here: If Customer A orders a Latte and Customer B orders an Espresso immediately after, the barista must make the Latte first to ensure fairness and prevent Customer A from waiting forever.

Part 2: AWS SNS (Simple Notification Service)

"For fan-out to multiple consumers simultaneously"

What it means

Fan-Out Pattern: This is a "push-based" publish/subscribe (Pub/Sub) pattern. A publisher sends a message once to an SNS "Topic," and SNS instantly clones and broadcast-pushes that message to multiple subscribers (consumers) simultaneously.
Decoupling: The service sending the message doesn't know (or care) who is listening. It just drops the message in the bucket, and SNS handles the distribution.

Simple Example: The New Author Announcement

Imagine an author finishes a new book. Instead of emailing every single fan individually, they post an update to a subscription newsletter service (the SNS Topic).

Instantly, that single update is broadcasted ("fanned out") to thousands of subscribers via different channels: some get an email, some get an SMS text, and another system automatically updates the bookstore website inventory.

In a software example: When a user buys a product on an e-commerce site, the OrderPlaced event is sent to SNS. SNS instantly "fans out" this event to three different systems at the exact same time:
The Shipping Service queue to pack the item.
The Invoicing Service queue to charge the card.
The Analytics Service to update marketing dashboards.

Part 3: AWS EventBridge

"For complex routing with pattern-based rules... my default for internal domain events"

What it means

Complex Routing & Pattern-Based Rules: EventBridge is a serverless event bus. Unlike SNS, which blasts messages to everyone subscribed, EventBridge inspects the contents of the event payload. You can write specific rules like: "Only forward this event if status is 'FAILED' and location is 'US'."
Internal Domain Events: A "domain event" is something meaningful that happened in your business logic (e.g., UserUpgradedToPremium). EventBridge is built to be the central nervous system connecting all your microservices.
Schema Registry & TypeScript Auto-Generation: As your team grows, keeping track of what an event looks like (its schema) becomes difficult. EventBridge’s Schema Registry automatically detects the structure of your events. It can then generate code bindings (like TypeScript types). This means developers get auto-complete in their code editors for events happening across the entire company!

Simple Example: The Airport Sorting System

Think of EventBridge like an automated airport baggage handling system. Every bag (event) has a tag indicating its destination, weight, and airline.

The main conveyor belt (the Event Bus) scans the tag of every bag and uses rules to route it:

If the destination is "London," send it to Gate 4.
If the bag is flagged as "Oversized," route it to the special handling team.
If it belongs to a third-party partner airline, route it to their terminal.

Furthermore, the airport maintains a central database of exactly what a valid baggage tag looks like (Schema Registry), so every airline's computer system knows precisely how to print a compatible tag without manual coordination.

When to use which?

Use SQS when your primary goal is load-smoothing and safety. You want to make sure your database or microservice doesn't break under high traffic, and you need to process items sequentially.
Use SNS when you want to broadcast a single event to multiple distinct systems instantly, and you want a simple "fire-and-forget" mechanism.
Use EventBridge when you are building an enterprise microservice mesh. It is the ideal choice when you need to route events based on what is inside them, integrate with SaaS apps (like Zendesk or Stripe), or want strict code-level governance over your event data structures.

hope you find it helpful
Hash

3- AWS Serverless: REST API vs. HTTP API

Hamid Shoja — Sun, 14 Jun 2026 18:42:00 +0000

There is common point of confusion. what's the different between REST API vs. HTTP API in AWS and what's the different between them and a traditional Rest API you write with e.g express in node

in the broader software world, a "REST API" is just an architectural pattern built on top of HTTP requests.

The confusion comes entirely from AWS-specific marketing terminology.

When you are inside the AWS ecosystem, Amazon API Gateway is a specific managed service, and AWS chose to split that service into two different flavors (or software products): one called "REST API" and one called "HTTP API."

Here is exactly how they work under the hood, how they differ internally, and how it compares to traditional servers.

1. How It Works: REST API vs. HTTP API (AWS Architecture)

Think of Amazon API Gateway as a reverse proxy or a "front door" that sits in front of your Lambda functions.

AWS REST API (The Heavyweight)

When a request hits an AWS REST API, AWS passes that request through a massive feature pipeline before it ever touches your Lambda code.

[Client Request] ──> [Authentication (Cognito/IAM)] ──> [Request Validation] ──> [Data Transformation (VTL)] ──> [Your Lambda]

What happens: AWS decrypts the request, validates the JSON schema, checks API keys, runs any custom request transformations using a complex mapping language called VTL, and then invokes your Lambda function.
Why it costs more: You are paying AWS for all that computing power happening inside the API Gateway layer itself.

AWS HTTP API (The Express Lane)

When a request hits an AWS HTTP API, AWS strips out almost the entire middle pipeline.

[Client Request] ──> [JWT/OAuth2 Authorization Only] ──> [Your Lambda]

What happens: The HTTP API acts as a lightning-fast router. It optionally checks a standard JWT token, converts the incoming HTTP request directly into a clean JSON object, and throws it straight into your Lambda function.
Why it costs less: Because AWS is doing almost zero processing or data manipulation. Your TypeScript Lambda function handles the validation and logic instead.

2. The Traditional Service Comparison (Express.js / NestJS)

In a traditional application (like a Node.js/Express app running on a virtual server or Docker container), you don't have this artificial split. You just write a "REST API."

Here is how the architecture looks side-by-side:

Traditional Server (Express.js on EC2/Docker)

In a traditional setup, one single server handles everything.

The server listens for an HTTP request.
Your Express middleware handles routing (app.get('/hello')).
Your Express middleware handles authorization and data validation.
Your controller executes the business logic.

AWS Serverless (HTTP API + Lambda)

In AWS Serverless, the responsibilities are decoupled into completely separate services:

AWS HTTP API handles the networking, SSL certificates, and basic routing (GET /hello).
AWS Lambda acts as the isolated execution container that runs your TypeScript code to handle the business logic.

Summary: Unmixing the Terms

In the Real World: A REST API is a conceptual design pattern. An HTTP request is the underlying protocol. A traditional Node.js backend handles both of these inside the application code.
In AWS Language: "REST API" and "HTTP API" are just two different pricing and feature tiers of the Amazon API Gateway service.

If you don't need AWS to do complex request manipulation before your code runs, you choose the HTTP API tier to save 70% on your infrastructure bill and let your TypeScript code do the heavy lifting!

I hope you find it useful
HASH

2- AWS Serverless: Testing (typescript)

Hamid Shoja — Fri, 12 Jun 2026 09:31:00 +0000

Shifting from traditional application testing to serverless TypeScript engineering is all about shifting your perspective: you stop testing a running server, and you start testing how your function responds to events and SDK states. Here is a simple, practical example for each testing, using modern AWS SDK v3 syntax.

1. Unit Testing: Jest + Mock Payloads & SDK Client Mocking

In unit tests, you don't call real AWS services. You pass a simulated API Gateway event to your handler, and you mock the AWS SDK so it returns predictable data instead of hitting live infrastructure.

The Code Under Test (`src/handler.ts`)

import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient, GetCommand } from '@aws-sdk/lib-dynamodb';

const ddbClient = new DynamoDBClient({});
const docClient = DynamoDBDocumentClient.from(ddbClient);

export const handler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {
  const userId = event.pathParameters?.id;

  if (!userId) {
    return { statusCode: 400, body: JSON.stringify({ message: 'Missing ID' }) };
  }

  // Fetch from DynamoDB
  const result = await docClient.send(new GetCommand({
    TableName: process.env.USERS_TABLE,
    Key: { id: userId }
  }));

  if (!result.Item) {
    return { statusCode: 404, body: JSON.stringify({ message: 'User not found' }) };
  }

  return {
    statusCode: 200,
    body: JSON.stringify(result.Item),
  };
};

The Jest Unit Test (`tests/unit.test.ts`)

Instead of the legacy aws-sdk-mock, the modern standard for AWS SDK v3 is aws-sdk-client-mock.

import { handler } from '../src/handler';
import { APIGatewayProxyEvent } from 'aws-lambda';
import { mockClient } from 'aws-sdk-client-mock';
import { DynamoDBDocumentClient, GetCommand } from '@aws-sdk/lib-dynamodb';

const ddbMock = mockClient(DynamoDBDocumentClient);

describe('Lambda Handler Unit Test', () => {
  beforeEach(() => {
    ddbMock.reset();
    process.env.USERS_TABLE = 'TestTable';
  });

  it('should return 200 and user data when user exists', async () => {
    // 1. Mock the AWS SDK Behavior
    ddbMock.on(GetCommand).resolves({
      Item: { id: 'user-123', name: 'Alice' }
    });

    // 2. Shape the Mocked APIGatewayProxyEvent Payload
    const mockEvent = {
      pathParameters: { id: 'user-123' }
    } as unknown as APIGatewayProxyEvent;

    // 3. Execute handler directly
    const response = await handler(mockEvent);

    expect(response.statusCode).toBe(200);
    expect(JSON.parse(response.body)).toEqual({ id: 'user-123', name: 'Alice' });
  });
});

2. Integration Testing: LocalStack

Integration tests verify that your code accurately interacts with auxiliary services, without relying on real AWS. LocalStack spins up containerized versions of AWS services inside your CI/CD pipeline or local environment.

To test against LocalStack, your application code just needs to point its AWS Clients to the local Docker container URL (usually http://localhost:4566).

The Integration Test Configuration (`tests/integration.test.ts`)

import { DynamoDBClient, CreateTableCommand } from '@aws-sdk/client-dynamodb';
import { DynamoDBDocumentClient, PutCommand } from '@aws-sdk/lib-dynamodb';
import { handler } from '../src/handler';
import { APIGatewayProxyEvent } from 'aws-lambda';

// Point the client to LocalStack instead of real AWS
const localStackConfig = {
  endpoint: 'http://localhost:4566',
  region: 'us-east-1',
  credentials: { accessKeyId: 'test', secretAccessKey: 'test' }
};

const ddbClient = new DynamoDBClient(localStackConfig);
const docClient = DynamoDBDocumentClient.from(ddbClient);

describe('DynamoDB Integration via LocalStack', () => {
  beforeAll(async () => {
    // Setup: Create the table in LocalStack before tests run
    await ddbClient.send(new CreateTableCommand({
      TableName: 'LocalUsersTable',
      AttributeDefinitions: [{ AttributeName: 'id', AttributeType: 'S' }],
      KeySchema: [{ AttributeName: 'id', KeyType: 'HASH' }],
      BillingMode: 'PAY_PER_REQUEST'
    }));

    process.env.USERS_TABLE = 'LocalUsersTable';
  });

  it('should successfully read data actually written to LocalStack', async () => {
    // Seed real data into the LocalStack DynamoDB container
    await docClient.send(new PutCommand({
      TableName: 'LocalUsersTable',
      Item: { id: 'user-456', name: 'Bob' }
    }));

    const mockEvent = { pathParameters: { id: 'user-456' } } as unknown as APIGatewayProxyEvent;

    // Run the handler — it will communicate directly with LocalStack
    const response = await handler(mockEvent);

    expect(response.statusCode).toBe(200);
    expect(JSON.parse(response.body).name).toBe('Bob');
  });
});

3. End-to-End (E2E) Testing: Newman

In E2E testing, your application is fully deployed to a staging environment. You treat it entirely as a black box—sending actual HTTP requests to the live API Gateway URL. Newman allows you to run Postman collections natively via the CLI.

The Testing Workflow

You export a Postman collection containing your test assertions (my-api-tests.json).
You execute it via your terminal or CI environment against the live URL.

# Execute your Postman test collection against your deployed AWS Staging endpoint
newman run ./tests/my-api-tests.json --env-var "baseUrl=https://xyz123.execute-api.us-east-1.amazonaws.com/staging"

4. Local Execution: AWS SAM Local

Before deploying to staging, you want to see how your Lambda executes inside an isolated Docker container mimicking the real AWS Lambda runtime environment. AWS SAM achieves this.

Step A: Define your event payload (`events/mock-request.json`)

{
  "pathParameters": {
    "id": "user-789"
  }
}

Step B: Invoke the function via CLI

Run the SAM build command to compile your TypeScript down to JavaScript, then use sam local invoke to execute the function with your mock event.

# 1. Compile TypeScript and build resources
sam build

# 2. Locally invoke the function using the mock event
sam local invoke UserHandlerFunction --event events/mock-request.json

Hope youe find it helpful
Hash

1- AWS Serverless: Designing a serverless API: Order Processing API (E-commerce)

Hamid Shoja — Thu, 11 Jun 2026 15:40:00 +0000

Modern enterprise order processing architectures must decouple synchronous client demands from asynchronous backend dependencies. Here I'll detail a highly scalable, fault-tolerant design built on AWS. By utilizing an automated API Gateway entry point, specialized Amazon Cognito authentication, optimized AWS Lambda logic blocks, an engineered RDS Proxy connection layer, and an event-driven SQS/EventBridge core, the design guarantees isolation, cost efficiency, and sub-millisecond structural routing.

The Scenario

User places an order → payment is processed → inventory updated → confirmation email sent

Client → API Gateway (Cognito auth + validation)
       → Order Lambda (business logic + DynamoDB write)
       → SQS (payment queue)
       → Payment Lambda → EventBridge
                        → Inventory Lambda
                        → Notification Lambda (SES)

1- Entry Point — API Gateway

REST endpoint: POST /orders

Request validation via API Gateway models (reject malformed payloads instantly, no Lambda invoked)

Auth via Cognito User Pool Authorizer — validates JWT token on every request

How It Works

The Request Hits: A client sends a POST /orders request with a JWT token in the header.
Auth Check: API Gateway automatically intercepts the request and validates the JWT against the Cognito User Pool. If expired or spoofed, it returns 410 Gone / 401 Unauthorized right there.
Payload Check: Next, it compares the body against your JSON Schema Model. If a required field like customer_id is missing, API Gateway instantly drops it with a 400 Bad Request.
The Win: Your downstream services (like Lambda) are never invoked for bad/unauthorized requests, saving compute costs and protecting against basic DDoS or bad actor spam.

Gotchas

Cognito Latency: While Cognito authorizers are native, they can add a slight latency overhead to your API's P99 metrics during peak traffic. For massive global scale, some enterprises migrate to custom Lambda Authorizers that cache tokens in ElastiCache (Redis).
Model Validation Limits: API Gateway's built-in validator is great for structural checks (e.g., "is this an integer?"), but it cannot do business logic validation (e.g., "is this item SKU actually in our database?"). You still need lightweight validation downstream.
Throttling: Always configure Usage Plans and Rate Limiting at this layer. Without it, a rogue client could overwhelm your backend before your auto-scaling kicks in.

2. Business Logic — Lambda (TypeScript)

Bundled with esbuild — tiny bundle, fast cold start

Uses aws-lambda-powertools for structured logging + correlation IDs + tracing

How It Works

Bundling (esbuild): Strips unused node modules, removes comments, tree-shakes dead code, and transpiles TypeScript down to a single, lightweight JavaScript file. Less code means the internal Lambda service downloads and instantiates your code container incredibly quickly.

The Execution Lifecycle: * Initialization (Cold Start): Lambda boots the container and runs code outside the handler function. By not putting heavy SDK packages here, initialization remains ultra-fast.

Invocation (Warm Start): The handler executes. Because DynamoDBClient was stored in a global variable during the first run, subsequent warm invocations bypass the heavy initialization and dynamic import() statement entirely.

Powertools Observability: Rather than using console.log, Powertools outputs structured JSON logs. If a customer has an issue, you can trace that specific correlationId seamlessly across your logs, metrics, and X-Ray traces.

Gotchas

The Memory vs. CPU Trap: Developers often assign Lambda the minimum memory (128MB) to "save money". The catch: AWS scales CPU and network performance proportionally with memory. Upgrading to 1024MB or 1536MB often speeds up cold starts and execution times so drastically that the execution costs remain identical or cheaper while delivering a superior P99 response time.
VPC Cold Starts: If your business logic needs to query an RDS database inside a private VPC, Lambda must attach an Elastic Network Interface (ENI). While AWS optimized this significantly using Hyperplane, it can still add a predictable overhead to cold starts compared to a Lambda running outside a VPC.
Global State Pollution: Global variables (like DynamoDBClient above) persist across warm starts. If you modify a global variable inside a handler (e.g., global error arrays or temporary user arrays), it will bleed into the next customer's request. Always reset request-specific states inside the handler.

Conceptual Application Code (TypeScript)

// 1. GLOBAL SCOPE: Warm start re-use (No heavy SDKs imported here)
import { Logger } from '@aws-lambda-powertools/logger';
import { Tracer } from '@aws-lambda-powertools/tracer';

const logger = new Logger();
const tracer = new Tracer();

// 2. LAZY LOADING: Dynamically imported only when needed inside handler
let DynamoDBClient: any = null; 

export const handler = async (event: any, context: any) => {
  // Clear state/set correlation context
  logger.addContext(context);
  const correlationId = event.headers['X-Correlation-Id'] || context.awsRequestId;
  logger.appendKeys({ correlationId });

  try {
    const body = JSON.parse(event.body);

    // Business Logic Validation (Stock/Price Check)
    const isStockAvailable = await checkStock(body.items);
    if (!isStockAvailable) {
      return { statusCode: 422, body: JSON.stringify({ message: "Out of stock" }) };
    }

    // Lazy load the heavy SDK right before database write
    if (!DynamoDBClient) {
      const { DynamoDBClient: DB } = await import('@aws-sdk/client-dynamodb');
      DynamoDBClient = new DB({});
    }

    // Proceed with processing...
    return { statusCode: 201, body: JSON.stringify({ orderId: "12345" }) };

  } catch (error) {
    logger.error("Order processing failed", error as Error);
    return { statusCode: 500, body: JSON.stringify({ message: "Internal Error" }) };
  }
};

3. Database — RDS

table design — orders, users, inventory

RDS proxy

How It Works

The Serverless Connection Problem: Relational databases assign memory to every single open connection. If your API gets a spike in traffic and Lambda scales up to 2,000 concurrent containers, they will try to open 2,000 direct database connections, instantly crashing RDS with an "out of memory" error.
Enter RDS Proxy: Lambda functions point to the RDS Proxy endpoint instead of the database. The proxy keeps a continuous, optimized pool of connections open to RDS.
Multiplexing: When a Lambda function finishes executing an order (takes 50ms), RDS Proxy immediately claims that connection back and hands it to a different Lambda instance. Your DB only ever sees a stable, flatlined connection count.

Gotchas

Session Pinning: RDS Proxy's primary job is to multiplex connections. However, if your Lambda executes certain commands—like preparing a dynamic SQL statement, changing session variables, or utilizing temporary tables—RDS Proxy gets confused and performs

-Session Pinning. This ties that specific Lambda instance to that specific database connection until the Lambda dies, completely destroying the benefits of the proxy pool. Keep queries standard and stateless.

The IAM Secret Storage Lag: RDS Proxy reads the DB password directly from AWS Secrets Manager. If you rotate your database password in an emergency, there can be a tiny window (seconds) of cached credential lag where the proxy might drop connection handshakes.
DynamoDB vs. RDS: If you genuinely want a Partition Key (userId) and Sort Key (orderId), you should drop RDS and switch to Amazon DynamoDB. In an enterprise context, DynamoDB handles high-scale transactional orders infinitely better without needing an RDS Proxy, VPC configurations, or connection pools, though you sacrifice the ability to run complex SQL JOIN statements across your tables.

High-Level Relational Database Design (DDL)

-- 1. Users Table
CREATE TABLE users (
    user_id UUID PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- 2. Orders Table (Composite Index handles the lookups)
CREATE TABLE orders (
    order_id UUID PRIMARY KEY,
    user_id UUID REFERENCES users(user_id) NOT NULL,
    total_amount DECIMAL(10, 2) NOT NULL,
    status VARCHAR(50) NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
-- Accelerates "Get all orders for a specific User ordered by date"
CREATE INDEX idx_user_orders ON orders(user_id, created_at DESC);

-- 3. Inventory Table
CREATE TABLE inventory (
    item_id UUID PRIMARY KEY,
    sku VARCHAR(100) UNIQUE NOT NULL,
    stock_quantity INT NOT NULL CHECK (stock_quantity >= 0),
    price DECIMAL(10, 2) NOT NULL
);

4. Async Flow — SQS + EventBridge

After order saved → Lambda drops message to SQS (payment queue)
Payment Lambda picks it up, processes payment
On success → publishes event to EventBridge
EventBridge fans out to:Inventory Lambda (update stock)
Notification Lambda (send email via SES)

How It Works

The Hand-off: Once the Business Logic Lambda from Part 2 saves the order as PENDING, it drops a lightweight message (e.g., { "orderId": "abc-123", "amount": 99.00 }) directly into SQS. The API Gateway can instantly return a 202 Accepted response to the client. The user isn't left waiting on a spinner while the payment processes.
The Consumer: The Payment Lambda continuously polls SQS. It talks to your third-party payment gateway (like Stripe).
The Broadcast: On successful payment, the Payment Lambda fires a single structured JSON event into EventBridge. It doesn't know—or care—who needs this information.
The Fan-Out: EventBridge evaluates the incoming event pattern. Because it matches a Payment.Success type, it acts as a traffic cop and duplicates the event, executing both the Inventory Lambda and the Notification Lambda concurrently.

Gotchas

The Visibility Timeout Trap: Your SQS visibility_timeout_seconds configuration is hyper-critical. When a Lambda instance reads a message, that message is hidden from other instances for X seconds. If your Payment Lambda hits an API lag with Stripe and takes 31 seconds to complete, but your visibility timeout is set to 30 seconds, SQS will make that message visible again. A second Lambda will pick it up and process the payment a second time. Rule of thumb: Visibility timeout must always be > 6 times your Lambda function timeout.
Idempotency is Non-Negotiable: Because SQS guarantees at-least-once delivery (network hiccups can cause duplicate messages), your consumers must be idempotent. The Payment Lambda must verify with your DB or payment processor if orderId: abc-123 has already been charged before processing it.
EventBridge Latency vs. Throughput: EventBridge is built for massive, complex filtering and cross-microservice routing, but it has a slightly higher delivery latency (typically 20–50ms) compared to Amazon SNS (Simple Notification Service). If you require near-instant sub-millisecond fan-out and don't need advanced JSON schema filtering, an SNS Topic might be a faster alternative, though it lacks EventBridge's robust schema registry capabilities.

Conclusion

Building a enterprise-scale order processing engine on AWS requires balancing system decoupled isolation with a smooth user experience.

I hope you liked the article and you found it helpful.

Have questions about this high-level design, or want to discuss alternatives like DynamoDB single-table design? Let me know in the comments below!

Reclaim Your Mac Disk Space

Hamid Shoja — Fri, 22 May 2026 11:01:52 +0000

Your Mac is nearly full. That 98% capacity warning is real, and it will start causing build failures, crashes, and slowdowns if you ignore it.

This guide walks through what's eating your disk and exactly how to clean it — fast.

Step 1: Diagnose First

Always start with a full picture before deleting anything.

df -h

Look at the Avail column on /dev/diskXXX. If you see less than 1GB, you're in trouble.

Then find the biggest offenders in your home folder:

du -sh ~/Library/Caches/* 2>/dev/null | sort -rh | head -20
du -sh ~/Library/Application\ Support/* 2>/dev/null | sort -rh | head -20

Step 2: Clear the Caches (Safe, ~N GB+)

~/Library/Caches is safe to delete. Every app rebuilds its cache on next launch but you can pick some specific ones too

Step 3: Tame Application Support

This is where the real weight lives. Unlike Caches, be selective here — some folders contain important app data.

du -sh ~/Library/Application\ Support/* 2>/dev/null | sort -rh | head -25

For may Docker Desktop or Rancher Desktop stores its entire Linux VM + all container images.

If you no longer use Docker just remove it entirly

Step 4: Clean Docker Images

Old branch images from months ago are dead weight. Check what you have:

docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}\t{{.CreatedSince}}"

See how much a full prune would recover:

docker system df

Remove everything not currently running:

docker system prune -a

Or, conservative — only dangling (<none>) images:

docker image prune

Step 5: Verify You Recovered Space

df -h

Check the Avail column again. You should be back to several GBs of free space.

The Developer's Mindset on Disk Hygiene

Disk bloat is gradual. You don't notice until you're at 100% and your docker build silently fails.

A few habits prevent this:

Run docker system prune after finishing a feature branch
Clear ~/Library/Caches monthly — it's always safe
Keep an eye on ~/Library/Application Support/rancher-desktop if you use container runtimes
Old branch images in Docker are never coming back — prune them freely

I hope you found it helpful

A tip from a senior engineer

Hamid Shoja — Mon, 19 Jan 2026 18:12:06 +0000

The Trade-off: Clean Testing vs. Code Brevity in Modern JS

Hamid Shoja ・ Jan 19

#javascript #frontend #node #backend

Uvicorn in Modern Python APIs

Hamid Shoja — Mon, 19 Jan 2026 18:10:24 +0000

A quick guide to why Uvicorn is essential for Python developers in 2026, how to use it, and how it stacks up against other languages.

What is Uvicorn?

Uvicorn is a high-speed ASGI (Asynchronous Server Gateway Interface) server. While frameworks like FastAPI or Starlette help you write your code, Uvicorn is the "engine" that actually runs the code and handles web requests from users.

Why do we use it?

In the past, Python servers (WSGI) could only handle one request at a time per process. Uvicorn uses an asynchronous event loop, allowing it to handle thousands of concurrent connections (like WebSockets or long-polling) without waiting for one to finish before starting the next.

Quick Start Example

Install:

pip install uvicorn

Code (main.py):

async def app(scope, receive, send):
    await send({
        'type': 'http.response.start',
        'status': 200,
        'headers': [[b'content-type', b'text/plain']],
    })
    await send({
        'type': 'http.response.body',
        'body': b'Hello, Dev.to!',
    })

Run:

uvicorn main:app --reload

Alternatives to Consider

Hypercorn: Great if you need HTTP/3 support.
Daphne: The go-to for Django Channels.
Granian: A Rust-based runner for those who need even more speed.

Architecture Comparison (Python vs. The World)

How does Uvicorn's "Event Loop" compare to other languages in 2026?

Perfomance

Unicorn: ~150k requests/sec; excellent for I/O but limited by the Global Interpreter Lock (GIL).

Nodejs: ~600k requests/sec; highly optimized for I/O-bound web traffic.
Go (Goroutines): >1M requests/sec; built-in concurrency makes it a "workhorse" for microservices.
Rust (Tokio/Axum): >1M requests/sec; the fastest model due to lack of garbage collection and zero-cost abstractions.

Cpu-intensive tasks

In a single-threaded async loop, one heavy CPU calculation can freeze the entire server. We should offload blocking tasks to a thread pool or a separate worker (like Celery/Arq) to keep the Uvicorn loop responsive.

Example: Use run_in_executor for blocking code.

import asyncio

@app.get("/heavy-task")
async def heavy_task():
    # Don't run blocking code directly; offload it to keep the loop free
    loop = asyncio.get_running_loop()
    result = await loop.run_in_executor(None, some_blocking_heavy_math)
    return result

Summary

If you are building a modern Python web app, Uvicorn is the standard choice. It balances the ease of Python with the speed required for modern, real-time web applications.

Follow for more bite-sized dev tutorials! 🚀
HASH

refs:
https://medium.com/@yogeshkrishnanseeniraj/scaling-django-async-workers-uvicorn-gunicorn-celery-and-redis-full-benchmarking-guide-fef057069e96#:~:text=Uvicorn%20alone%20provides%20excellent%20async,with%20low%20to%20moderate%20traffic.
https://stackoverflow.com/questions/21485920/single-threaded-event-loop-vs-multi-threaded-non-blocking-worker-in-node-js#:~:text=As%20a%20minor%20addendum%20I,57.8k10%2093%20131
https://www.youtube.com/watch?v=n0KETvEqiCk&t=57

The Trade-off: Clean Testing vs. Code Brevity in Modern JS

Hamid Shoja — Mon, 19 Jan 2026 17:57:48 +0000

Hey fellow devs! 👋

In modern JavaScript and TypeScript development, we are constantly balancing two opposing forces: the desire for Code Brevity (writing concise, minimal code) and the need for Clean Testing (writing code that is easy to isolate and verify).

Often, the code that is fastest to write is the hardest to test.

Conversely, code designed for testability often looks "boilerplate-heavy" at first glance.

Let's explore this trade-off through real-world examples, moving from common patterns to the mindset required for architecting long-term scalable systems.

Round 1: The Environment Variable Dilemma

This is a classic debate that often appears in code reviews. How do you access environment variables like API keys or feature flags provided by Vite, Webpack, or Node?

The "Brief" Approach (Static Constants)

The fastest way is to read the variable directly and store it in a constant. It's one line of code. It's simple.

// config.ts
export const IS_PRODUCTION = import.meta.env.PROD;
export const API_URL = import.meta.env.VITE_API_URL;
// myFeature.ts
import { IS_PRODUCTION } from './config';
if (IS_PRODUCTION) {
  // do scary real things
}

The Hidden Cost

This code is brief, but it is tightly coupled to the build system's global state.

When you write a unit test for myFeature.ts, the IS_PRODUCTION constant is evaluated immediately when the test file loads. Once that constant is set to true or false, it is extremely difficult to change it within the same test suite run.

To test both scenarios, you often have to resort to "stubbing globally" , telling your test runner (like Vitest or Jest) to fundamentally alter how the JavaScript runtime behaves.

// ❌ Messy Global Testing
vi.stubEnv('PROD', 'true'); 
// Now EVERY test thinks it's prod until you remember to unstub it.
// If you forget, other tests break mysteriously.

The "Testable" Approach (Getter Functions)

The alternative is to wrap the access in a function. It adds boilerplate. It feels slightly redundant.

// config.ts
// It's just a function returning a value
export const getIsProduction = () => import.meta.env.PROD;
// myFeature.ts
import { getIsProduction } from './config';
// We call the function now
if (getIsProduction()) {
  // do scary real things
}

The Benefit: Creating a "Seam"

From a Senior Engineering perspective, we have just created a Seam.

A Seam is a concept (popularized by Michael Feathers) referring to a place where you can alter the behavior of your program without editing the source code.

In our tests, we no longer need to hack the global environment. We just need to spy on a standard JavaScript function.

// ✅ Clean Isolated Testing
import * as Config from './config';
test('does scary things only in prod', () => {
  // Create the seam just for this test block
  const spy = vi.spyOn(Config, 'getIsProduction');
  spy.mockReturnValue(true);
  // run expectations...
  spy.mockReturnValue(false);
  // run other expectations...
});

The testable approach trades brevity for isolation and control.

Round 2: Dealing with Time

Another common area where brevity hurts testing is handling current time.

The "Brief" Approach (Direct Access)

Imagine a function that determines if a discount code is expired.

// discount.ts
export const isDiscountExpired = (expiryDate: Date): boolean => {
  // Brevity wins here:
  const now = new Date(); 
  return now > expiryDate;
}

This code is incredibly short. But it is non-deterministic.

If you write a test today that says "Expires tomorrow should return false", that test will pass today. But if you run that same test suite tomorrow, it will fail.

To test this, you again have to rely on heavy-handed global tool hacks like "Fake Timers" to freeze the system clock of the test runner.

The "Testable" Approach (Dependency Injection)

To make this testable, we need to take control away from the function itself and inject the dependency (time).

We can do this via a defaulted parameter (a lightweight form of Dependency Injection).

// discount.ts
// We allow 'now' to be passed in, but default to current time
export const isDiscountExpired = (
  expiryDate: Date, 
  now: Date = new Date() // Default value makes it easy to use in app code
): boolean => {
  return now > expiryDate;
}

Now the test is trivial and deterministic. We don't need to freeze system time; we just pass in a fixed date.

// ✅ Clean Testing
test('checks expiration', () => {
  const fixedNow = new Date('2024-01-01T10:00:00Z');
  const tomorrow = new Date('2024-01-02T10:00:00Z');
  // We inject our fixed time, guaranteeing the result forever
  expect(isDiscountExpired(tomorrow, fixedNow)).toBe(false);
});

The Senior Engineer's Mindset

When you are a junior or mid-level developer, your primary metric is often "velocity" , how fast can I ship this feature? Brevity helps velocity in the short term.

As you advance to senior or principal roles, your primary metrics shift to maintainability, stability, and risk reduction.

Shift Left

We want to "shift left" on bugs , finding them during unit tests on a developer's machine, rather than in QA or production.

If code is brief but relies on global state (like import.meta.env or new Date()), developers will instinctively avoid writing tests for it because writing those tests is difficult and painful.

By introducing slight amounts of boilerplate , creating getter functions, injecting dependencies, creating seams , we lower the friction required to write a test.

Conclusion

Choose Brevity for throwaway prototypes, simple scripts, or incredibly confined UI components that have zero logic.
Choose Testability for business logic, configuration, helpers, and anything that your application relies on to function correctly over time.

It looks like more code today, but it buys you peace of mind tomorrow.

If this helped, give it a heart!
Hash

Understanding MCP Through a Simple Example: A Practical Introduction

Hamid Shoja — Sat, 17 Jan 2026 18:41:59 +0000

Hey fellow devs! 👋

I’ve been working with MCP fairly often and like most of us, I learn best by actually building something. Not something production-ready or revolutionary — just something simple enough to understand what MCP actually does.

That’s why I built a basic currency converter using MCP. It’s intentionally simple, but that’s the point.

Let me walk you through what can be learned from this example.

A Personal Take First

When new protocols and frameworks come out, I want to answer one question: “What problem does this actually solve?”

This currency converter teaches exactly how MCP works, and that’s worth sharing.

The Learning Goal

Before writing any code, I want you to understand one specific thing:

How does AI actually communicate with external tools through MCP?

What MCP Actually Does

Here’s what I learned by building this:

Without MCP:

You: "Is ¥10,000 enough to buy a $60 game?"
AI: "I don't have access to current exchange rates, 
     but you can check [some website]."

With MCP:

You: "Is ¥10,000 enough to buy a $60 game?"
AI: 
1. Realizes it needs an exchange rate
2. Sees there's a get_exchange_rate tool available
3. Calls: get_exchange_rate(from="JPY", to="USD", amount=10000)
4. Gets: 10000 JPY = 65.83 USD
5. Responds: "Yes, ¥10,000 is approximately $65.83 USD, 
              so you'd have $5.83 left after buying the game."

The key insight: MCP is just a standardized way for AI to discover and use your tools.

The Example Architecture

My simple implementation looks like this:

User sends natural language prompt
Hono API receives it
API gets list of provided MCP server tools (get_exchange_rate)
API Sends prompt + tools to Claude AI
Claude AI interprets when user wants a tool
In the interception step API calls MCP tool, getting the actual rate
API sends another request to Claude AI including actual rate + prompt
User gets their answer It’s basic. And that’s exactly why it’s useful for learning.

Look at the MCP tool definition:

{
  name: "get_exchange_rate",
  description: "Get exchange rate between currencies",
  inputSchema: {
    type: "object",
    properties: {
      from_currency: { type: "string" },
      to_currency: { type: "string" },
      amount: { type: "number", optional: true }
    }
  }
}

This tool just returns exchange rates. That’s it.

The AI takes care of everything else.

Now Let’s take a closer look at the implementation steps together.

1- User sends natural language prompt

"Is ¥10,000 enough to buy a $60 game?"

2- API receives it

app.post('/api/chat')
    const { prompt } = await c.req.json();

3- API gets list of provided MCP server tools (get_exchange_rate)

const tools = await mcpClient.listTools();
4- API Sends prompt + tools to Claude AI

const response = await anthropic.messages.create({
      tools: tools,
      messages: [{
        role: 'user',
        content: prompt
      }]
    });

5- Claude AI interprets When user wants an action that provided in tools get_exchange_rate

while (response.stop_reason === 'tool_use')
   const toolUse = response.content.find(block => block.type === 'tool_use');

6- In the interception step API calls MCP tool, getting the actual rate

const toolResult = await mcpClient.callTool({
        name: toolUse.name,
        arguments: toolUse.input,
      });

7- API sends another request to Claude AI including actual rate + prompt

response = await anthropic.messages.create({
        tools: tools,
        messages: [
          { role: 'user', content: prompt }, // original prompt
          {
            role: 'user',
            content: [{
              type: 'tool_result',
              tool_use_id: toolUse.id,
              content: JSON.stringify(toolResult.content) // rate info
            }]
          }
        ]
      });

8- User gets their answer

    const finalText = response.content
    return finalText 

// Yes, ¥10,000 is approximately $65.83 USD, 
//              so you'd have $5.83 left after buying the game

Why This Simple Example Matters

Here’s what this simple example demonstrates:

1.** Tool Discovery**
The AI can see what tools are available and understand when to use them based on the description.

Parameter Extraction The AI automatically extracts structured parameters from messy natural language:

“Is ¥10,000 enough for $60?” → from="JPY", to="USD", amount=10000
“How many dollars is 50 euros?” → from="EUR", to="USD", amount=50

Context Awareness The AI can handle complex queries:

“I have 5 euros in cash and 20 in my bank, total in USD?”
AI does: 5 + 20 = 25, then calls the tool with 25 EUR

Natural Responses The AI formats the tool’s response naturally instead of just dumping JSON.

See It Working

I recorded a quick demo showing different types of queries being handled:

Press enter or click to view image in full size

Nothing fancy, just the basic flow working as expected.

Setting It Up (For Learning Purposes)

If you want to try this yourself to understand MCP:

git clone https://github.com/hshoja/Currency-Exchange-MCP-Service
npm install
cp env.example .env
# Add your API keys to .env
npm run dev

You’ll need:

Anthropic API key (for Claude AI)
Freecurrencyapi key (for exchange rates)

Then just send POST requests with natural language prompts:

{
  "prompt": "What is 100 USD in EUR?"
}

The Real Takeaway

After building this simple example, We now understand:

MCP is not about building smarter APIs.

It’s about building simple, focused tools and letting AI be the smart layer that connects them to human intent.

Your tool can be dumb. It should be dumb. Just do one thing well, and let AI the rest.

Potential Use Cases (Beyond This Simple Example)

While the currency converter is basic, the pattern scales to more interesting problems, have a look to these examples.

AI Agent Crypto MCP Trading : an example which shows how create an mcp that opens or closes positions in a crypto platform by natural language
Kali Linux HACKING MCP : running kali commands for hacking by natural language
Natural language to SQL: connect and query the database by natural language
Building an agentic appointment scheduling app

The complexity isn’t in MCP itself — it’s in the tools you build and connect.

Check Out The Code

The full repository includes:

Feel free to clone it, modify it, or use it as a reference while learning MCP yourself.

Are you learning MCP too? Have you built simple examples to understand new tech? I’d love to hear about it — drop a comment!

P.S. — If this helped you understand MCP a bit better, give it a like! And remember: simple examples are valid examples.

How simultaneously swapping unique IDs in Postgres

Hamid Shoja — Mon, 08 Dec 2025 18:29:05 +0000

Hi friends

Here's a quick tip for when you're working with Postgres, this came in clutch for me when I had to use DEFERRABLE INITIALLY IMMEDIATE

I'm sharing this with a practical example where two rows in a table must exchange unique values simultaneously within the same transaction. This is common when swapping unique IDs or handling cyclic dependencies.

Example: Swapping Unique Teacher IDs

Consider a classes table where each class has a unique teacher_id, but you need to swap the teachers between two classes. The UNIQUE constraint would normally prevent this in a single UPDATE statement because, mid-operation, there would temporarily be duplicate teacher_id values.

So we can Define the table with a unique constraint that is DEFERRABLE INITIALLY IMMEDIATE:

CREATE TABLE classes (
    id INT PRIMARY KEY,
    teacher_id INT NOT NULL UNIQUE DEFERRABLE INITIALLY IMMEDIATE,
    class_name VARCHAR(100)
);
-- Insert initial data
INSERT INTO classes VALUES (1, 101, 'Biology'), (2, 102, 'Chemistry');

By default, the database checks the uniqueness after every statement.
Perform the swap within a transaction by explicitly deferring the constraint check:

BEGIN;
-- Temporarily set the specific constraint to DEFERRED mode for this transaction
SET CONSTRAINTS classes_teacher_id_key DEFERRED;

-- The update statements can now run without immediate failure
UPDATE classes SET teacher_id = 102 WHERE id = 1; -- Temporarily creates duplicate 102
UPDATE classes SET teacher_id = 101 WHERE id = 2; -- Resolves the duplicate

COMMIT;
-- At the COMMIT point, the database checks all deferred constraints.
-- Since the final state is valid (101 and 102 are unique again), the transaction succeeds.

If you tried these updates without the BEGIN; ... SET CONSTRAINTS DEFERRED; ... COMMIT; block, the first UPDATE statement would immediately fail due to the INITIALLY IMMEDIATE setting, which acts as a per-statement check.

this example demonstrate how to use DEFERRABLE INITIALLY IMMEDIATE constraints to swap unique values within a transaction:

Hope that helped!

Hash

React 19.2's useEffectEvent vs our Custom useEventCallback

Hamid Shoja — Sun, 05 Oct 2025 13:02:20 +0000

Hey fellow React devs! 👋

So React 19.2 dropped and brought us useEffectEvent - a new hook that solves a problem many of us have been tackling with custom solutions. If you're like me and have been using a custom useEventCallback hook (or something similar), you're probably wondering: "Should I ditch my trusty custom hook for this new official one?"

BTW: if you interested to read it from medium.

Let me break it down for you based on some real-world experience.

The Problem Both Hooks Solve

First, let's talk about why these hooks exist. You know that annoying situation where you want to access the latest state/props/reference in a useEffect without adding them to the dependency array? Yeah, that one:

function Page({ url }) {
  const { items } = useContext(ShoppingCartContext);
  const numberOfItems = items.length;

  const onNavigate = useCallback((visitedUrl) => {
    logVisit(visitedUrl, numberOfItems);
  },[numberOfItems]);

  useEffect(() => {
    onNavigate(url);
  }, [url, onNavigate]); // if not passing onNavigate getting lint error

  // ...
}

In this example, the Effect should re-run after a render when url changes (to log the new page visit), but it should not re-run when numberOfItems changes that creates a new ref for onNavigate causing new log for every numberOfItems up and down!

So we need a way to get a persistent ref for onNavigate function including the latest numberOfItems.

Now if you use new hook useEffectEvent instead of useCallback this problem gets solved:

function Page({ url }) {
  const { items } = useContext(ShoppingCartContext);
  const numberOfItems = items.length;

  const onNavigate = useEffectEvent((visitedUrl) => {
    logVisit(visitedUrl, numberOfItems);
  });

  useEffect(() => {
    onNavigate(url);
  }, [url]);

  // ...
}

This problem already gets solved by another hook called useEventCallback by creating stable function reference.

Meet the Custom Champion: useEventCallback

This is what many of us have been building:

export function useEventCallback<T extends (...args: any[]) => any>(fn: T): T {
  const ref = useRef(fn)

  useEffect(() => {
    ref.current = fn
  })

  return useCallback((...args: any[]) => ref.current.apply(void 0, args), []) as T
}

It's reliable, battle-tested, and works everywhere.

CAN We Now Swap Them?

Here's where it gets interesting. These hooks are not drop-in replacements for each other.

useEventCallback instead of useEffectEvent:

Yes you can, the result is almost the same, example:

function Page({ url }) {
  const { items } = useContext(ShoppingCartContext);
  const numberOfItems = items.length;

  const onNavigate = useEventCallback((visitedUrl) => {
    logVisit(visitedUrl, numberOfItems);
  });

  useEffect(() => {
    onNavigate(url);
  }, [url]);

  // ...
}

But there are some caveats:

React's internal magic > our clever hacks, so maybe we're missing some React optimizations
The official API is designed for React's future - You need perfect Concurrent Mode compliance

useEffectEvent instead of useEventCallback:

✅ You CAN use useEffectEvent when you need stable event handlers for Effect deps

// ✅ useEffectEvent works
const handleClick = useEventCallback(() => doSomething());
useEffect(() => { 
  handleClick() 
}, [])

❌ You CANNOT use useEffectEvent when:

1. You need event handlers for JSX

// ✅ useEventCallback works
const handleClick = useEventCallback(() => doSomething());
return <button onClick={handleClick}>Click me</button>;

// ❌ useEffectEvent is NOT for this

2. You're passing callbacks to child components

// ✅ Safe with useEventCallback
const onChildEvent = useEventCallback(handleChildEvent);
return <ChildComponent onEvent={onChildEvent} />;

// ❌ Don't pass useEffectEvent callbacks as props

3. You need async operations

// ✅ useEventCallback handles async fine
const handleAsync = useEventCallback(async (id) => {
  const result = await fetchData(id);
  return result;
});

// ❌ useEffectEvent has restrictions with async

My Take: Use Both (For Now)

Here's my practical recommendation:

Keep using useEventCallback for general stable function references, event handlers, and callback props
Adopt useEffectEvent specifically for functions called within effects

They serve different purposes, even though they solve similar problems.

The Migration Path

If you're on React 19.2+, start migrating effect-specific uses:

// Before
const logEvent = useEventCallback((data) => {
  analytics.track('event', data, currentUser.id);
});

useEffect(() => {
  logEvent(someData);
}, [someData]);

// After
const logEvent = useEffectEvent((data) => {
  analytics.track('event', data, currentUser.id);
});

useEffect(() => {
  logEvent(someData);
}, [someData]);

But keep useEventCallback for everything else!

The Bottom Line

Don't feel bad about your custom hook - it's been doing great work! useEffectEvent isn't here to replace it entirely, but to provide a more specialized, optimized solution for a specific use case.

What's your experience been with these hooks? Are you planning to migrate, or sticking with your custom solutions? Drop a comment - I'd love to hear your thoughts!

DEV Community: Hamid Shoja

5- AWS Serverless:: Caching and Event-Driven Design

Layer 1: Edge Caching (AWS CloudFront)

Simple Example:

Layer 2: Application Layer Caching (Amazon ElastiCache Redis)

Simple Example:

Layer 3: Database Caching (Amazon DAX)

Compute Optimization: Lambda Execution Context Reuse

Simple Example (Code Context):

Event-Driven Cache Invalidation

Simple Example:

Summary

4- AWS Serverless: Event-Driven Design: SQS, SNS, and EventBridge

Part 1: AWS SQS (Simple Queue Service)

"For resilient pull-based processing with FIFO for ordering guarantees"

What it means

Simple Example: The Coffee Shop

Part 2: AWS SNS (Simple Notification Service)

"For fan-out to multiple consumers simultaneously"

What it means

Simple Example: The New Author Announcement

Part 3: AWS EventBridge

"For complex routing with pattern-based rules... my default for internal domain events"

What it means

Simple Example: The Airport Sorting System

When to use which?

3- AWS Serverless: REST API vs. HTTP API

1. How It Works: REST API vs. HTTP API (AWS Architecture)

AWS REST API (The Heavyweight)

AWS HTTP API (The Express Lane)

2. The Traditional Service Comparison (Express.js / NestJS)

Traditional Server (Express.js on EC2/Docker)

AWS Serverless (HTTP API + Lambda)

Summary: Unmixing the Terms

2- AWS Serverless: Testing (typescript)

1. Unit Testing: Jest + Mock Payloads & SDK Client Mocking

The Code Under Test (src/handler.ts)

The Jest Unit Test (tests/unit.test.ts)

2. Integration Testing: LocalStack

The Integration Test Configuration (tests/integration.test.ts)

3. End-to-End (E2E) Testing: Newman

The Testing Workflow

4. Local Execution: AWS SAM Local

Step A: Define your event payload (events/mock-request.json)

Step B: Invoke the function via CLI

1- AWS Serverless: Designing a serverless API: Order Processing API (E-commerce)

The Scenario

1- Entry Point — API Gateway

How It Works

Gotchas

2. Business Logic — Lambda (TypeScript)

How It Works

Gotchas

Conceptual Application Code (TypeScript)

3. Database — RDS

How It Works

Gotchas

High-Level Relational Database Design (DDL)

4. Async Flow — SQS + EventBridge

How It Works

Gotchas

Conclusion

Reclaim Your Mac Disk Space

Step 1: Diagnose First

Step 2: Clear the Caches (Safe, ~N GB+)

Step 3: Tame Application Support

Step 4: Clean Docker Images

Step 5: Verify You Recovered Space

The Developer's Mindset on Disk Hygiene

A tip from a senior engineer

The Trade-off: Clean Testing vs. Code Brevity in Modern JS

Hamid Shoja ・ Jan 19

Uvicorn in Modern Python APIs

What is Uvicorn?

Why do we use it?

Quick Start Example

Alternatives to Consider

Architecture Comparison (Python vs. The World)

Perfomance

Cpu-intensive tasks

The Code Under Test (`src/handler.ts`)

The Jest Unit Test (`tests/unit.test.ts`)

The Integration Test Configuration (`tests/integration.test.ts`)

Step A: Define your event payload (`events/mock-request.json`)