DEV Community: Abdulaziz Hamzah

Project #1: Loadtest

Abdulaziz Hamzah — Mon, 09 Mar 2026 22:06:23 +0000

Overview

A minimal wrk clone written in Go for learning purposes. This is a simple HTTP load testing tool that demonstrates concurrent programming and performance measurement. The tool sends concurrent HTTP requests to a target URL and provides detailed statistics about latency, throughput, and success rates.

Technology Stack

Language: Go
Key Libraries: net/http, flag, sync, time
Tools: Command-line interface

Learning Goals

What I aimed to learn from this project:

Go goroutines and channels for concurrent programming
Semaphore pattern for controlling concurrency
HTTP client configuration and timeout handling
Performance measurement and statistics collection
Command-line interface design with flag parsing

Key Features

HTTP load testing with configurable concurrency
Configurable request count and timeout
Real-time statistics (latency, throughput, success/failure rates)
Simple command-line interface
Safe concurrency with semaphore pattern

Technical Challenges & Solutions

Challenge 1: Managing concurrent requests safely

Problem: Needed to control the number of concurrent HTTP requests to avoid overwhelming the system and the target server.

Solution: Implemented a semaphore pattern using buffered channels. Created a worker pool that limits concurrent goroutines by passing "tokens" through a channel. This ensures exactly the specified number of requests run concurrently.

Challenge 2: Accurate timing measurements

Problem: Needed to measure individual request latencies while also calculating overall throughput.

Solution: Used time.Now() before each HTTP request and calculated duration after completion. For overall throughput, measured total time from start to finish and divided by completed requests.

Challenge 3: Proper resource cleanup

Problem: HTTP response bodies needed to be closed to prevent memory leaks, especially with many concurrent requests.

Solution: Used defer resp.Body.Close() immediately after checking for errors to ensure resources are always cleaned up, even if panics occur.

Code Architecture

The project follows a clean separation of concerns:

main.go: Entry point, argument parsing, and result reporting
cli.go: Command-line flag definitions and parsing logic
worker.go: Core concurrent execution logic using semaphore pattern
stats.go: Statistical calculations and result aggregation

Key design patterns:

Semaphore Pattern: Buffered channel controls concurrent access
Worker Pool: Goroutines execute tasks from a shared channel
Sync.WaitGroup: Ensures all goroutines complete before exiting

Installation & Usage

# Clone and build
git clone https://github.com/Azizham66/loadtest.git
cd loadtest
go build -o loadtest .

# Basic usage
./loadtest -url=https://example.com -requests=100

# High concurrency test
./loadtest -url=https://api.example.com -requests=1000 -concurrency=50

# Custom timeout
./loadtest -url=https://slow-server.com -requests=500 -timeout=10

Options

-url string: URL to stress test (required)
-requests int: Number of requests to send (default: 10)
-concurrency int: Number of concurrent requests (default: 10)
-timeout int: Timeout in seconds (default: 5)

What I Learned

Technical Skills

Go Concurrency: Basic understanding of goroutines, channels, and select statements
Semaphore Pattern: How to implement resource limiting using buffered channels
HTTP Client Configuration: Custom timeouts and connection management in Go
Performance Measurement: Accurate timing and statistical calculations
CLI Development: Flag parsing and user-friendly command-line interfaces

Concepts & Patterns

Concurrent Programming: Safe coordination between multiple goroutines
Resource Management: Proper cleanup in concurrent environments
Error Handling: Graceful failure handling in distributed systems
Statistics: Latency distribution and throughput calculations

Areas of Improvement

Better Code Organization: Implement proper Go package structure with cmd, internal, and pkg directories, plus interface abstractions for testability and configuration management
Enhanced Error Handling: Create custom error types for different failure scenarios, implement error aggregation for better categorization, and add retry logic for transient failures

Project Statistics

Duration: 1 day
Lines of Code: ~200 lines across 4 files
Difficulty: Beginner/Intermediate
Technology Area: System Programming / Open Source Tooling

Related Resources

This is Project #1 of my 100 Projects Challenge. Read more about the challenge here.

I Started a 100 Projects in 100 Days Challenge (Not Exactly in 100 Days) — And Here’s Why You Should Too

Abdulaziz Hamzah — Mon, 09 Mar 2026 16:15:06 +0000

A lot of developers learn new concepts, tools or languages, by following a course, watching tutorials or reading documentation, and then building project, but nobody talks about the hardest parts: applying what you learned into real projects.

It usually goes like this:

You learn a new tool, language or framework
You want to build something to apply what you learned into a real project
You don't know what to build and you struggle to find ideas

After a while you lose motivation and end up building nothing or you start following tutorials and what happens is:

You watch someone build something.
You understand it.
You feel productive.

Or you get stuck in tutorial hell.
And then... you try building something on you own.
Suddenly you brain goes blank.

I've realized the biggest gap between learning programming and becoming a professional engineer is not knowledge, it's experience. So I decided to fix that.

I started a 100 Projects Challenge.
The name suggests 100 projects in 100 days, but realistically it might take longer. Some projects may take a day, others up to a week. The important part isn't the calendar, it's the consistent building and showing up.

The goal is simple:

Build 100 meaningful coding projects that force me to explore different technologies, tools, and fields in computer science and engineering.

Why I started this challenge

As a junior developer and being a beginner myself, I realized that most beginner projects looks like this:

To-Do List
Calculator
Weather App
Blog CRUD
E-Commerce clone

Those projects were useful... in 2018.
While those projects are great starting point to teach you the fundamentals of software development. In an era where LLMs can generate boilerplate CRUD code in seconds, the value of a developer shifts from writing code to understanding systems.

So I wanted something different...
Something that would:

Force me to research, read documentation and know how to learn
Expose me to new technologies and tools I would have never touched
Help me gain real skill
Make actual project worth documenting and showing on my resume
Learn how things actually work which is something rarely touched in modern courses and tutorials

This challenge is designed to build system-thinking.

The Rules of the Challenge

To make the challenge meaningful, I created a few rules.

1. Every project must teach something meaningful

Basic beginner projects don’t count.

No todo lists.
No simple CRUD dashboards.
No tutorial clones.

Every project must introduce a real concept or skill.

For example:

Building a feature flag engine
Writing a small network protocol
Experimenting with computer graphics
Creating a simple embedded system
Integrating AI into real tools

The goal is learning something valuable each time.

2. Projects must explore different technologies

This challenge isn’t about mastering one language.
It’s about exploring the ecosystem of computer engineering.

Projects may involve:

Web development
System programming
Embedded systems
IoT
AI engineering
Game development
Computer graphic
Networking
Open source tooling
Or anything else you're interesting in and want to learn

Different languages and environments are encouraged. You don't have to learn 10 languages, but you should know how to read documentation and research when you need.

3. Each project must provide real value

Every project should give the challenger something tangible:

A reusable library
A useful tool
A deeper understanding of a field
Or anything you can show off and be proud that you built it
experience with real engineering concepts

The goal isn’t just “finishing projects”.
It’s gaining skills you can carry forward.

4. Projects must be small but meaningful

Each project should take:

Minimum: 1 day
Maximum: 1 week

The challenge is designed to encourage focused exploration, not multi-month builds.
You also cannot start a new project until the current one is finished.
No half-built graveyards of abandoned repos.

5. Every project must be documented

Finishing a project is only half the job.

Every project must be documented as either:

A DEV article
A blog post
An open-source repository with proper documentation

Documenting forces you to:

Organize your thoughts
Explain your decisions
Share knowledge with others

And it builds a public record of your progress.

What Kinds of Projects Will Be Included?

The challenge spans multiple areas of computer science and engineering.

Some examples of topics I plan to explore:

Web development tools and libraries
AI-powered applications
Embedded systems experiments
IoT devices
3D computer graphics (OpenGL / Vulkan etc.)
Low-level system programming
Networking tools
Developer utilities
Open source contributions
Game development experiments

Each project focuses on one meaningful concept.

For example:

Building a feature flag engine
Implementing a mini task scheduler
Creating a simple TCP protocol
Writing a CLI tool that solves a real problem
Integrating an AI agent into an application

Small projects, but real engineering ideas.
You can adjust those to align with your preferences and interests.

Why This Challenge Is Powerful

This approach solves several problems developers face:

Tutorial Hell: You stop watching tutorials and start building things yourself.
Fear of New Technologies: Instead of committing months to something new, you try it in a one-week experiment.
Lack of Portfolio Projects, after 100 projects, you’ll have:
- dozens of repositories
- many documented experiments
- experience across multiple domains
- That’s far more interesting than another CRUD app.
Real Engineering Experience. Each project teaches something concrete, in my case:
- networking fundamentals
- secure coding practices
- graphics pipelines
- embedded development
- AI integration patterns

Over time, the knowledge compounds.

How the challenge works

Coming up with project ideas sucks, and it is the reason many beginners feel overwhelmed or clueless, so you don't have to do it, I wrote this prompt which you can edit according to your preferences and paste it into your AI assistant

# 100 projects in 100 days challenge.
The goal of this challenge is to build 100 meaningful coding projects in a short time period (may be more than 100 days in total) where I get to research, learn and experience with different languages, concepts, fields and tools. The project is going to consist of 100 different coding projects that are short and sweet, completable in the minimum of 1 day and the maximum of 1 week, with every project providing a real value I can take out. The rules consist of the following: 
- Every project should touch something meaningful I can learn from, basic things like To-Do lists, Crud Apps, ECommerce websites etc. 

- Projects should not be a single language, they should force exploration and working in different languages and environment, while being welcoming if the challenger is new to the language 

- Each project should leverage one tool or topic that would benefit the challenger with a real value 

- Each project can be completed in the minimum of 1 day and the maximum of 1 week, and the challenger can NOT start a new project before confirming they finished the current one. 

- Project topics include to web and application development, embedded systems, IoT software, Low level system programming, AI engineering (integrating AI into real projects using agentic systems or APIs), game development, open source, computer graphics (preferably Vulkan, could go with OpenGL if the entry barrier for Vulkan is not beginner friendly), computer networks etc. The projects should not be too unrelated or teach a skill that is unrelated, the goal is to build something real and get real skills and get into that field. 

- Projects should be welcomed to new comers, and should be doable if the challenger has 0 experience in the field. 

- Every Project should teach the challenger something about the field it's related to, the challenger should finish a project with a related skill they can take home (e.g. a minimal http server, if the project is related to systems and computer networks) 

- Every project idea will be generated by you with a section mentioning prerequisites, key skills, background assumptions and a quick guide to get started with resource and references. The challenger can request a reroll if they feel the project is too hard or too easy. 

- Every project should be documented whether it's a short article on a platform like DEV.to or a personal blog, or an open source repository with well written documentation The project aims to give the challenger a chance to get into the provided fields, by having real skills and meaningful experience to go further and expand in these topics and fields.

<You can add any other custom instructions here>

Paste this to your AI assistant and update it every time you finish a project.

For each project:

The idea is generated.
The project includes:
- prerequisites
- key skills
- a quick guide to get started

The project is built.
The results are documented publicly.
If a project turns out to be too difficult or too trivial, it can be rerolled.

The goal isn’t punishment, the goal is learning.

The Real Goal

The purpose of this challenge isn’t just completing 100 projects.
It’s about becoming comfortable building things in unfamiliar territory.

By the end of the challenge I hope to have:

explored many areas of computer engineering
developed practical skills in multiple domains
built a large collection of real projects
documented the entire journey

And hopefully helped others start their own challenges too.

If you’ve ever felt stuck in tutorial hell or unsure how to explore new technologies…

Try building 100 small, meaningful projects.

You might be surprised how much you learn.

StudyAI: Transform PDFs into interactive study materials with AI

Abdulaziz Hamzah — Tue, 03 Mar 2026 14:38:50 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

I built StudyAI, an interactive study tool that transforms uploaded PDF files into:

Smart flashcards
Auto-generated quizzes
Structured study notes

Which happens using your own API key, which never leaves the browser, making sure your data stays secure.

The goal was simple: reduce the friction between reading and actually retaining information. Instead of passively scrolling for hours through PDFs, students can actively engage with their material in seconds.

The application is powered by Gemini 2.5 Flash by Google AI Studio, which handles the content generation pipeline via API integration.

Google Gemini played a major role throughout the entire lifecycle of this project:

Designing the UI/UX of the application
Implementing the core components and functionality
Building the initial prototype and MVP skeleton
Powering the study generation features through its API

This wasn't just an AI feature added at the end, Gemini was part of both the development and runtime layers of the project.

Demo

You can try the project yourself here:

👉 Live Demo: https://studyai-alpha.vercel.app/

The project is also fully open source:

👉 GitHub Repository: https://github.com/Azizham66/StudyAI

Feel free to explore the codebase, open issues, or contribute.

What I Learned

I had been wanting to seriously build something with Next.js for a while, but never had the right idea. This project gave me the push I needed.

While building StudyAI, I gained hands-on experience with:

Static Site Generation (SSG), Server-Side Rendering (SSR), and Client-Side Rendering (CSR)
The difference between Server and Client Components
Building API routes using the App Router
Handling file uploads securely and processing them server-side
Clean routing without relying on external routing libraries
Structuring scalable full-stack applications

Beyond Next.js, I learned how to design a production-ready AI-powered application:

Structuring prompts for predictable AI output
Managing AI response formatting
Handling token limits and latency trade-offs
Integrating AI into real-world workflows instead of treating it as a novelty feature

This project shifted my mindset from “adding AI” to “designing with AI.”

Google Gemini Feedback

Using Google Gemini to build a full application was an insightful experience.

Where Gemini Shined

Strong UI/UX design suggestions
Rapid scaffolding of components
Generating structured content like quizzes and flashcards
Helping prototype ideas extremely quickly

Where Gemini Struggled

Type safety issues: It frequently defaulted to using explicit any, which required manual refactoring to maintain TypeScript standards.
Context window drift: After extended prompting sessions, it sometimes lost context and generated irrelevant or conflicting code.
Unoptimized React components: In several cases, it produced components that caused unnecessary re-renders or inefficient patterns, leading to performance issues that required manual optimization.

These friction points weren't blockers, but they highlighted the importance of reviewing and refining AI-generated code rather than blindly accepting it.

Overall, Gemini significantly accelerated development, but real human intervention remained critical. Reviewing architecture decisions, enforcing type safety, optimizing performance, and validating logic highlighted the importance of never taking AI-generated code at face value.

Qur'an Search MCP Server

Abdulaziz Hamzah — Mon, 02 Mar 2026 00:04:47 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

This project was built to help the Muslim dev community build faster and more efficient AI powered applications

What I Built

When I was browsing, I found an open source project that caught my eye, it was a Qur'an search engine built with TypeScript and published as an NPM package, so I thought to myself to use this to solve a very common problem.

😵‍💫 Problem: whenever AI agents are asked religious questions or questions related to the Qur'an (the holy book of Islam) it would either give out misinformation, which is problematic especially when the question is related to the person's religion and religious practices, or in the better case, it would have to search the web, which spends more tokens and is slower, so I thought I will take the exiting engine and build an MCP adaptation layer on top of it.

✅ Result: When prompted, the AI agent will use the search tool to search locally using Arabic optimized search engine, which will give more accurate information as well as removing the need for online searches and optimize token usage and response speed.

Demo

Video Demo

Code

Github Repo Link

How I Built It

Building the Quran Search MCP was an exercise in transforming a high-performance TypeScript library into a standardized AI tool. Here is the concise breakdown of the development process:

Architectural Foundation:
I adopted a pnpm Monorepo structure to decouple the core search logic from the MCP communication layer. This ensured that the quran-search-engine remained a pure dependency, while the mcp-server acted as the specialized interface for LLMs.
High-Performance Data Bootstrapping:
To eliminate search latency, I implemented a Singleton Data Cache. Using Promise.all(), the server concurrently loads the Quranic text, morphological maps, and word indexes into memory during the initial handshake. This ensures sub-millisecond response times for the AI.
Protocol Integration:
Using the official MCP SDK, I mapped the engine’s search capabilities to a structured toolset. I utilized Zod schemas to strictly define search parameters (fuzzy, exact, prefix), ensuring the AI assistant provides valid, typed inputs that the engine can process without errors.
Dual-Purpose Distribution:
I configured the package for Dual-Mode Usage:
CLI: Optimized for immediate use via npx for AI Desktop clients.
Library: Used Subpath Exports in package.json so developers can import the engine or the server independently into their own TypeScript projects.
Validation & Stress Testing:
I bypassed the GUI and tested the integration using JSON-RPC piping. By feeding raw JSON strings directly into the server via the terminal, I verified protocol compliance and error handling before the first deployment.

Building a Quran Search MCP Server: From Monorepo to npm Package

Abdulaziz Hamzah — Sat, 28 Feb 2026 19:23:55 +0000

Today I want to share the journey of building a complete Quran Search MCP (Model Context Protocol) server that bridges AI assistants with powerful Quran search capabilities. This project showcases how to transform an existing search engine into an MCP-compatible server while maintaining clean architecture.

The Challenge

The goal was to create an MCP server that exposes the excellent quran-search-engine by Adel Benyahia to AI assistants through the Model Context Protocol. The original engine is a powerful TypeScript library for searching Quranic text with morphological analysis, fuzzy matching, and advanced features.

Architecture Decisions

Monorepo Structure

I chose a monorepo approach to separate concerns:

quran-search-MCP/
├── packages/
│   └── quran-search-engine/     # Original search engine 
├── mcp-server/                  # MCP server adaptation
│   ├── src/                     # Server source code
│   │   ├── data/                # Data caching module
│   │   ├── handlers/            # Search handlers
│   │   ├── tools/               # MCP tools
│   │   ├── types/               # Type definitions
│   │   └── index.ts             # Server entry point
│   ├── dist/                    # Built server files
│   ├── package.json              # Server package config
│   └── tsconfig.json           # TypeScript config
├── README.md                    # This documentation
├── CHANGELOG.md                 # Version history
└── package.json                 # Workspace configuration

Why this structure?

Clear separation: Engine and server concerns are isolated
Reusability: Engine can be used independently
Maintainability: Each package has its own lifecycle
Testing: Engine tests run separately from server logic

Data Loading Strategy

The MCP server needed to load three key datasets:

// Data caching implementation
export const loadDataCache = async (): Promise<DataCache> => {
  const [quranData, morphologyMap, wordMap] = await Promise.all([
    loadQuranData(),
    loadMorphology(),
    loadWordMap(),
  ]);

  dataCache = {
    quranData,           // Complete Quranic verses
    morphologyMap,      // Morphological analysis per verse
    wordMap,           // Word-to-verse mappings
  };

  return dataCache;
};

Performance benefits:

Single load: All data loaded once during server bootstrap
Memory efficiency: Data cached for fast access
Parallel loading: All three datasets loaded concurrently

MCP Implementation

Server Setup

The MCP server uses the official MCP SDK:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';

async function bootstrap() {
  await loadDataCache();

  const server = new McpServer({
    name: 'quran-search-engine-mcp',
    version: '0.1.0',
  });

  registerSearchTools(server);
  const transport = new StdioServerTransport();
  await server.connect(transport);

  return server;
}

Tool Registration

The search tool is registered with Zod schema validation:

server.registerTool(
  'search',
  {
    title: 'search',
    description: 'Search Quran',
    inputSchema: z.object({
      query: z.string(),
      options: z.object({
        limit: z.number().optional(),
        matchType: z.enum(['exact', 'fuzzy', 'prefix']).optional(),
        includeMorphology: z.boolean().optional(),
      }).optional(),
    }),
  },
  async ({ query, options }) => {
    // Search implementation
  }
);

Dual Export Strategy

The package supports both CLI and library usage:

CLI Usage

npx quran-search-mcp

Library Usage

import { createServer } from 'quran-search-mcp';

const server = await createServer();

Subpath Exports

{
  "exports": {
    ".": {
      "types": "./mcp-server/dist/index.d.ts",
      "import": "./mcp-server/dist/index.js",
      "require": "./mcp-server/dist/index.js"
    },
    "./engine": {
      "types": "./packages/quran-search-engine/dist/index.d.ts",
      "import": "./packages/quran-search-engine/dist/index.mjs",
      "require": "./packages/quran-search-engine/dist/index.js"
    }
  }
}

Build Process

TypeScript Compilation

Both packages use TypeScript but with different build tools:

Engine: Uses tsup for bundling with multiple outputs

{
  "scripts": {
    "build": "tsup"
  }
}

MCP Server: Uses tsc for direct compilation

{
  "scripts": {
    "build": "tsc"
  }
}

Workspace Scripts

The root package orchestrates both builds:

{
  "scripts": {
    "build": "pnpm -C packages/quran-search-engine build && pnpm -C mcp-server build",
    "build:engine": "pnpm -C packages/quran-search-engine build",
    "build:mcp": "pnpm -C mcp-server build",
    "prepublishOnly": "pnpm run build"
  }
}

Key Features Implemented

Search Capabilities

Exact Search: Find exact Arabic text matches
Fuzzy Search: Find similar words and phrases
Prefix Search: Find words starting with specific prefixes
Morphological Analysis: Search by lemma and root words
Pagination: Control result sets with limit and offset

Performance Optimizations

Data Caching: Quran data loaded once at startup
Memory Efficient: Optimized data structures
Type Safety: Full TypeScript support with Zod validation
Error Handling: Comprehensive error handling and logging

npm Package Configuration

Complete Package Setup

{
  "name": "quran-search-mcp",
  "version": "0.1.0",
  "description": "Quran Search Engine MCP Server - Complete package with engine and server",
  "main": "./mcp-server/dist/index.js",
  "bin": {
    "quran-search-mcp": "./mcp-server/dist/index.js"
  },
  "files": [
    "mcp-server/dist",
    "packages/quran-search-engine/dist",
    "CHANGELOG.md"
  ]
}

Repository Structure

GitHub: https://github.com/Azizham66/quran-search-MCP
License: MIT
Attribution: Proper credit to original quran-search-engine project

Testing & Validation

Manual MCP Testing

# Test tools list
echo '{"jsonrpc": "2.0", "method": "tools/list", "params": {}, "id": 1}' | npx quran-search-mcp

# Test search functionality
echo '{"jsonrpc": "2.0", "method": "tools/call", "params": {"name": "search", "arguments": {"query": "الرحمن"}}, "id": 2}' | npx quran-search-mcp

Build Verification

# Both packages build successfully
pnpm build

# Engine tests pass
pnpm test

Challenges & Solutions

Challenge 1: Workspace Dependencies

Problem: MCP server needed to import engine package
Solution: Used workspace:* dependency and proper pnpm workspace configuration

Challenge 2: Data Loading

Problem: Large Quran datasets could slow startup
Solution: Implemented singleton cache with Promise.all() for parallel loading

Challenge 3: Dual Usage

Problem: Support both CLI and library usage
Solution: Added direct execution check and proper exports

Challenge 4: Type Safety

Problem: MCP protocol requires strict schema validation
Solution: Used Zod for runtime validation and TypeScript for compile-time safety

What I Learned

Monorepo Benefits: Clear separation of concerns while maintaining unified development
MCP Protocol: Standardized way to expose tools to AI assistants
Performance Matters: Data caching strategies significantly impact user experience
Export Strategy: Dual exports (main package + subpaths) provide flexibility
Build Tools: Different tools serve different purposes (tsup vs tsc)
Documentation: Accurate, up-to-date docs are crucial for adoption

Future Improvements

Potential Enhancements

Streaming Results: For large search result sets
Caching Layer: Redis or similar for distributed deployments
Plugin System: Allow custom search algorithms
Multiple Transports: Support HTTP, WebSocket beyond stdio
Advanced Search: Boolean queries, phrase search, proximity search

Conclusion

Building the quran-search-mcp package was a rewarding experience in combining existing powerful libraries with modern protocols. The monorepo structure provides maintainability while the MCP integration makes it accessible to AI assistants.

Special thanks to Adel Benyahia for creating the excellent quran-search-engine library that made this MCP adaptation possible. His work on Arabic text processing, morphological analysis, and search algorithms provided the solid foundation needed for this project.

The key was respecting the original quran-search-engine's excellence while building a clean, standards-compliant adaptation layer that adds value without reinventing the wheel.

Try it out:

npm install quran-search-mcp
npx quran-search-mcp

The project is ready for production use and welcomes contributions from the community!

Built with ❤️ for the Muslim community and AI developers worldwide

Special thanks to Adel Benyahia for the foundational quran-search-engine library

🚀 WATele-Bridge: A Telegram ↔ WhatsApp Bridge

Abdulaziz Hamzah — Wed, 17 Sep 2025 09:28:27 +0000

I recently worked on a project that let me explore some exciting areas like:

Building Telegram bots
Using WhatsApp APIs
Playing with asynchronous programming
Developing and consuming APIs

The result? 👉 WATele-Bridge – a simple, self-hosted bridge between Telegram and WhatsApp.

🔧 How It Works

The project has two main parts:

Telegram Bot (Python, Telethon)

Listens for new messages from a user-specified chat, group, or channel.
Whenever a new message arrives, it triggers an event handler.
That event makes an HTTP request to an API endpoint.

WhatsApp API (Node.js, '@whiskeysockets/Baileys')

Exposes a send-message endpoint.
Receives the incoming request from the Telegram bot.
Forwards the message directly to WhatsApp.

This essentially creates a Telegram → WhatsApp relay.

⚡ Why I Built This

I wanted to:

Learn Telethon for Telegram bot development.
Explore Baileys (a popular WhatsApp Web API library).
Understand how to design async message handling.
Practice building and integrating a small microservice API.

It’s a great project if you’re curious about combining different chat platforms or experimenting with real-time communication apps.

🚀 Try It Yourself

You can self-host the project with the instructions in the repo:
👉 github.com/Azizham66/WATele-Bridge
Feel free to fork it, tweak it, or use it as a foundation for your own automation ideas!

🤝 Contribute

This is still a work in progress, and contributions are very welcome. Some possible improvements:

Adding support for two-way sync (WhatsApp → Telegram)
Deployment scripts (Docker, PM2)
Better logging and error handling
Adding the ability to listen from multiple Telegram chats

💡 Final Thoughts

This was a fun experiment that combined multiple APIs and asynchronous programming. If you’ve ever wanted to link two messaging platforms, this project might give you a head start.