DEV Community: Fahim Ahammed Firoz

Understanding Docker Networks (Easy Concept Explanation)

Fahim Ahammed Firoz — Sun, 16 Nov 2025 14:27:45 +0000

A Docker Network is basically a virtual space where containers can communicate with each other. By default, every Docker container is isolated, meaning it cannot see or talk to any other container. This isolation is good for security, but in real projects we usually run multiple containers together, like a backend API, a frontend, and a database. If these containers cannot talk to each other, nothing will work. That is why Docker Networks exist, they allow containers to communicate safely and easily.

You can think of a Docker Network as a room, and containers as people inside that room. People in the same room can talk to each other freely. People in different rooms cannot communicate unless you create a connection between the rooms. In the same way, containers inside the same Docker Network can communicate smoothly, while containers in different networks remain isolated.

Docker has different types of networks, but the most commonly used one is the Bridge Network. This network works like a private area where related containers, such as your API and database, stay together and can interact. The Host Network removes the boundary between the container and the machine running it, which makes communication faster but less isolated. The None Network isolates the container completely, giving it no network access at all. The Overlay Network is used in large or multi server environments where containers on different machines need to communicate as if they were in the same room.

One of the best things about Docker Networks is that containers can talk to each other using their names instead of IP addresses. For example, your API can reach the database simply by using its container name. Docker automatically manages all the underlying network rules, which makes development much easier.

In simple words, a Docker Network is like Wi Fi for containers. If containers are connected to the same network, they can communicate. If they are not, they stay isolated.

Docker networking keeps your applications structured, secure, and scalable, and understanding this concept is a big step toward mastering container based development.

কেন Stripe Date-Based API Versioning ব্যবহার করে? (কেন Traditional Versioning করে না)

Fahim Ahammed Firoz — Wed, 08 Oct 2025 13:35:16 +0000

প্রায় সবাই জানি Stripe-এর API অসাধারণ। কিন্তু জানেন কি কেন তারা traditional /v1, /v2 versioning ব্যবহার না করে, বরং date-based versioning ব্যবহার করে?

এটা মূলত Stripe-এর developer-friendly এবং stable API design-এর ঝলক।

Traditional Versioning-এর কিছু সীমাবদ্ধতা রয়েছে। উদাহরণস্বরূপ, যখন একটি API /v1/customers থেকে /v2/customers-এ আপডেট হয়, তখন সাধারণত endpoint structure, data format, এবং response shape-এর বড় পরিবর্তন আসে। এর ফলে existing integrations হঠাৎ ভেঙে যেতে পারে এবং developers-কে নতুন version-এ migrate করতে অনেক সময় ও effort দিতে হয়। এছাড়া, একাধিক version maintain করাও জটিল হয়ে যায়। অর্থাৎ, Traditional Versioning বড় পরিবর্তনের ক্ষেত্রে risk তৈরি করে এবং integration-কে কম stable রাখে।

Stripe-এর Date-Based Versioning হল এমন একটি পদ্ধতি যেখানে প্রতিটি API version একটি নির্দিষ্ট তারিখের সঙ্গে mark করা থাকে, যেমন 2025-09-30.clover. এতে করে প্রতিটি major বা monthly release সহজে track করা যায়।

Major release-এ বড় পরিবর্তন (যা backward-compatible নয়) আনা হয়, কিন্তু monthly release-এ শুধু backward-compatible ছোট পরিবর্তন আসে। এই পদ্ধতিতে, আপনার integration যেই version-এ pinned থাকে, তা নতুন update এলেও ভাঙবে না। Developer রা চাইলে পরবর্তীতে step-by-step নতুন version-এ safely migrate করতে পারেন।

Stripe internally প্রতিটি request handle করে compatibility layer দিয়ে।

Main codebase সর্বদা latest থাকে, কিন্তু পুরোনো version-এর জন্য response backward-compatible হয়।

Stripe-এর SDK যেমন stripe-node, stripe-python, release time-এর API version-এর সাথে pinned থাকে। ফলে Type mismatch বা API inconsistency-এর ঝুঁকি কমে যায়।

Webhook endpoint তৈরির সময় যেই version নির্বাচন করা হয়, সেই version-এর data format সবসময় ঠিক থাকে। নতুন update আসলেও আপনার webhook break হয় না।

সহজভাবে-

Traditional versioning = একবারে big change, risk বেশি
Date-based versioning = step by step small change, integration always stable

Stripe-এ এটি win-win.

Stripe-এর date-based versioning দেখায় কিভাবে innovation এবং stability একসাথে রাখা যায়। Integration সহজ, upgrades smooth, এবং system সবসময় reliable.

Building an AI Chat Rate Limiter with Node.js, Express, and Vercel AI SDK

Fahim Ahammed Firoz — Sat, 20 Sep 2025 16:04:14 +0000

When building AI chat applications, one of the main challenges is controlling costs. Each AI request has a cost, so you cannot allow unlimited usage. A rate limiter helps solve this by restricting how many requests each user can make in a fixed time period.

In this article, we will look at how to build a chatbot backend using Node.js, Express, and the Vercel AI SDK. Our system uses a fixed window rate limiting algorithm to manage usage for different user types: Guest, Free, and Premium.

Why Rate Limiting?

Rate limiting ensures:

Fair usage for all users
Protection from abuse
Cost control for AI services
Predictable system performance

For example, if a Guest makes 1,000 requests per hour, your costs can skyrocket. With a limiter, you decide how many requests are allowed.

User Types and Limits

User Type	Limit (per hour)	Notes
Guest	3	No login required
Free	10	Logged-in users with free plan
Premium	50	Logged-in users with premium plan

The system identifies:

Guests by IP address
Logged-in users by their user.id (from JWT token)

How the Rate Limiter Works

A request is sent to /api/chat.
If there is a JWT token, it is verified. If missing, the user is a Guest.
The system decides the limit based on user type:
- Guest = 3
- Free = 10
- Premium = 50
The request counter is checked for the current 1-hour window.
If the user has requests left, the system forwards the query to the AI SDK.
If the limit is exceeded, the server returns a 429 error with a clear message.

Fixed Window Algorithm

We use a Fixed Window Algorithm:

Keep a count of requests per user (or IP).
If the request is within the same window (1 hour), increase the count.
If the window has expired, reset the count and start a new window.
If the count is above the limit, reject the request.

Example in memory store:

{
  "user123": {
    "count": 7,
    "windowStart": 1695206400000
  }
}

This means user123 has made 7 requests since the last window started.

Flow Diagram

The process can be explained with this flow:

Check if the request has a JWT token.
If valid, assign user type (Free or Premium). Otherwise, assign Guest.
Apply the rate limit based on user type.
If the user is new, start tracking requests.
If the time window has expired, reset the counter.
If the count is within the limit, allow the request. Otherwise, block it.

Conclusion

By combining Express, JWT authentication, and the Vercel AI SDK, we built a chatbot backend with different rate limits for Guests, Free users, and Premium users.

This ensures cost control, fair usage, and a better experience for all users.

Source code: GitHub - chatbot-throttle

⭐ If you find this project useful, don’t forget to star the repository on GitHub!

Protect Your API with Token Bucket Rate Limiting

Fahim Ahammed Firoz — Sat, 20 Sep 2025 06:53:32 +0000

When building APIs, chat services, or real-time systems, one of the biggest challenges is preventing clients from overwhelming your server with too many requests. Without protection, a flood of traffic can slow down performance or even crash the system.

This is where rate limiting comes in. Among the many techniques available, the Token Bucket Algorithm is widely used because it is simple, efficient, and allows for bursts of traffic without losing overall control.

What is Rate Limiting?

Rate limiting is the process of controlling how many requests a client can send to a server in a given period of time.

Example:

A client may be allowed 10 requests per second.
If they exceed that, their additional requests are rejected until the next second begins.

Rate limiting ensures:

Fair resource usage across users
Protection against abuse, brute-force attacks, or spam
Improved server stability and reliability

The Token Bucket Algorithm

The Token Bucket Algorithm works like this:

Each client is assigned a bucket.
The bucket has a capacity (for example, 10 tokens).
Tokens are refilled at a fixed rate (for example, 1 token per second).
Each request consumes one token.
If the bucket is empty, the request is rejected.

This approach allows short bursts of requests when tokens are available, while still enforcing a long-term average request rate.

Token Bucket Flow

The steps are as follows:

Check if the client is new
If yes, create a bucket for them with full capacity.
Refill tokens
Based on the time elapsed since the last refill.
Check if tokens are available

If yes, consume one token and accept the request.
If no, reject the request.

This balance ensures that clients can make quick bursts of requests but cannot exceed the average allowed rate.

Implementing Token Bucket in Node.js

Let’s build a simple HTTP server with Token Bucket Rate Limiting.

Step 1: Setup

const http = require('http');

// Configuration
const bucketCapacity = 10;   // maximum tokens per user
const refillRate = 1;        // tokens per second
const ipBuckets = new Map(); // store buckets for each IP

We define the bucket size, refill rate, and a map to store each user’s token bucket.

Step 2: Refill Function

function refillTokens(bucket) {
    const now = Date.now();
    const elapsed = (now - bucket.lastRefillTime) / 1000; // seconds
    const refill = Math.floor(elapsed * refillRate);

    if (refill > 0) {
        bucket.tokens = Math.min(bucketCapacity, bucket.tokens + refill);
        bucket.lastRefillTime = now;
    }
}

This function calculates how many tokens should be added based on the elapsed time since the last refill, and updates the bucket without exceeding its capacity.

Step 3: Rate Limiting Middleware

function rateLimitMiddleware(req, res) {
    const ip = req.socket.remoteAddress;

    // If user is new, create a bucket
    if (!ipBuckets.has(ip)) {
        ipBuckets.set(ip, { tokens: bucketCapacity, lastRefillTime: Date.now() });
    }

    const bucket = ipBuckets.get(ip);
    refillTokens(bucket);

    if (bucket.tokens > 0) {
        bucket.tokens -= 1; // consume one token
        res.writeHead(200, { 'Content-Type': 'text/plain' });
        res.end('Request accepted\n');
    } else {
        res.writeHead(429, { 'Content-Type': 'text/plain' });
        res.end('Too Many Requests\n');
    }
}

This function manages the bucket for each IP, consumes tokens when available, and rejects requests if tokens are empty.

Step 4: Start the Server

const server = http.createServer(rateLimitMiddleware);

server.listen(3000, () => {
    console.log('Server running at http://localhost:3000/');
});

This starts the server on port 3000, applying the rate limiting logic to every request.

Full Code

const http = require('http');

// Configuration
const bucketCapacity = 10;   // maximum tokens per user
const refillRate = 1;        // tokens per second
const ipBuckets = new Map(); // store buckets for each IP

// Refill function
function refillTokens(bucket) {
    const now = Date.now();
    const elapsed = (now - bucket.lastRefillTime) / 1000; // seconds
    const refill = Math.floor(elapsed * refillRate);

    if (refill > 0) {
        bucket.tokens = Math.min(bucketCapacity, bucket.tokens + refill);
        bucket.lastRefillTime = now;
    }
}

// Middleware
function rateLimitMiddleware(req, res) {
    const ip = req.socket.remoteAddress;

    // If user is new, create a bucket
    if (!ipBuckets.has(ip)) {
        ipBuckets.set(ip, { tokens: bucketCapacity, lastRefillTime: Date.now() });
    }

    const bucket = ipBuckets.get(ip);
    refillTokens(bucket);

    if (bucket.tokens > 0) {
        bucket.tokens -= 1; // consume one token
        res.writeHead(200, { 'Content-Type': 'text/plain' });
        res.end('Request accepted\n');
    } else {
        res.writeHead(429, { 'Content-Type': 'text/plain' });
        res.end('Too Many Requests\n');
    }
}

// Start server
const server = http.createServer(rateLimitMiddleware);

server.listen(3000, () => {
    console.log('Server running at http://localhost:3000/');
});

Use Cases

API Gateways: prevent abuse by limiting requests per client
Chat Applications: stop spamming by controlling message frequency
Authentication Systems: slow down brute-force login attempts
IoT Devices: manage bursts of data from sensors and devices

Benefits of Token Bucket

Allows bursts of requests up to the bucket capacity
Maintains a steady long-term request rate
Simple and efficient implementation
Predictable refill behavior

Conclusion

The Token Bucket Algorithm is a practical and effective way to implement rate limiting. It combines flexibility and control by allowing temporary bursts while maintaining a predictable average request rate.

If you are building APIs, chat systems, or real-time applications, Token Bucket rate limiting can help you protect your server, ensure fairness, and improve system reliability.

TypedSQL in Prisma: Type-Safe SQL Made Simple

Fahim Ahammed Firoz — Fri, 30 Aug 2024 09:35:06 +0000

TypedSQL is a powerful feature in Prisma that allows developers to write raw SQL queries while maintaining type safety and full integration with Prisma’s TypeScript client. This feature is especially useful for scenarios where complex SQL queries are necessary, but you still want to benefit from Prisma’s type safety, code generation, and developer experience (DX). In this blog, we'll walk through the steps to get started with TypedSQL, how to pass arguments to queries, define argument types, and some best practices.

Setting Up TypedSQL in Prisma

To start using TypedSQL in your Prisma project, follow these steps:

1. Install the Required Packages

Ensure that you have @prisma/client and prisma installed and updated to at least version 5.19.0. You can do this by running the following commands:

npm install @prisma/client@latest
npm install -D prisma@latest

2. Enable TypedSQL in Your Schema

Add the typedSql preview feature flag to your schema.prisma file:

generator client {
  provider = "prisma-client-js"
  previewFeatures = ["typedSql"]
}

3. Create a Directory for SQL Files

Inside your prisma directory, create a sql directory where you'll write your SQL queries:

mkdir -p prisma/sql

4. Write Your SQL Queries

Create a new .sql file in the prisma/sql directory. The file name must be a valid JavaScript identifier and cannot start with a $. For example, let's create a getUsersWithPosts.sql file:

-- prisma/sql/getUsersWithPosts.sql
SELECT u.id, u.name, COUNT(p.id) as "postCount"
FROM "User" u
LEFT JOIN "Post" p ON u.id = p."authorId"
GROUP BY u.id, u.name

5. Generate the Prisma Client

To generate TypeScript functions and types for your SQL queries, run the following command:

prisma generate --sql

If you want Prisma to regenerate the client automatically after every change, you can use the --watch flag:

prisma generate --sql --watch

6. Use TypedSQL Queries in Your Code

You can now import and use your SQL queries in your TypeScript code:

import { PrismaClient } from '@prisma/client'
import { getUsersWithPosts } from '@prisma/client/sql'

const prisma = new PrismaClient()

const usersWithPostCounts = await prisma.$queryRawTyped(getUsersWithPosts())
console.log(usersWithPostCounts)

Passing Arguments to TypedSQL Queries

To pass arguments to your TypedSQL queries, you can use parameterized queries. This allows you to write flexible and reusable SQL statements while maintaining type safety.

Example: Passing Parameters

In your SQL file, use placeholders for the parameters you want to pass. The syntax for placeholders depends on your database engine. For PostgreSQL, use the positional placeholders $1, $2, etc.:

-- prisma/sql/getUsersByAge.sql
SELECT id, name, age
FROM users
WHERE age > $1 AND age < $2

When using the generated function in your TypeScript code, pass the arguments as additional parameters to $queryRawTyped:

import { PrismaClient } from '@prisma/client'
import { getUsersByAge } from '@prisma/client/sql'

const prisma = new PrismaClient()

const minAge = 18
const maxAge = 30
const users = await prisma.$queryRawTyped(getUsersByAge(minAge, maxAge))
console.log(users)

Example: Passing Array Arguments

TypedSQL supports passing arrays as arguments for PostgreSQL. Use PostgreSQL's ANY operator with an array parameter:

-- prisma/sql/getUsersByIds.sql
SELECT id, name, email
FROM users
WHERE id = ANY($1)

In your TypeScript code:

import { PrismaClient } from '@prisma/client'
import { getUsersByIds } from '@prisma/client/sql'

const prisma = new PrismaClient()

const userIds = [1, 2, 3]
const users = await prisma.$queryRawTyped(getUsersByIds(userIds))
console.log(users)

Defining Argument Types in SQL Files

You can define the types of arguments directly in your SQL files using specific comments. This enhances type safety and ensures that the TypeScript client is fully aware of the types being passed.

Example: Typing Arguments

Add the following comments to define the types:

-- @param {Int} $1:minAge The minimum age of the user
-- @param {Int} $2:maxAge The maximum age of the user
SELECT id, name, age
FROM users
WHERE age > $1 AND age < $2

The format is consistent across all supported database engines and ensures that your TypeScript code accurately reflects the SQL query structure.

Pros and Cons of Using TypedSQL

Pros

Type Safety: TypedSQL provides strong type safety for raw SQL queries, reducing the risk of runtime errors and ensuring consistent data handling.
Integrated DX: By integrating with Prisma, TypedSQL allows you to write complex SQL queries while still benefiting from Prisma’s developer tools, like autocomplete and type inference.
Reusable Queries: TypedSQL encourages the reuse of SQL queries across your application, making it easier to maintain and update your codebase.
Protection Against SQL Injection: By using parameterized queries, TypedSQL helps protect your application against SQL injection attacks, which are a common security vulnerability.
Better Performance for Complex Queries: TypedSQL allows you to execute more complex and efficient SQL queries directly within Prisma, bypassing some of the limitations of Prisma’s query builder.

Cons

Limited Dynamic SQL Support: TypedSQL does not natively support constructing SQL queries with dynamically added columns. For such cases, you need to fall back to $queryRaw or $executeRaw, which means losing type safety.
Increased Complexity: Using raw SQL, even with type safety, adds a layer of complexity to your codebase, especially if your team is more familiar with Prisma’s query builder syntax.
Learning Curve: Developers need to be comfortable with both SQL and Prisma’s TypeScript client to use TypedSQL effectively. This might require additional learning for some team members.
Dependency on Preview Features: TypedSQL is currently a preview feature, meaning it’s not yet fully stable and might undergo breaking changes in future releases.
Lack of Full ORM Benefits: When using TypedSQL, you miss out on some of the abstractions and conveniences that Prisma’s ORM provides, such as automatic relation handling and query optimization.

Conclusion

TypedSQL is a powerful tool in Prisma’s ecosystem that bridges the gap between raw SQL and type-safe query construction. It offers the flexibility of raw SQL with the benefits of Prisma’s TypeScript client, making it ideal for scenarios where you need fine-grained control over your database queries.

However, it’s important to weigh the pros and cons before adopting TypedSQL in your project. While it offers many advantages, particularly in terms of type safety and query performance, it also introduces complexity and requires a good understanding of SQL.

By following the steps outlined in this guide, you can start using TypedSQL in your Prisma projects, writing more complex queries while maintaining the benefits of Prisma’s type-safe client.

🚀3 Important Rules for Naming Variables in Excellent Code

Fahim Ahammed Firoz — Sun, 17 Mar 2024 20:38:03 +0000

Good variable names are just as important as clear function names for making code easy to understand. Here are 3 simple rules to make your variable names better:

Meaningful Names: Replace generic names (like temp or x, y, x) with names that reflect their purpose.

❌ tempData

✅ customerOrder

Descriptive Naming: Use descriptive terms that explain the content of the variable.

❌ isSomething (unclear what "something" is)
✅ isUserLoggedIn (clear and concise)

Case Consistency: Pick a case convention (snake_case, camelCase) and stick to it throughout your codebase.

Snake Case: Lowercase letters with underscores for separation (e.g., total_price)
Camel Case: Lowercase with the first letter of each word capitalized (e.g., totalPrice)

Bonus Tip: Consider adding prefixes or suffixes for specific variable types (e.g., strFirstName, intEmployeeID).

By following these principles, your variables become self-documenting, improving code readability and maintainability for yourself and your fellow developers.

Consistent naming across functions and variables is key!

GraphQL vs tRPC: Picking the Best Fit for Your Project

Fahim Ahammed Firoz — Sat, 28 Oct 2023 19:33:21 +0000

GraphQL *এর সাথে বর্তমান সময়ে **tRPC *নামে একটি টেকনোলজির নাম বেশি শোনা যাচ্ছে। এটি একটি **remote procedure call (RPC) framework যা বিশেষভাবে TypeScript এর জন্য ডিজাইন করা হয়েছে। এটিতে ক্লায়েন্ট সাইট থেকেই সার্ভার ডিফাইন ফাংশন কল করা যায়। tRPC বেশ first এবং তুলনামূলক ব্যবহার করা সহজ। এছাড়াও এর এমন কিছু features রয়েছে যার জন্য এটিকে microservices-based applications তৈরির জন্য আদর্শ বলা যেতে পারে।

কি!! এই কথাটুকু শুনে graphql শেখা বাদ দিয়ে tRPC শিখবেন? নাকি কনফিউশনে পড়ে গেলেন কোনটি শেখা ভালো হবে? আবার এমনটিও মনে হতে পারে যে পুরান পাগলে ভাত পায় না নতুন পাগলের আমদানি।

তাহলে আগে এই পাগল দ্বয়ের উদয় হলো কোন সময়ে সেটি জানার চেষ্টা করি। ২০১২ সালে মার্ক সাইমন, জোসেফ উইলিয়ামস এবং জোয়েল ওয়াল্টন GraphQL তৈরি করেছিল এবং ২০১৫ সালে এটির প্রথম ভার্সন রিলিজ করা হয়েছিল। ২০১৬ সাল থেকে এটি বেশ জনপ্রিয় হতে থাকে এবং facebook, Google, Microsoft এর মতো বড় বড় কোম্পানি এটি ব্যবহার করা শুরু করে।

অন্যদিকে, ২০২০ সালে ডেভিড ক্রাউন tRPC নামে একটি RPC framework তৈরি করে এবং ২০২১ সালে tRPC 1.0 রিলিজ করা হয়েছিল। ২০২২ সাল থেকে এটি বেশ জনপ্রিয় হতে শুরু করে।

_GraphQL এবং tRPC দুটিই API তৈরির জন্য ব্যবহৃত টেকনোলজি। তবে এদের মধ্যে কিছু গুরুত্বপূর্ণ পার্থক্য রয়েছে। যেমনঃ _
GraphQL একটি query language, & tRPC একটি RPC Framework. এর মানে হল যে GraphQL ব্যবহার করে, আপনি একটি API তৈরি করতে পারেন যা ক্লায়েন্টকে সার্ভার থেকে data access করতে দেয়। অন্যদিকে, tRPC ব্যবহার করে, আপনি একটি API তৈরি করতে পারেন যা ক্লায়েন্ট এবং সার্ভার মধ্যে data transfer করতে দেয়। পার্ফমেন্সের দিক থেকে tRPC কিছুটা এগিয়ে থাকলেও GraphQL flexibility এর দিক থেকে এগিয়ে রয়েছে। GraphQL API তৈরিতে বিভিন্ন ধরনের ল্যাগুয়েজ ব্যবহার করা যায়, কিন্তু tRPC শুধু মাত্র TypeScript এর জন্য ডিজাইন করা।

দুটিই বেশ ভালো টেকনোলজি এবং দুটিরই ভালো সুবিধা রয়েছে আবার কিছু লিমিটেশনও রয়েছে। তাহলে কোন ধরনের প্রজেক্টে কোনটি use করা উচিত?

আপনি যদি একটি powerful & flexible API তৈরি করতে চান যার মাধ্যমে ক্লায়েন্ট থেকে স্পেসিফিক ডেটার জন্য রিকোয়েস্ট করতে পারবেন তাহলে GraphQL ভালো পছন্দ হতে পারে। যেমনঃ Social Media API, Content Management System (CMS), Data Analytics API.

আবার অন্যদিকে, আপনি যদি simple & ব্যবহার করা সহজ এমন API তৈরি করতে চান যা data transfer করতে পারবে, তাহলে tRPC ভালো পছন্দ হতে পারে। tRPC মূলত microservice based application এর জন্য ডিজাইন করা হয়েছে। এছাড়াও real-time chat application, gaming application তৈরিতেও এটি ব্যবহার করা যেতে পারে।

সবশেষে বলতে পারি যে, GraphQL এবং tRPC উভয়ই শক্তিশালী এবং কার্যকর টেকনোলজি। দুটিরই বেশ জনপ্রিয়তা এবং প্রয়োজনীয়তা রয়েছে। এখন আপনার কাজের ধরন এবং প্রয়োজনীয়তার উপর নির্ভর করছে আপনি আপনার প্রজেক্টে/এপ্লিকেশনে কোনটি ব্যবহার করবেন।

_References: _