Forem: Ibrahim Pelumi Lasisi

Self-Hosted Ngrok Alternative in 200 Lines of Node.js

Ibrahim Pelumi Lasisi — Mon, 02 Feb 2026 04:13:32 +0000

Self-Hosted Ngrok in 200 Lines of Node.js

Problem: Need to tunnel multiple local services. Ngrok free tier = 1 tunnel.

Solution: Built my own. Took 4 hours.

What It Does

liptunnel http 3000,8080,5000 --multi

Creates 3 public URLs on your domain. One command.

The Architecture

User → yourdomain.com → VPS → WebSocket → Your PC → localhost

Core concept:

// Server: Forward HTTP via WebSocket
app.use((req, res) => {
  const subdomain = req.headers.host.split('.')[0];
  tunnels[subdomain].ws.send(JSON.stringify(req));
  // Wait for response, send back
});

// Client: Receive, proxy, respond
ws.on('message', (data) => {
  http.request('localhost:3000', data.request, (response) => {
    ws.send(response);
  });
});

That's the entire concept. The rest is error handling.

Why Self-Host?

✅ Privacy - Your traffic stays yours

✅ Cost - $0 beyond your VPS

✅ Branding - Your domain

✅ Control - Customize everything

Performance

Memory: 25MB/tunnel
Latency: ~5ms overhead
Throughput: 100+ req/sec
Setup: 5 minutes

Use Cases

Microservices: Tunnel entire stack locally

Webhooks: Test Stripe/GitHub without deploying

Demos: Client-branded URLs

Compliance: Healthcare/finance (no third parties)

Get Started

Full code + docs:

👉 github.com/ibrahimpelumi6142/liptunnel

git clone https://github.com/ibrahimpelumi6142/liptunnel
npm install
node server/server.js  # On VPS
liptunnel http 3000    # Local

Tech Stack

Node.js (runtime)
WebSocket (tunnel)
Express (dashboard)

No frameworks. ~200 lines total.

What's Next

Coming soon:

HTTPS (Let's Encrypt)
Fixed subdomains
Auth tokens
Request inspector

Try It

⭐ Star on GitHub

Questions? Drop them below 👇

Tags: #nodejs #opensource #webdev #selfhosted

WhatsApp: The Future of Customer Communication (A Developer's Perspective)

Ibrahim Pelumi Lasisi — Wed, 24 Dec 2025 19:10:43 +0000

As developers, we're constantly searching for the most efficient ways to connect businesses with their customers. After building customer communication systems for years, I've come to a realization: WhatsApp isn't just another messaging platform—it's becoming the backbone of modern customer communication. Here's why you should care, and how to leverage it in your applications.

The Numbers Don't Lie

With over 2 billion active users across 180+ countries, WhatsApp has achieved something remarkable: it's become the default communication method for billions of people. Unlike email (which has a dismal 20% open rate) or SMS (expensive and limited), WhatsApp messages boast a 98% open rate and 45-60% click-through rates. From a technical standpoint, that's the kind of engagement metric that makes a developer's heart skip a beat.

Why Developers Should Embrace WhatsApp Business API

1. Users Are Already There

The biggest friction in any communication system is adoption. With WhatsApp, there's zero friction—your users already have the app installed, they check it multiple times daily, and they're comfortable using it. No app downloads, no new account creation, no onboarding tutorials. Just pure, immediate communication.

2. Rich Media and Interactive Experiences

Gone are the days of plain-text notifications. The WhatsApp Business API lets you build rich, interactive experiences:

# Example: Sending an interactive button message
import requests
import json

def send_button_message(phone_number, order_id):
    message = {
        "messaging_product": "whatsapp",
        "to": phone_number,
        "type": "interactive",
        "interactive": {
            "type": "button",
            "body": {
                "text": f"Your order #{order_id} is ready for pickup!"
            },
            "action": {
                "buttons": [
                    {
                        "type": "reply",
                        "reply": {
                            "id": "confirm_pickup",
                            "title": "Confirm Pickup"
                        }
                    },
                    {
                        "type": "reply",
                        "reply": {
                            "id": "reschedule",
                            "title": "Reschedule"
                        }
                    }
                ]
            }
        }
    }

    response = requests.post(
        f"https://graph.facebook.com/v18.0/{PHONE_NUMBER_ID}/messages",
        headers={
            "Authorization": f"Bearer {ACCESS_TOKEN}",
            "Content-Type": "application/json"
        },
        json=message
    )

    return response.json()

You can send images, documents, location data, product catalogs, and even create conversational flows with buttons and quick replies. It's like building a mini-app inside a chat interface.

3. End-to-End Encryption by Default

Security isn't an afterthought with WhatsApp—it's baked in. Every message is end-to-end encrypted, which means you can handle sensitive customer data with confidence. For fintech, healthcare, or any industry dealing with private information, this is massive.

4. Two-Way Conversations That Actually Work

Unlike traditional SMS or email notifications that feel like shouting into the void, WhatsApp enables genuine two-way conversations. Customers can reply, ask questions, and interact naturally. Your application can listen for these responses and react accordingly.

from flask import Flask, request, jsonify

app = Flask(__name__)

# Webhook handler for incoming messages
@app.route('/webhook', methods=['POST'])
def webhook():
    data = request.get_json()

    # Extract message from webhook payload
    try:
        message = data['entry'][0]['changes'][0]['value']['messages'][0]

        if message['type'] == 'text':
            customer_response = message['text']['body']
            phone_number = message['from']

            # Process customer response
            handle_customer_reply(phone_number, customer_response)
    except (KeyError, IndexError):
        pass

    return jsonify({"status": "success"}), 200

def handle_customer_reply(phone_number, message):
    # Your logic here
    print(f"Received from {phone_number}: {message}")

Real-World Use Cases I've Implemented

Order Updates and Delivery Tracking

Customers obsessively check delivery status. Instead of them refreshing your app every five minutes, send proactive WhatsApp updates:

Order confirmed ✅
Being prepared 👨‍🍳
Out for delivery 🚚
Delivered successfully 📦

Each update can include tracking links, estimated times, and interactive buttons for actions like "Contact Driver" or "Report Issue."

Customer Support Revolution

Traditional support tickets feel impersonal and slow. WhatsApp support feels like texting a friend who actually wants to help. I've seen support resolution times drop by 60% after implementing WhatsApp-based support.

# Route support conversation to available agent
async def route_to_agent(customer_id, message):
    agent = await find_available_agent()

    await create_support_session({
        'customer_id': customer_id,
        'agent_id': agent.id,
        'channel': 'whatsapp',
        'initial_message': message
    })

    # Notify agent via your internal system
    notify_agent(agent, customer_id, message)

Appointment Reminders and Confirmations

No-shows cost businesses billions annually. WhatsApp reminders with one-tap confirmation buttons reduce no-shows by up to 40%:

Send reminder 24 hours before
Customer confirms with a button tap
Automatically update your booking system
Send last-minute reminder 2 hours before

Transactional Notifications

Payment confirmations, password resets, subscription renewals—all those critical transactional messages that often get lost in email spam folders. On WhatsApp, they're seen within minutes.

Getting Started: The Technical Implementation

Step 1: Set Up WhatsApp Business API

You'll need:

A Meta Business Account
WhatsApp Business API access
A phone number to use as your business number
Webhook endpoint for receiving messages

Step 2: Choose Your Approach

Option A: Direct API Integration
Full control, but more complex setup. Great if you're building at scale.

Option B: Use a Cloud API Provider
Meta's Cloud API or providers like Twilio, MessageBird, or 360dialog. Faster setup, managed infrastructure.

Option C: Business Solution Provider (BSP)
Full-service platforms that handle everything. Best for rapid deployment.

Step 3: Build Your Webhook Handler

from flask import Flask, request, jsonify
import os

app = Flask(__name__)

# Webhook verification (required by Meta)
@app.route('/webhook', methods=['GET'])
def verify_webhook():
    mode = request.args.get('hub.mode')
    token = request.args.get('hub.verify_token')
    challenge = request.args.get('hub.challenge')

    if mode == 'subscribe' and token == os.getenv('VERIFY_TOKEN'):
        return challenge, 200
    else:
        return 'Forbidden', 403

# Handle incoming messages
@app.route('/webhook', methods=['POST'])
def handle_webhook():
    data = request.get_json()

    if data.get('object') == 'whatsapp_business_account':
        for entry in data.get('entry', []):
            for change in entry.get('changes', []):
                if 'messages' in change.get('value', {}):
                    process_incoming_message(change['value']['messages'][0])

    return jsonify({"status": "success"}), 200

def process_incoming_message(message):
    # Your message processing logic here
    print(f"Processing message: {message}")

if __name__ == '__main__':
    app.run(debug=True)

Step 4: Send Your First Message

import requests
import os

def send_whatsapp_message(to, message):
    """Send a text message via WhatsApp Business API"""

    url = f"https://graph.facebook.com/v18.0/{os.getenv('PHONE_NUMBER_ID')}/messages"

    headers = {
        'Authorization': f"Bearer {os.getenv('ACCESS_TOKEN')}",
        'Content-Type': 'application/json'
    }

    payload = {
        'messaging_product': 'whatsapp',
        'to': to,
        'type': 'text',
        'text': {'body': message}
    }

    response = requests.post(url, headers=headers, json=payload)
    return response.json()

# Example usage
result = send_whatsapp_message('+1234567890', 'Hello from Python!')
print(result)

Best Practices I've Learned the Hard Way

1. Respect the 24-Hour Window

WhatsApp has a 24-hour customer service window. After a customer messages you, you have 24 hours to respond freely. After that, you need to use pre-approved message templates. Plan your conversation flows accordingly.

2. Design for Mobile First

Your messages will be read on phones. Keep text concise, use emojis strategically, and make buttons large and clear. Test everything on actual devices.

3. Handle Opt-Ins Properly

Always get explicit consent before messaging customers. Build a clear opt-in flow and respect opt-outs immediately. This isn't just good practice—it's required.

4. Monitor Message Quality Ratings

WhatsApp monitors how users interact with your messages. If too many people block your number or mark messages as spam, you'll lose access. Focus on sending valuable, timely messages that users actually want.

5. Build for Scale from Day One

Even if you're starting small, design your system to handle volume. Use message queues, implement rate limiting, and build proper error handling. WhatsApp has rate limits, and you don't want to hit them during a critical send.

The Future is Conversational Commerce

We're moving toward a world where customers don't need separate apps for every business they interact with. They just chat. Need to order food? Chat. Check bank balance? Chat. Schedule a doctor's appointment? Chat.

WhatsApp is positioning itself at the center of this shift. With features like WhatsApp Payments, product catalogs, and shopping buttons, the line between communication and commerce is disappearing.

As developers, we have the opportunity to build these experiences now. The businesses that embrace conversational commerce early will have a significant advantage.

My Final Take

After implementing WhatsApp communication systems for everything from e-commerce to healthcare, I can confidently say it's not hype, it's a fundamental shift in how businesses and customers interact. The API is robust, the documentation is solid, and the user base is massive.

Is it perfect? No. There's a learning curve, compliance requirements to navigate, and you're building on someone else's platform. But the engagement metrics speak for themselves, and the developer experience keeps improving.

If you're building any application that involves customer communication, WhatsApp integration should be in your roadmap. Your customers are already there, waiting to hear from you.

Resources to Get Started

Have you implemented WhatsApp in your applications? What challenges did you face? Drop your experiences in the comments—I'd love to hear what's working for you.

Which Telegram Bot Library Should You Use? (Beginner-Friendly Guide)

Ibrahim Pelumi Lasisi — Thu, 11 Dec 2025 16:14:54 +0000

Which Telegram Bot Library Should You Use? (Beginner-Friendly Guide)

Telegram bots are everywhere now—automation, e-commerce, customer support, and even AI assistants. But new developers often struggle to pick between:

Raw Telegram Bot API
python-telegram-bot
telebot (PyTelegramBotAPI)

Here’s a simple, beginner-friendly breakdown based on real experience.

If You Are a Beginner → Use Telebot

Telebot is the easiest and fastest way to start.

Why it's perfect for beginners:

Zero setup
Readable decorators
Simple message handlers
Worked by millions of developers

Example:

import telebot
bot = telebot.TeleBot("TOKEN")

@bot.message_handler(commands=['start'])
def start(message):
    bot.reply_to(message, "Hello!")

bot.infinity_polling()

Done. Your bot works.

If You Want Power → Use **python-telegram-bot

This is the most advanced library.

Why it's great:

Async support
Best for production
Large modular architecture
Cleaner webhook support

Example:

from telegram.ext import ApplicationBuilder, CommandHandler

async def start(update, context):
    await update.message.reply_text("Hello!")

app = ApplicationBuilder().token("TOKEN").build()
app.add_handler(CommandHandler("start", start))
app.run_polling()

If You Want Full Control → Use Raw Telegram API

Use when:

Building custom frameworks
Integrating with unusual infrastructure

Example:

import requests

requests.post(
  f"https://api.telegram.org/botTOKEN/sendMessage",
  json={"chat_id": "ID", "text": "Hello!"}
)

Summary — Which Should You Choose?

Goal	Best Choice
Learn quickly	Telebot
Build production bot	python-telegram-bot
Build custom system	Raw API

Final Advice

If you're new to Telegram bots:

✔ Start with Telebot
✔ Move to python-telegram-bot when you're ready
✔ Use Raw API only when necessary

Source Code + Extra Examples

All sample code and detailed comparison tables are available on GitHub:

👉 GitHub Repository:
https://github.com/ibrahimpelumi6142/telegram-bot-api-vs-telebot

About the Author

Lasisi Ibrahim Pelumi
Full-stack Engineer • Automation Developer • Bot Specialist
Building AI-driven automation tools using WhatsApp, Telegram, Node.js, Python, and FastAPI.

Running FastAPI in Production on a VPS (Step-by-Step)

Ibrahim Pelumi Lasisi — Wed, 10 Dec 2025 00:58:25 +0000

FastAPI makes it super easy to build APIs — but deploying it to real production on a VPS is where many developers get stuck.

Over the past months, I’ve deployed multiple FastAPI services (APIs, webhooks, and automation backends) to VPS servers for real users. In this guide, I’ll walk through a clean, production-ready setup you can reuse for your own projects.

We’ll go from:

main.py on your laptop → Live HTTPS API on a VPS with gunicorn, uvicorn, systemd, and nginx.

What We’ll Build

We’ll deploy a FastAPI app so that:

It runs behind gunicorn + uvicorn workers
It’s managed by systemd (auto-start on reboot, restart on crash)
It’s served via nginx as a reverse proxy
It’s protected with HTTPS using Let’s Encrypt
It uses environment variables for secrets (no hardcoded tokens)
It’s easy to update with a simple git pull + restart

I’ll assume:

You’re using Ubuntu 20.04+ on your VPS
You have SSH access
You have a domain pointing to the VPS IP (optional but recommended)

Create a Minimal FastAPI App

On your local machine (or directly on the server), create a basic FastAPI app:

mkdir fastapiapp
cd fastapiapp
python -m venv venv
source venv/bin/activate   On Windows: venv\Scripts\activate
pip install fastapi uvicorn[standard]

Create app/main.py:

from fastapi import FastAPI

app = FastAPI()


@app.get("/")
async def read_root():
    return {"message": "Hello from FastAPI on VPS!"}

Test locally:

uvicorn app.main:app --reload

If it works locally, we’re ready to move to the VPS.

Connect to Your VPS

From your local terminal:

ssh root@YOUR_SERVER_IP

(Replace root with your username if you’re using a non-root user.)

Update packages:

apt update && apt upgrade -y

Install some essentials:

apt install -y git python3 python3-venv python3-pip nginx

Clone Your FastAPI Project to the VPS

Inside your server:

cd /opt
git clone https://github.com/ibrahimpelumi6142/fastapi-production-guide
cd fastapi-production-guide
python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip
pip install fastapi uvicorn[standard] gunicorn

(If your project is private, use ssh clone or GitHub deploy keys.)

You should now have:

fastapi-production-guide/
├── app/
│   └── main.py
├── nginx/
│   └── fastapi.conf
├── systemd/
│   └── fastapi.service
├── .env.example
├── requirements.txt
└── README.md

Run FastAPI with Gunicorn + Uvicorn Workers

Instead of running plain uvicorn, in production we use gunicorn to manage multiple uvicorn workers.

From /opt/fastapiapp:

source venv/bin/activate
gunicorn -k uvicorn.workers.UvicornWorker app.main:app --bind 0.0.0.0:8000 --workers 3

Your app should be available on port 8000:

curl http://127.0.0.1:8000/

If you see:

{"message":"Hello from FastAPI on VPS!"}

We’re good.

Now we’ll turn this into a service.

Create a systemd Service (So It Runs in the Background)

We don’t want to manually start gunicorn every time.
We’ll use systemd to manage it like a proper service.

Create a service file:

nano /etc/systemd/system/fastapi.service

Paste this (update paths/usernames where needed):

[Unit]
Description=Gunicorn instance to serve FastAPI app
After=network.target

[Service]
User=root
WorkingDirectory=/opt/fastapi-production-guide
Environment="PATH=/opt/fastapi-production-guide/venv/bin"
ExecStart=/opt/fastapi-production-guide/venv/bin/gunicorn -k uvicorn.workers.UvicornWorker app.main:app --bind 0.0.0.0:8000 --workers 3

Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Save and exit.

Reload systemd:

systemctl daemon-reload
systemctl start fastapi
systemctl enable fastapi

Check status:

systemctl status fastapi

If it’s active (running), your backend is now running in the background, even if you log out.

Configure Nginx as a Reverse Proxy

We don’t expose gunicorn directly to the internet. Instead, we let nginx:

Handle HTTP(S)
Proxy requests to 127.0.0.1:8000
Deal with static files (if needed)
Improve security & performance

Create a new Nginx config:

nano /etc/nginx/sites-available/fastapi

If you have a domain, use it. If not, you can temporarily use the server IP.

server {
    listen 80;
    server_name YOUR_DOMAIN_NAME_HERE;   or your server IP

    location / {
        proxy_pass         http://127.0.0.1:8000;
        proxy_redirect     off;

        proxy_set_header   Host                 $host;
        proxy_set_header   X-Real-IP            $remote_addr;
        proxy_set_header   X-Forwarded-For      $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto    $scheme;
    }
}

Enable this site:

ln -s /etc/nginx/sites-available/fastapi /etc/nginx/sites-enabled/
rm /etc/nginx/sites-enabled/default   optional, remove default site
nginx -t
systemctl restart nginx

Now, visit:

http://YOUR_DOMAIN_NAME/ or
http://YOUR_SERVER_IP/

You should see your FastAPI JSON response.

Add HTTPS with Let’s Encrypt (Certbot)

Never leave a public API on pure HTTP.

Install Certbot:

apt install -y certbot python3-certbot-nginx

Run:

certbot --nginx -d YOUR_DOMAIN_NAME_HERE

Follow the prompts:

Provide email
Accept terms
Choose redirect option → Redirect all traffic to HTTPS

After this, your site is live at:

https://YOUR_DOMAIN_NAME/

Certbot also sets up automatic certificate renewal.

Using Environment Variables for Secrets

Never hardcode secrets like:

API keys
Database credentials
JWT secrets

In your app, use os.getenv or pydantic BaseSettings.

Example: app/config.py

from pydantic import BaseSettings


class Settings(BaseSettings):
    app_name: str = "My FastAPI App"
    secret_key: str
    debug: bool = False

    class Config:
        env_file = ".env"


settings = Settings()

In main.py:

from fastapi import FastAPI
from .config import settings

app = FastAPI(title=settings.app_name)

On the server, create .env in /opt/fastapiapp:

nano /opt/fastapiapp/.env

Example:

SECRET_KEY=supersecretvalue
DEBUG=false

Restart the service:

systemctl restart fastapi

Now your secrets live outside the code.

Updating Your App (Deploying New Versions)

When you change your code on GitHub, deploy updates like this:

ssh root@YOUR_SERVER_IP
cd /opt/fastapiapp
git pull
source venv/bin/activate
pip install -r requirements.txt   if using one
systemctl restart fastapi

That’s it — instant deploy.

If you want smoother deploys, you can:

Add a deploy.sh script
Use systemctl reload for zero-downtime (with more advanced gunicorn configs)
Add logging to file + log rotation

Basic Logging & Monitoring

You can see logs via systemd:

journalctl -u fastapi -f

Or Nginx logs:

tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log

From here, you can integrate:

Uvicorn access logs
Centralized logging (e.g. Loki, ELK, etc.)
Health checks & uptime monitoring (e.g. UptimeRobot or Better Stack)

Common Mistakes to Avoid

Some things I’ve seen (and done myself) that cause pain in production:

❌ Running uvicorn directly in screen/tmux

If the terminal dies → app dies. Use systemd.

❌ Exposing port 8000 to the world

Always hide gunicorn/uvicorn behind Nginx.

❌ No HTTPS

APIs without HTTPS are insecure and sometimes blocked by clients.

❌ Hardcoding tokens in code

Always use .env + BaseSettings or environment variables.

❌ No restart policy

If your app crashes once and doesn’t restart, you’re down. systemd’s Restart=always saves you here.

When to Move Beyond a Single VPS

A single VPS with FastAPI + gunicorn + Nginx is great for:

MVPs
Side projects
Small SaaS
Internal tools
Bots & automation services

When do you outgrow it?

You need auto-scaling
You want zero-downtime blue/green deployments
You need container orchestration (Kubernetes, ECS, etc.)
You have many microservices and need a service mesh

But for 80% of real-world use cases, a well-configured VPS is more than enough, especially when you’re just shipping and proving value.

Conclusion

Deploying FastAPI to production doesn’t have to be scary.

With:

gunicorn + uvicorn workers
systemd to manage your process
nginx as a reverse proxy
Let’s Encrypt for HTTPS
environment variables for secrets

…you already have a solid, production-ready setup that many teams use in real products.

If you’re building something like a WhatsApp bot backend, job assistant, automation service, or SaaS API, this stack will carry you very far.

About the Author

I’m Lasisi Ibrahim Pelumi, a full-stack developer and automation engineer based in the UK. I build AI-powered products, automation tools, and APIs — including WhatsApp-based assistants and SaaS platforms deployed on VPS and cloud infrastructure.

You can find more of my work on:

GitHub: @ibrahimpelumi6142
LinkedIn: Lasisi Ibrahim Pelumi

How I Architected a Scalable WhatsApp Job Assistant (WorqNow)

Ibrahim Pelumi Lasisi — Tue, 09 Dec 2025 14:21:29 +0000

Over the past months, I’ve been building WorqNow, a WhatsApp-based AI Job Assistant that helps users find jobs, build CVs, get personalised recommendations, and learn career skills — all through simple natural-language chat.

What started as a small idea has grown into a system handling thousands of messages, real-time job searches across multiple APIs, personalised recommendations, and automated CV generation.

This article breaks down the engineering decisions, system architecture, scaling challenges, and technical lessons behind building a modern WhatsApp automation platform.

1. The Problem: Job Search is Broken for Millions

Most job seekers especially in Africa and emerging markets rely on:

Slow job websites
Fake job groups
Cluttered Telegram channels
Manual searches
Outdated listings

But almost everyone already uses WhatsApp, making it the perfect channel for:

Instant job alerts
Natural language search
Personalised recommendations
CV building
No sign-up, no app download

The challenge was building a system that feels like a human assistant but scales like a cloud platform.

2. High-Level Architecture Overview

Below is the simplified architecture that powers WorqNow:

User (WhatsApp)
     ↓
Meta WhatsApp Cloud API (Webhook)
     ↓
FastAPI Backend (Python)
     ├── Intent Recognition Engine
     ├── Job Aggregation Service
     ├── CV Builder Workflow
     ├── MongoDB User Store
     └── APScheduler (Background Jobs)
     ↓
External APIs:
     ├── Remotive API
     ├── JSearch API (RapidAPI)
     ├── AI Models for CV Drafting
     ↓
Response Sent Back to WhatsApp

This event-driven architecture allows WorqNow to remain fast, scalable, and modular.

3. Intelligent Intent Recognition

Real users don’t type commands like developers.
They type:

“find me backend jobs in london”
“I need a cv”
“my location is lagos”
“show me recommended jobs”

To support flexible language, I built a lightweight intent engine combining:

✓ Keyword extraction
✓ Fuzzy matching
✓ Context memory
✓ User profile learning

Example:

if fuzzy_match(["search", "find", "job"], message):
    intent = "keyword_search"
elif "location" in message or "in " in message:
    intent = "set_location"
elif fuzzy_match(["make cv", "build cv", "resume"], message):
    intent = "cv_builder"

This allows the bot to understand human language, not just strict commands.

4. Real-Time Job Aggregation Layer

WorqNow fetches live job data from two major APIs:

1. Remotive API

Fast and clean for remote-friendly jobs.

2. JSearch API (RapidAPI)

Great for country-specific searches.

To avoid hitting rate limits and to speed up response times, I built a combined aggregator:

async def search_jobs(keyword, location):
    remotive = fetch_remotive(keyword, location)
    jsearch = fetch_jsearch(keyword, location)

    results = merge_and_dedupe(remotive + jsearch)
    return results[:10]

This ensures:

Up to 10 high-quality jobs returned instantly
Duplicates removed
Faster response times

📍 5. Persistent User Profiles (MongoDB)

Every user has a personal profile stored in MongoDB:

{
  "wa_id": "234916XXXXXXX",
  "name": "John Doe",
  "preferred_location": "London",
  "search_history": ["backend developer", "ui/ux"],
  "subscription": true,
  "cv_state": {}
}

This allows WorqNow to:

Offer personalised job recommendations
Save preferred locations
Continue CV-building sessions
Send scheduled job alerts

MongoDB was chosen because:

It’s flexible
Schema-less
Great for user-driven apps
Handles rapid iteration

6. Background Schedulers for Job Alerts

I used APScheduler to run background tasks like:

Daily personalised job recommendations
CV reminder follow-ups
Category-specific job alerts
Admin broadcast messages

Example:

scheduler.add_job(
    send_daily_jobs,
    trigger="cron",
    hour=9,
)

This ensures users receive fresh jobs every morning without interacting manually.

7. CV Builder Workflow (Q&A Flow + PDF Generation)

The CV builder works through a guided WhatsApp conversation:

Ask for name
Ask for education
Ask for work experience
Ask for skills
Ask for projects
Auto-generate a professional CV using WeasyPrint
Send the final PDF back to the user

Template is powered by Jinja2 + HTML/CSS → PDF.

The workflow state is saved per user so they can continue anytime.

8. Scaling Challenges & Solutions

Challenge 1: Meta API Rate Limits

Solution: Message queue + retry logic

Challenge 2: FastAPI concurrency

Solution: Uvicorn with workers + async handlers

Challenge 3: Large job API responses

Solution: In-memory caching + deduping

Challenge 4: Natural language variability

Solution: Hybrid intent engine (keywords + fuzzy + context)

Challenge 5: User spikes during broadcasts

Solution: Batch sending + exponential backoff

💡 9. Key Technical Decisions That Made the System Scalable

Event-driven architecture (webhooks → handlers)
Async FastAPI instead of blocking frameworks
MongoDB for flexible user schemas
Scheduler for automation
Modular design for adding new features easily
Reusable message templates to keep responses consistent

WorqNow is now structured like a mini SaaS backend, not just a chatbot.

10. The Future of WorqNow

Upcoming features:

Machine-learning job recommendations
Voice message understanding
More APIs for job aggregation
AI-powered interview preparation
Gamified learning roadmap system
University admission advisor module (paused temporarily)

My long-term goal is to build a career ecosystem inside WhatsApp.

Conclusion

WorqNow started as a simple automation experiment and evolved into a full job–career assistant powered by:

Clean architecture
Modular services
Real-time APIs
Async processing
Smart language understanding
Scalable cloud infrastructure

This project taught me how to design systems that are:

User-friendly
Resilient
Modular
Fast
Easy to extend

And most importantly how to build real products people actually use every day