DEV Community: Fahim Ahammed Firoz

What I Built

Fahim Ahammed Firoz — Sat, 31 Oct 2026 17:40:20 +0000

*This is a submission for the MLH x DEV Writing Challenge*

What I Built

During the hackathon, my team and I built EcoSync (name your project here if different), a real-time web application designed to help communities track, report, and gamify local environmental cleanups and recycling efforts.

The idea came from seeing how difficult it is for grassroots environmental groups to coordinate volunteer turnouts and visualize their measurable impact. EcoSync allows users to drop pins on local areas that need attention, join nearby cleanup events, log waste collected, and earn activity badges.

Building it in under 36 hours pushed our limits. We learned how to rapidly design and deploy a full-stack product under pressure, handle state management efficiently in real-time, and balance feature ambition with shipping a functional MVP before the deadline.

Demo

Live Application: https://ecosync-demo.vercel.app
GitHub Repository: https://github.com/your-username/ecosync

Here is a quick walkthrough of the core workflow:

User Dashboard: Displays nearby cleanup initiatives and active community boards.
Interactive Map: Shows geo-tagged cleanup spots with urgency indicators.
Impact Tracker: Lets organizers log the weight/volume of waste collected, automatically updating the event leaderboard.

Partner Technologies

To power the app reliably and quickly, we integrated two MLH partner technologies:

1. MongoDB Atlas

We needed a flexible, scalable document database to handle dynamic event locations, volunteer profiles, and status updates. We deployed a managed MongoDB Atlas cluster to store:

User authentication and badge records
Dynamic geospatial coordinates for cleanup pins

Using MongoDB’s geospatial queries ($near and $geoWithin), we were able to quickly fetch cleanup tasks within a 5-mile radius of a user’s current coordinates. Atlas made the setup effortless, letting us connect directly through Mongoose without dealing with manual database server maintenance.

2. Twilio (Messaging API)

To keep volunteers updated without requiring them to keep the web app open, we integrated the Twilio SMS API. When an organizer changes an event status or issues an urgent weather alert, registered volunteers receive an instant SMS notification. Setting up the Twilio Node.js SDK took less than an hour, and the documentation made testing edge-case alerts seamless.

Hackathon Experience

I participated in Hack the North (or insert your hackathon's name here), and the energy was electric from start to finish. Collaborating across time zones with teammates who brought distinct skills in UI/UX, backend logic, and system design made the long hours genuinely fun.

The highlight of the event was the late-night debugging session around 3:00 AM—when our API routes were throwing silent CORS errors right before our first planned sleep break. Solving that together over a shared Discord call, finally seeing the live data render on screen, and making the submission minutes before the portal closed is something I won’t forget.

A massive thank you to Major League Hacking (MLH), DEV, and the event mentors for organizing such an inspiring space to build, break, and learn.

Private Notes AI: A Ghost That Remembers Your Past

Fahim Ahammed Firoz — Sat, 31 Oct 2026 17:37:08 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

What if you could talk to your past self?

We write hundreds of notes, save random thoughts, document ideas, and sometimes forget where we put them. Eventually, those memories become digital ghosts buried somewhere in our devices.

That's why I came up with Private Notes AI.

Private Notes AI is an AI-powered personal memory assistant that helps users interact with their own notes using natural language.

Instead of manually searching through hundreds of notes, you can simply ask questions like:

"What was that project idea I wrote down last month?"
"Did I ever make notes about learning Kubernetes?"
"Find the technical decisions I made for my previous project."
"What were my goals for this year?"

The AI searches your personal knowledge base and brings relevant memories back to life.

The idea behind the project perfectly fits this week's theme: Ghost in the Machine.

A little ghost that lives inside your machine and remembers things you might have forgotten.

Demo

[Add your deployed demo URL here]

[Add a demo video here]

Code

GitHub Repository: [Add your GitHub repository URL here]

How I Built It

The main idea was to build an AI application where open-source AI isn't just an additional feature. It's the actual engine behind the experience.

The planned architecture includes:

Open-weight LLM: For understanding questions and generating contextual responses.
Ollama: For running AI models locally.
Embeddings: To convert personal notes into searchable vector representations.
Vector Search: To retrieve relevant memories based on semantic similarity.
Backend: To manage notes, indexing, and AI interactions.
Frontend: To provide a simple conversational interface.

The workflow is straightforward:

Users create or import their personal notes.
Notes are converted into embeddings.
Embeddings are stored in a searchable knowledge base.
Users ask questions in natural language.
Relevant notes are retrieved and provided as context to the local LLM.
The model generates an answer based on the user's own information.

The goal is to make the entire AI workflow possible without depending on a proprietary AI API.

Why Does Open Innovation Matter?

This is probably the most important part of this project.

Personal notes can contain almost anything: private thoughts, passwords accidentally written down, business ideas, project plans, personal experiences, and important memories.

Sending all of that information to an external AI service isn't always a good idea.

With open-source AI and local inference, we get more control over our data.

Privacy: Personal information can stay on the user's own machine instead of being sent to an external AI provider.

Freedom: We can experiment with different open-weight models and choose the one that works best.

No vendor lock-in: The application doesn't have to depend on a single company's API, pricing, or availability.

Offline possibilities: Once the model and required resources are downloaded, the core AI experience can work without an internet connection.

For me, open innovation is not just about using free software. It's about having the freedom to understand, modify, improve, and control the technology we're building with.

A private memory assistant should belong to its user, not to an AI company.

My Agent Session

[Add your DevRelay session link here]

The Spirit of It

We often think technology is about remembering more things.

But sometimes, the real problem is that we forget the things that matter.

An old project idea, a random thought at 2 AM, a solution to a problem we struggled with months ago, or a goal we once promised ourselves to achieve.

Imagine asking your computer about something you wrote two years ago and getting an answer instantly.

It's almost like having a conversation with your past self.

Maybe that's what a ghost in the machine really is.

Not something that haunts you, but something that remembers you.

Prize Categories

[Add applicable partner prize categories here]

Thanks to the DEV team and all the partners for organizing this challenge. Building something around open-source AI has been a great opportunity to explore what's possible beyond closed AI APIs.

Happy Hacktoberfest! 👻

DocuFlow AI: Turn Any Codebase into a Client-Ready Technical Audit

Fahim Ahammed Firoz — Mon, 19 Oct 2026 07:29:54 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Every developer knows the challenge of joining a project with thousands of lines of undocumented code, unclear architecture, and no reliable API reference. For freelancers and agencies, understanding an unfamiliar codebase can consume hours of unpaid discovery work before a project even begins.

DocuFlow AI is an autonomous codebase documentation and architecture analysis engine designed to turn that problem into a sellable service.

It helps developers, freelance consultants, and software agencies analyze existing repositories and generate professional, client-ready technical documentation.

With DocuFlow AI, you can:

Generate architecture overviews: Understand the technology stack, project structure, major components, and dependencies.
Create interactive architecture diagrams: Generate Mermaid-based component and sequence diagrams.
Discover APIs and code symbols: Catalog routes, functions, classes, interfaces, and other important code structures.
Audit operations and security: Identify potential security issues, missing validations, configuration concerns, and technical debt.
Export client-ready reports: Package findings into Markdown documentation and branded technical audit deliverables.

The goal is simple: help developers spend less time reverse-engineering code and more time delivering valuable work.

The Side Hustle Opportunity

DocuFlow AI makes it easier to offer codebase audits as a freelance service, particularly during client onboarding, legacy system handoffs, and technical due diligence.

Potential business models include:

One-time audits: $49 per report.
Freelancer and agency subscriptions: $199/month.
Enterprise on-premise CLI: $499/seat/year.
Documentation automation: GitHub Actions and CI/CD integrations that keep technical documentation updated as code changes.

These are proposed pricing models, not verified revenue or customer results.

Demo

The project is designed to run locally through an interactive web dashboard or a command-line interface.

The dashboard provides a place to explore generated documentation, architecture diagrams, and code analysis results.

Run it locally:

# Install dependencies
pnpm install

# Start the dashboard
pnpm start

# Open http://localhost:3000

For CLI usage:

# Analyze a repository with Gemini
pnpm cli /path/to/target-repo --key YOUR_GEMINI_KEY

# Run without an external AI API key
pnpm cli /path/to/target-repo --provider heuristic

The heuristic mode provides a no-API-key alternative for structural analysis and documentation generation. It should not be confused with local LLM inference.

Code

The project is built around a modular architecture that separates repository analysis, AI-powered synthesis, and documentation delivery.

The intended workflow is:

Ingest a local repository, ZIP archive, or sample project.
Parse the file hierarchy, code symbols, routes, and dependencies.
Build structured context for documentation and audit generation.
Generate architecture explanations, diagrams, API references, and audit findings.
Export the results as reusable technical documentation and client handoff reports.

Explore the project through the code repository and running demo linked with the submission.

How I Built It

DocuFlow AI uses a multi-stage pipeline to transform source code into structured technical insights.

Stage 1: Repository Analysis

The first stage walks through the codebase, identifies files and technologies, extracts relevant code structures, and maps dependencies.

This structured analysis reduces the need to send entire source files to an AI model when only specific symbols or relationships are relevant.

Stage 2: AI-Powered Documentation

The second stage synthesizes the extracted context into several deliverables:

Executive architecture summaries.
Component and sequence diagrams using Mermaid.
API references and symbol catalogs.
Operational documentation and security review findings.

The AI provider layer supports a flexible approach to inference, allowing users to choose a provider based on their privacy, hardware, and quality requirements.

Stage 3: Documentation and Reporting

The final stage presents the generated results in a web dashboard and supports exporting documentation for further editing, sharing, and client delivery.

The goal is not merely to produce a summary of source code. It is to create documentation that a developer or consultant can use as a practical engineering deliverable.

Why Does Open Innovation Matter?

Open innovation is central to DocuFlow AI because source code is often one of a company's most sensitive assets.

1. Privacy and Local-First Analysis

Client repositories can contain proprietary algorithms, internal APIs, business logic, and confidential configuration details.

An open-source analysis pipeline can inspect repository structure locally without requiring the source code to be uploaded to an external service.

When paired with a compatible local model, the entire analysis and inference workflow can operate without an external AI API connection, provided the required models and dependencies are already installed.

This is especially valuable for consultants working under NDAs and teams with strict data governance requirements.

2. Open-Weight Models and Flexible Inference

DocuFlow AI is designed to support local inference through tools such as Ollama and compatible OpenAI-style endpoints, with open-weight coding models such as Qwen2.5-Coder and DeepSeek-Coder as potential choices.

For users who prefer cloud inference, the architecture also accommodates Google Gemini.

This flexibility lets users choose between local privacy, available hardware, inference quality, and cloud convenience instead of depending entirely on a single proprietary provider.

3. Lower Operating Costs

Traditional AI-powered auditing services can incur recurring API costs, especially when analyzing large repositories through multiple generation passes.

Local inference can eliminate per-token API charges, although hardware, electricity, maintenance, and execution time still have costs.

That creates an opportunity for freelancers to build repeatable audit workflows and improve their margins without making every report dependent on a paid AI endpoint.

4. A Foundation Others Can Extend

An open and modular approach makes it easier to extend the tool with additional language analyzers, model providers, report formats, and CI/CD integrations.

The long-term vision is to make high-quality codebase documentation more accessible to individual developers and small agencies, not just organizations with dedicated architecture teams.

My Agent Session

I recorded and saved the agentic building process using DevRelay so that judges and other developers can explore the process behind the project.

View the complete DocuFlow AI agent session on DEV.to

The session provides an opportunity to inspect the prompts, tool calls, implementation workflow, and code changes involved in building the project.

You can also explore the interactive session using the embedded agent session below.

Building DocuFlow AI: Autonomous Codebase Documentation & Architecture Engine

You

Side Hustle Hackathon: Build something with open-source AI at its core that someone would actually pay for. We chose to build DocuFlow AI: an autonomous codebase documentation generator & architecture auditing engine.

Agent

Researched the technical pain point: developers & freelancers spend 25-35% of their billable hours deciphering legacy codebases, reverse-engineering routes, and drawing architecture diagrams. Architected a multi-stage pipeline:
1. Open-Source AST Parser (extracts symbols, routes, classes, imports)
2. Dual-Engine LLM Orchestrator (Google Gemini 1M+ context + Local Open-Weights via Ollama / Qwen2.5-Coder)
3. Interactive Web Dashboard with live Mermaid.js diagram rendering and Client Handoff Export.

▸ write_to_file server/agent/parser.js

Input

server/agent/parser.js

Output

Created codebase AST parser with regex tokenizers for JS/TS/Python/Go/Rust

▸ write_to_file server/agent/pipeline.js

Input

server/agent/pipeline.js

Output

Created 5-stage documentation pipeline orchestrator

You

Add Google Gemini API client, local open-weight model runner, prepackaged demo samples, and an interactive frontend dashboard with Mermaid diagrams.

Agent

Implemented Gemini API client with automatic fallback, Ollama connector for air-gapped local inference, Express backend with ZIP upload, and a Tailwind + Lucide + Mermaid.js web application. Tested the CLI runner and verified zero-token heuristic generation.

▸ run_command node bin/repodoc.js server/samples/ecommerce-api --provider heuristic

Input

$ node bin/repodoc.js server/samples/ecommerce-api --provider heuristic

Output

Successfully generated CODEBASE_DOCUMENTATION.md with 6 files, 170 lines, 9 symbols, and Mermaid component & sequence diagrams.

You

Add UI screenshots to README.md and install DevRelay to save the agent session.

Agent

Embedded all 4 product screenshots (Codebase Overview, Architecture & Mermaid diagrams, API & Endpoint Finder, and Code Health Audit) into README.md. Installed and registered DevRelay MCP server and skills.

Prize Categories

Primary category:

Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

DocuFlow AI focuses on turning open-source AI capabilities into a practical developer tool with a clear path toward a sustainable freelance or agency service.

The bigger idea: Documentation should not be an afterthought or an expensive manual process. With structured code analysis and flexible AI inference, developers can turn undocumented codebases into understandable systems and valuable client deliverables.

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: _