DEV Community: Jeffery Kachukwucide

Building a Rate-Limited API with Upstash Redis and Python

Jeffery Kachukwucide — Tue, 07 Jul 2026 01:29:51 +0000

An API with no rate limit is an API waiting to be hammered. A careless script stuck in a retry loop, a scraper with no backoff, or a client with a bug in its polling logic can all send hundreds of requests a second — and without a limit in place, your server tries to handle every single one. Rate limiting fixes this: it caps how many requests a client can make in a given window of time, and rejects anything past that cap before it reaches your application logic.

This tutorial adds rate limiting to a small Flask API using Upstash, a managed Redis service with a generous free tier. By the end, every route in the API will enforce a request limit per client, and clients who go over it will get a clear 429 Too Many Requests response instead of silently overwhelming your server.

The mental model you'll walk away with: you don't have to let bad actors or careless clients hammer your API into the ground. A Redis counter and a few lines of Python are enough to enforce a limit.

What you need before starting

Before you start, gather the following:

Basic Python knowledge.
Flask basics (routes, responses).
An Upstash account (free tier).
redis-py installed (pip install redis).
flask installed (pip install flask).

What you'll build

The API manages a simple items resource with standard CRUD routes: GET /items, GET /items/<id>, POST /items, PUT /items/<id>, and DELETE /items/<id>. Items live in memory — this tutorial is about protecting the API, not persisting data, so storage stays as simple as possible.

The interesting part is a single decorator, @rate_limit, that sits on every route. It uses Redis to track how many requests each client has made in the current time window and rejects any request past the configured limit.

Create an Upstash Redis database

Upstash gives you a Redis database with a REST-friendly free tier, and no local Redis installation to manage.

Go to console.upstash.com and sign up or log in.
Click Create Database.
Give it a name, pick a region close to you, and select the Free plan.
Open the new database and go to the Details tab.
Copy the Redis URL. It starts with rediss:// and already bundles your username, password, host, and port into one string.

Save that URL somewhere for the next step — it's the only Upstash-specific detail this project needs.

Connect Python to Upstash Redis

Upstash Redis speaks the standard Redis protocol, so the regular redis-py client connects to it directly. No Upstash-specific SDK is required.

Start by centralizing configuration in one module, so every environment variable the app depends on is visible in one place:

# config.py
import os

REDIS_URL = os.environ.get("UPSTASH_REDIS_URL", "")

RATE_LIMIT_MAX_REQUESTS = int(os.environ.get("RATE_LIMIT_MAX_REQUESTS", 10))
RATE_LIMIT_WINDOW_SECONDS = int(os.environ.get("RATE_LIMIT_WINDOW_SECONDS", 60))

if not REDIS_URL:
    raise RuntimeError(
        "UPSTASH_REDIS_URL is not set. Copy .env.example to .env, fill in "
        "your Upstash connection string, then export the variables before "
        "running the app."
    )

RATE_LIMIT_MAX_REQUESTS and RATE_LIMIT_WINDOW_SECONDS control the limit itself — the defaults above allow 10 requests per 60-second window. Raising the RuntimeError early means a missing connection string fails loudly at startup instead of causing confusing errors later.

With configuration in place, create the Redis client:

# redis_client.py
import redis
from config import REDIS_URL

redis_client = redis.from_url(REDIS_URL, decode_responses=True)

Two details matter here:

redis.from_url accepts the rediss:// URL exactly as Upstash provides it. The extra "s" means the connection is TLS-encrypted, and redis-py handles that automatically.
decode_responses=True tells the client to return plain Python strings instead of bytes. This keeps the rate-limiting code below simpler to read.

Build the rate limiter

This is the core of the tutorial: a fixed-window counter that tracks requests per client using Redis.

The algorithm has four steps:

Build a Redis key unique to both the client and the current time window — for example, ratelimit:203.0.113.5:28819023, where the number is the current Unix timestamp divided by the window length.
Increment that key with INCR. Redis creates missing keys at 0 before incrementing, and INCR is atomic, so concurrent requests from the same client can never race each other into an incorrect count.
On the first request in a new window, set an EXPIRE equal to the window length. Redis deletes the key on its own once the window ends, so the counter resets with no cleanup code required.
Once the count passes the configured limit, reject every further request in that window.

Here's the implementation:

# rate_limiter.py
import time
from functools import wraps

from flask import request, jsonify

from redis_client import redis_client
from config import RATE_LIMIT_MAX_REQUESTS, RATE_LIMIT_WINDOW_SECONDS


def _get_client_id() -> str:
    """Identify the caller by IP address."""
    return request.remote_addr or "unknown"


def is_rate_limited(client_id: str) -> tuple[bool, dict]:
    """Increment and check a client's request count for the current window."""
    current_window = int(time.time()) // RATE_LIMIT_WINDOW_SECONDS
    redis_key = f"ratelimit:{client_id}:{current_window}"

    # This single INCR call is the entire rate-limit counter.
    request_count = redis_client.incr(redis_key)

    if request_count == 1:
        redis_client.expire(redis_key, RATE_LIMIT_WINDOW_SECONDS)

    seconds_into_window = int(time.time()) % RATE_LIMIT_WINDOW_SECONDS
    seconds_remaining = RATE_LIMIT_WINDOW_SECONDS - seconds_into_window

    info = {
        "limit": RATE_LIMIT_MAX_REQUESTS,
        "remaining": max(0, RATE_LIMIT_MAX_REQUESTS - request_count),
        "retry_after": seconds_remaining,
    }
    return request_count > RATE_LIMIT_MAX_REQUESTS, info

Notice what's absent: no locks, no background cleanup job, no scheduled task to purge old counters. INCR and EXPIRE push both the concurrency safety and the cleanup work onto Redis, which is exactly what it's designed for.

_get_client_id identifies callers by IP address, which is enough for a tutorial and for many small APIs. If this app sat behind a reverse proxy or load balancer, you'd read the client's real IP from the X-Forwarded-For header instead — otherwise every request would appear to come from the proxy.

Apply the rate limiter to your routes

A rate limiter that nothing calls doesn't protect anything. The connection point is a decorator that wraps is_rate_limited around each route:

# rate_limiter.py (continued)
def rate_limit(f):
    @wraps(f)
    def wrapper(*args, **kwargs):
        client_id = _get_client_id()
        limited, info = is_rate_limited(client_id)

        if limited:
            response = jsonify({
                "error": "rate_limit_exceeded",
                "message": (
                    f"Too many requests. Limit is {info['limit']} requests "
                    f"per {RATE_LIMIT_WINDOW_SECONDS} seconds."
                ),
                "retry_after_seconds": info["retry_after"],
            })
            response.status_code = 429
            response.headers["Retry-After"] = str(info["retry_after"])
            return response

        return f(*args, **kwargs)
    return wrapper

Applying it to a route is a one-line addition:

# app.py
from flask import Flask, jsonify
import store
from rate_limiter import rate_limit

app = Flask(__name__)


@app.route("/items", methods=["GET"])
@rate_limit
def list_items_route():
    return jsonify(store.list_items())

The same @rate_limit decorator sits above every other route in app.py — the POST, PUT, DELETE, and single-item GET all get it too. Because the decorator runs before the view function's own code, a rejected request never touches store.py at all; it's turned away at the door. This is also why the CRUD logic in store.py (an in-memory dict guarded by a thread lock) doesn't need to know anything about rate limiting, HTTP, or Redis — it just manages items, and the decorator handles abuse protection as a separate concern layered on top.

Return a proper error response when the limit is exceeded

A rate limiter is only useful if callers can tell why their request failed and when to try again. The rate_limit decorator above returns two things that matter for that:

A 429 status code is the standard HTTP status for "you've sent too many requests."
A Retry-After header tells well-behaved clients exactly how many seconds to wait.

The JSON body follows the same idea, giving both a machine-readable error code and a human-readable message:

{
  "error": "rate_limit_exceeded",
  "message": "Too many requests. Limit is 10 requests per 60 seconds.",
  "retry_after_seconds": 37
}

A client library can check response.status_code == 429, read Retry-After, and back off automatically — no guessing required.

Test the rate limiter locally

Copy .env.example to .env, paste in your Upstash Redis URL, and export the variables into your shell:

export $(cat .env | xargs)

Install dependencies and start the app:

pip install -r requirements.txt
python app.py

With the default limit of 10 requests per 60 seconds, send 11 requests in a row and watch the last one fail:

for i in $(seq 1 11); do
  curl -s -o /dev/null -w "%{http_code}\n" http://localhost:5000/items
done

The first 10 lines print 200. The 11th prints 429 — the rate limiter did its job.

Know the fixed-window trade-off

Everything above adds up to a small amount of code: one Redis client, one counter function, and one decorator. In exchange, the decorator protects every route in the API from being overwhelmed by a single client, with no extra infrastructure beyond Redis itself.

This fixed-window approach is deliberately simple, and simple has a real trade-off worth knowing: a client can send its full limit right at the end of one window and its full limit again right at the start of the next, effectively doubling the rate for a brief moment at window boundaries. For most APIs, that's a fine trade for the simplicity of INCR plus EXPIRE. If you outgrow this fixed-window approach, the same Redis connection can support a sliding-window or token-bucket algorithm instead — but the core idea doesn't change: a Redis counter and a few lines of Python are enough to keep bad actors and careless clients from taking your API down.

The Repository link : https://github.com/anthonyonyenaobijeffery-debug/Protecting-Your-Python-API-from-Abuse-with-Upstash-Redis

Building a Transactional Email CLI with Mailgun and Python

Jeffery Kachukwucide — Sun, 05 Jul 2026 23:13:36 +0000

If your app needs to send a welcome email, a password reset link, or an order confirmation, you don't need to stand up a mail server. You need one HTTP call.

This tutorial builds a small Python CLI that sends transactional email through Mailgun's API, then checks whether Mailgun actually delivered it. By the end, you'll have replaced "sending email" with a simpler model: call an API, read the response, done.

What you need before starting

Before you start, gather the following:

Basic Python knowledge.
Python installed.
A Mailgun account (the free tier works).
The requests library (pip install requests).

What you'll build

The app is a small CRUD tool with four actions:

Send an email.
List what's been sent.
Check delivery status.
Delete a record.

Two files do the real work:

mailgun_client.py — the only file that talks to Mailgun; it sends emails and checks their status.
storage.py — logs each sent email to a local JSON file, so there's something to check later.

main.py wires these two together into a menu, and config.py loads your Mailgun credentials. Neither file does anything Mailgun-specific. This tutorial moves through them quickly and spends most of its time on mailgun_client.py, where the real subject lives.

Set up your Mailgun account

Sign up for a free Mailgun account. Every account starts with a sandbox domain — a Mailgun-provided domain you can send test emails from immediately, without verifying your own domain's DNS records.

Grab two things from the dashboard, both under Sending → Domain settings:

Your domain (the sandbox domain, e.g. sandboxXXXX.mailgun.org, or your own verified domain)
Your API key

One sandbox-specific rule catches people the first time: sandbox domains only deliver to authorized recipients. Before you can send yourself a test email, add your own address under Authorized Recipients in the dashboard. Skip this step, and Mailgun accepts the request but never delivers it — exactly the silent failure the status-check step later in this tutorial is built to catch.

Configure your credentials

Store your API key, domain, and sender address as environment variables — never in code. config.py loads them with a small dotenv reader (no extra dependencies), then fails fast if anything's missing:

MAILGUN_API_KEY = os.environ.get("MAILGUN_API_KEY")
MAILGUN_DOMAIN = os.environ.get("MAILGUN_DOMAIN")
MAILGUN_SENDER = os.environ.get("MAILGUN_SENDER")
MAILGUN_BASE_URL = os.environ.get("MAILGUN_BASE_URL", "https://api.mailgun.net/v3")

MAILGUN_BASE_URL defaults to Mailgun's US host. If your account is on Mailgun's EU region, set this to https://api.eu.mailgun.net/v3 instead — worth knowing before a mismatched region costs you a confusing 401.

With MAILGUN_API_KEY, MAILGUN_DOMAIN, and MAILGUN_SENDER set in a .env file, the app is ready to talk to Mailgun.

Send the email

This function delivers on the tutorial's promise. Everything before it was setup; everything after it is bookkeeping.

def send_email(to, subject, body, sender):
    response = requests.post(
        f"{MAILGUN_BASE_URL}/{MAILGUN_DOMAIN}/messages",
        auth=("api", MAILGUN_API_KEY),
        data={
            "from": sender,
            "to": to,
            "subject": subject,
            "text": body,
        },
    )
    response.raise_for_status()
    return response.json()

A transactional email, structurally, is four fields: from, to, subject, text. Mailgun's Messages API takes exactly those four as form fields on a POST to /{domain}/messages. There's no envelope object, no MIME construction, no SMTP handshake — you build a dictionary and make one request.

Two details here are easy to get wrong the first time:

Auth is HTTP Basic Auth, not a bearer token. The username is the literal string "api"; your API key is the password. requests handles the encoding through the auth= tuple — but if you're used to APIs that expect Authorization: Bearer <token>, this is a different shape.
The payload is form-encoded, not JSON. data={...} sends application/x-www-form-urlencoded, which is what Mailgun's Messages API expects — even though the response comes back as JSON. Passing json= here instead of data= is a common first mistake, and the resulting error doesn't make the cause obvious.

response.raise_for_status() turns a 4xx or 5xx response into a Python exception immediately, instead of letting a failed send look successful. response.json() hands back Mailgun's confirmation, including a message ID — the thread that connects sending an email to checking on its delivery later.

Confirm the email actually delivered

Here's the detail that matters most: Mailgun accepting your request is not the same as Mailgun delivering your email. A 200 response means "I've queued this to send," not "your recipient has it." Confirming delivery means asking Mailgun a second, separate question.

Mailgun doesn't expose a "get status by message ID" endpoint. Instead, you query its Events API — a log of everything that's happened to your domain's messages — and filter by ID:

def get_delivery_status(message_id):
    clean_id = message_id.strip("<>")

    response = requests.get(
        f"{MAILGUN_BASE_URL}/{MAILGUN_DOMAIN}/events",
        auth=("api", MAILGUN_API_KEY),
        params={"message-id": clean_id},
    )
    response.raise_for_status()
    events = response.json().get("items", [])

    if not events:
        return "unknown"

    return events[0].get("event", "unknown")

Two quirks are worth knowing before you hit them:

The message ID send_email() returns is wrapped in angle brackets (<abc123@sandbox...mailgun.org>), but the Events filter expects the bare ID. strip("<>") handles the mismatch.
The event log can lag a few seconds behind the send. Check status immediately after sending, and you may get "unknown" back — not because anything failed, but because Mailgun hasn't logged the event yet. Waiting a moment and checking again usually resolves it.

events[0] is the most recent event for that message — typically delivered, accepted, or failed. That single string is confirmation that the email didn't just leave your app; it actually arrived.

Wire the send and status functions into the app

main.py calls these two functions and logs the result. The send step looks like this:

result = mailgun_client.send_email(
    to=to, subject=subject, body=body, sender=config.MAILGUN_SENDER,
)
record = storage.create_record({
    "to": to,
    "mailgun_message_id": result["id"],
    "status": "queued",
    # ...
})

storage.py writes that record to a local JSON file — not because Mailgun requires it, but because Mailgun doesn't keep "your" list of sent emails, only a raw event log. The local record is what lets you look up a message ID later and ask get_delivery_status() about it.

Run the app

$ python main.py
--- Mailgun Transactional Email Manager ---
1. Send a new email (Create)
2. List logged emails (Read)
3. Refresh delivery status (Update)
4. Delete a logged email (Delete)
5. Quit
Choose an option: 1
Recipient email: you@example.com
Subject: Test send
Body text: Hello from the Mailgun API.

Sent. Local record #1 created. Mailgun says: Queued. Thank you.

Choose option 3 and enter 1, and the app queries the Events API and updates the record — queued becomes delivered (or accepted, depending on timing). If it still shows unknown, wait a few seconds and check again; that's the event-log lag, not a bug.

Treat sending email as an API call

Nowhere in this project is there SMTP configuration, a mail server, or a queuing system to install. There's one POST to send an email and one GET to confirm it arrived — both plain HTTP calls made with requests.

That's the mental model worth keeping: sending email from an app isn't a mail-server problem. It's an API call.

The repository for the code link : https://github.com/anthonyonyenaobijeffery-debug/Sending-Transactional-Emails-in-Python-with-Mailgun

Building an Event-Driven User Signup Flow with Redpanda and Python

Jeffery Kachukwucide — Sat, 04 Jul 2026 22:03:02 +0000

This tutorial builds an event-driven signup flow with Python and Redpanda: creating, updating, and deleting a user become events on a Redpanda Cloud topic instead of direct database writes. You'll write a producer that turns CLI commands into events, a consumer that folds those events into a SQLite table, and a query script that reads that table directly — never touching Redpanda at all. That last piece is where the event-driven mental model actually clicks into place.

In a typical signup flow, one function does everything:

Validates the input.
Writes a row to the database.
Maybe queues a welcome email.
Maybe updates an analytics table.

Every time the app needs a new reaction to a signup, someone edits that same function. The database write and the side effects it triggers stay welded together.

Event-driven design breaks that weld. Instead of reacting to a signup inline, the signup handler publishes one fact: "this happened." Anything downstream — a database writer, an email service, an analytics job — subscribes to that fact on its own schedule, in its own process, without knowing the handler exists.

What you need before starting

This tutorial assumes Python — reading a CLI script and a SQLite call should feel familiar — but not event streaming. If you've never used a message broker before, that's the gap this tutorial fills:

What an event is.
Why a broker sits between the code that causes an event and the code that reacts to it.
How that separation looks in real Python.

A quick note on terms: Redpanda's client library calls the object traveling through a topic a message. This tutorial calls that same object an event once its payload holds a UserEvent. The two words describe the same thing — message is the broker's vocabulary, event is this tutorial's.

Create a Redpanda Cloud cluster

Redpanda Cloud's Serverless tier removes the infrastructure step entirely — no Docker, no cluster sizing, no networking to configure.

Sign up for Redpanda Cloud and create a Serverless cluster. It's provisioned in a few minutes and ready to use immediately.
On the Topics page, create a topic named user-lifecycle — this is where every signup, update, and delete event will land.
On the Security page, create a SASL user with the SCRAM-SHA-256 mechanism, and save its password somewhere safe.
On the cluster's Overview page, copy the bootstrap server address. Every producer and consumer you write will connect through this one address.

You now have four values: the bootstrap server, a username, a password, and a mechanism name. Everything else in this tutorial builds on those four.

Configure the project

Install the single third-party dependency:

pip install -r requirements.txt

requirements.txt lists exactly one package: kafka-python. It speaks Kafka's wire protocol, which Redpanda implements, so the same client library that talks to Kafka talks to Redpanda without modification.

Copy .env.example to .env and fill in the four values from your cluster:

REDPANDA_BOOTSTRAP_SERVERS=<bootstrap-server-address>
REDPANDA_SASL_USERNAME=<your-username>
REDPANDA_SASL_PASSWORD=<your-password>
REDPANDA_SASL_MECHANISM=SCRAM-SHA-256

config.py is the only file that reads these variables. It loads them once and hands every other module a ready-made connection dict:

def kafka_common_config() -> dict:
    """Connection kwargs shared by both KafkaProducer and KafkaConsumer."""
    return {
        "bootstrap_servers": BOOTSTRAP_SERVERS,
        "security_protocol": SECURITY_PROTOCOL,
        "sasl_mechanism": SASL_MECHANISM,
        "sasl_plain_username": SASL_USERNAME,
        "sasl_plain_password": SASL_PASSWORD,
    }

Producer and consumer both call this function, so the connection settings live in exactly one place.

Define the event contract

Before writing a producer or a consumer, define the shape of the event they'll exchange. models.py holds the UserEvent dataclass, and it imports neither kafka nor sqlite3 — the event schema is a plain contract, independent of how it's transported or stored.

@dataclass
class UserEvent:
    event_type: str
    user_id: str
    payload: dict
    event_id: str = field(default_factory=lambda: str(uuid.uuid4()))
    timestamp: str = field(default_factory=_now)

    def to_json(self) -> bytes:
        return json.dumps(asdict(self)).encode("utf-8")

    @staticmethod
    def from_json(raw: bytes) -> "UserEvent":
        data = json.loads(raw.decode("utf-8"))
        return UserEvent(**data)

event_type is one of SIGNUP, UPDATE, or DELETE. payload carries whatever data that event type needs:

An email and name for a signup.
A status change for an update.
Nothing at all for a delete.

Keeping the envelope generic like this means adding a new event type later costs a new constant and a new branch in the consumer's dispatch — not a new topic or a schema migration.

Write the producer: turn a CLI command into an event

producer.py is the only place a "signup" becomes an event. It builds a KafkaProducer, then serializes and sends a UserEvent:

def build_producer() -> KafkaProducer:
    return KafkaProducer(
        **config.kafka_common_config(),
        key_serializer=lambda k: k.encode("utf-8"),
        value_serializer=lambda v: v,
        acks="all",
    )


def publish(producer: KafkaProducer, event: UserEvent) -> None:
    future = producer.send(config.TOPIC_NAME, key=event.user_id, value=event.to_json())
    record_metadata = future.get(timeout=10)
    print(f"published {event.event_type} for {event.user_id} "
          f"-> partition {record_metadata.partition}, offset {record_metadata.offset}")

Two choices in this code matter more than the rest of the file:

Keying by user_id. Redpanda only guarantees message order within a single partition, and messages sharing a key always land on the same partition. Keying by user_id — not by event_id — keeps one user's SIGNUP → UPDATE → DELETE sequence from arriving out of order.
acks="all". The producer waits for Redpanda's full in-sync replica set to confirm the write, not just the partition leader, before it considers the event published.

The rest of producer.py is CLI plumbing: argparse subcommands for signup, update, and delete that build a UserEvent from command-line flags and hand it to publish(). None of it touches SQLite, and none of it knows a consumer exists. That's the point — the producer's only responsibility is turning a command into an event and putting it on the topic.

Write the consumer: fold events into a read-model

consumer.py is the other half of the contract. It doesn't expose any CRUD API of its own — it subscribes to the topic and replays whatever the producer published, in order, into a SQLite table:

def apply_event(repo: UserRepository, event: UserEvent) -> None:
    if event.event_type == EventType.SIGNUP:
        user = User(user_id=event.user_id, email=event.payload["email"], name=event.payload["name"])
        repo.create(user)
    elif event.event_type == EventType.UPDATE:
        repo.update(event.user_id, event.payload, event.timestamp)
    elif event.event_type == EventType.DELETE:
        repo.delete(event.user_id)

The main loop wires a KafkaConsumer to this dispatch function:

consumer = KafkaConsumer(
    config.TOPIC_NAME,
    **config.kafka_common_config(),
    group_id=config.CONSUMER_GROUP_ID,
    auto_offset_reset="earliest",
    enable_auto_commit=False,
    key_deserializer=lambda k: k.decode("utf-8") if k else None,
    value_deserializer=lambda v: v,
)

for message in consumer:
    event = UserEvent.from_json(message.value)
    apply_event(repo, event)
    consumer.commit()

enable_auto_commit=False is the detail worth pausing on. The consumer commits its offset by hand, only after apply_event() finishes — after the row lands in SQLite. If the process crashes between reading a message and finishing the write, Redpanda still considers that message unread, and the consumer replays it on restart. This guarantee is called at-least-once delivery: it never loses an event, but it can redeliver one.

Redelivery only stays safe because repository.py writes with INSERT OR REPLACE:

def create(self, user: User) -> None:
    self.conn.execute(
        """
        INSERT OR REPLACE INTO users
            (user_id, email, name, status, created_at, updated_at)
        VALUES (?, ?, ?, ?, ?, ?)
        """,
        (user.user_id, user.email, user.name, user.status, user.created_at, user.updated_at),
    )
    self.conn.commit()

Replaying the same SIGNUP event twice overwrites a row with identical values instead of failing on a duplicate primary key. At-least-once delivery and idempotent writes are a pair: one guarantees you won't miss an event, the other guarantees seeing it twice doesn't corrupt anything.

Write the query script: read state without touching Redpanda

Everything so far has been the write path. query.py is the read path, and it's short enough to show in full:

if args.command == "list":
    users = repo.list_all()
    for user in users:
        print(f"{user.user_id}  {user.email:<30} {user.name:<20} {user.status}")
else:  # get
    user = repo.get(args.user_id)
    print(user if user else f"no user found with id {args.user_id}")

No kafka import. No producer, no consumer, no topic. query.py reads straight from the users table that consumer.py already built. This is the mental-model shift the whole tutorial has been building toward: writes travel through events so that any number of independent consumers could react to them, but reads don't need Redpanda at all. Reads just hit the materialized view the consumer already produced.

That separation is also why producer.py never imports repository.py, and why repository.py never imports kafka. The write path and the read path are two independent code paths that agree on exactly one thing — the UserEvent schema in models.py — and nothing else. A second consumer, like an email sender or an audit log, could subscribe to the same topic tomorrow without producer.py or query.py changing by a single line.

Run the flow end-to-end

Start the consumer first, in its own terminal, so it's listening before any events arrive:

python consumer.py

In a second terminal, publish a signup:

python producer.py signup --email ada@example.com --name "Ada Lovelace"

The producer's terminal prints the partition and offset the event landed on. The consumer's terminal prints confirmation that the user now exists in the SQLite table. Update and delete work the same way:

python producer.py update --user-id <user_id> --status inactive
python producer.py delete --user-id <user_id>

Then check the current state, reading straight from SQLite and not through Redpanda:

python query.py list
python query.py get --user-id <user_id>

What you built

The CRUD operations here are deliberately simple — a signup flow was never the hard part. What's worth taking away is the shape underneath this signup flow: a producer that only knows how to turn a command into an event, a consumer that only knows how to fold events into state, and a read path that skips Redpanda entirely, because reads don't depend on it. That shape scales past this tutorial's four commands — any process that needs to react to a user signing up subscribes to the same topic, on its own schedule, without ever touching producer.py.

Building a Conflict-Safe Notes App with Supabase and Vanilla JavaScript

Jeffery Kachukwucide — Wed, 01 Jul 2026 22:02:22 +0000

This article shows how one SQL trigger and one extra WHERE clause let a vanilla JavaScript client detect and resolve edit conflicts — with no locking system, no hand-maintained version column, and no custom server.

The example assumes you already know SQL and JavaScript. With that background, Supabase can feel deceptively easy to pick up: it's Postgres with a JavaScript client bolted on. That's mostly true, except for one spot where the two layers stop being separate and have to hand off responsibility to each other — what happens when two people edit the same row at the same time.

What you'll build

A single-page notes app: a form to add notes, a list of note cards, and inline edit, save, and delete actions. Multiple browser tabs — or multiple people — can have the app open at once, and a Supabase realtime channel keeps them in sync.

This article covers one slice of that app: what happens when two clients edit the same note at the same time. The realtime sync and the basic CRUD operations are standard Supabase patterns, so the article moves through them quickly to spend most of its time on the conflict-detection logic described above.

Set up your Supabase project

Your schema.sql file does more than create a table. Supabase requires two settings that a plain, self-managed Postgres setup doesn't need, plus one more piece — a trigger — that the rest of this article depends on.

Enable Row Level Security

In a typical backend, your server connects to Postgres with credentials that already have table permissions, and that's the end of it. Supabase flips this: the client ships an anon key straight into the browser, so anyone holding that key can call the API. Row Level Security (RLS) is the gate that decides what the anon key can actually do.

alter table notes enable row level security;

create policy "public full access (demo only)"
on notes
for all
using (true)
with check (true);

With RLS enabled and no policy, Supabase denies all access by default — the opposite of a typical open Postgres setup. The policy above allows everything, which works for learning but is wrong for anything real.

Enable realtime updates

Creating a table doesn't automatically stream its changes. You also need to add the table to Supabase's realtime publication:

alter publication supabase_realtime add table notes
  where not exists (
    select 1 from pg_publication_tables
    where pubname = 'supabase_realtime' and tablename = 'notes'
  );

Skip this step, and postgres_changes subscriptions on notes will connect successfully but never fire. This silent failure is worth knowing about before you go looking for bugs elsewhere.

Add the updated_at trigger

The rest of this article depends on one more piece: a trigger that stamps every update with a server-generated timestamp.

create or replace function set_updated_at()
returns trigger as $$
begin
  new.updated_at = now();
  return new;
end;
$$ language plpgsql;

create trigger trg_notes_updated_at
before update on notes
for each row
execute function set_updated_at();

On every UPDATE to this table, the database overwrites updated_at unconditionally, before it writes the row. The client can send whatever it wants in that field — the trigger ignores it. Hold onto that fact: it's what makes the conflict detection in this article trustworthy.

Connect the JavaScript client

On the JavaScript side, setup is one line:

const db = supabase.createClient(SUPABASE_URL, SUPABASE_ANON_KEY);

This client is your only connection to Postgres from here on. Every query in the rest of this article is a method chain on db.

Add the standard CRUD operations

fetchNotes, createNote, and deleteNote map onto SQL about as literally as you'd expect. Here's fetchNotes:

async function fetchNotes() {
  const { data, error } = await db
    .from('notes')
    .select('*')
    .order('created_at', { ascending: true });
  if (error) throw error;
  return data;
}

createNote and deleteNote follow the same pattern:

.from('notes').select('*') is SELECT * FROM notes.
.insert({...}).select().single() is an INSERT ... RETURNING, unwrapped from an array to a single object because exactly one row comes back.
.delete().eq('id', id).select() is a DELETE ... RETURNING; the client uses the returned row to confirm a row actually existed to delete.

None of this logic is Supabase-specific — it's SQL wearing a JavaScript accent. The next section covers the one operation that needs more than a literal translation: UPDATE.

Detect conflicts with a compare-and-swap WHERE clause

Here's the bug this app is designed around. Two tabs open the same note. Both load it with the same updated_at. Tab B saves first. If Tab A's save just runs UPDATE notes SET title = ..., content = ... WHERE id = X, it silently clobbers Tab B's change — no error, no warning, just wrong data. This is the classic "last write wins" trap, and it's invisible until two people actually collide.

The fix isn't more JavaScript. It's one extra clause in the SQL:

async function updateNote(id, title, content, knownUpdatedAt) {
  const { data, error } = await db
    .from('notes')
    .update({ title, content })
    .eq('id', id)
    .eq('updated_at', knownUpdatedAt)
    .select();
  if (error) throw error;
  return data.length === 0 ? null : data[0]; // null = conflict
}

That second .eq() turns this into UPDATE notes SET ... WHERE id = X AND updated_at = Y. Postgres evaluates the whole WHERE clause atomically — there's no gap in time between "check if this row still matches" and "write to it" for another transaction to sneak into. Either the row's updated_at still equals what this client last saw, and the write happens, or it doesn't, and Postgres touches zero rows. This is a compare-and-swap, done entirely inside a single statement, with no application-level locking at all.

The JS side just has to notice which of those two outcomes happened, and .select() after an .update() gives it a clean signal for free: if the WHERE matched nothing, Supabase returns an empty array — not an error. data.length === 0 is the conflict.

This is the seam the whole app is built around: SQL owns the atomicity, JS owns interpreting the result.

The other half of the compare-and-swap lives in the trigger you added during setup. The database — not the browser — sets updated_at on every write. That gives the value three guarantees the client can rely on:

It can't be stale from clock skew.
It can't be forged by a malicious client.
It can't be forgotten or left unset.

In effect, you get a free, tamper-proof version number, without adding a version column or writing any bookkeeping logic yourself:

function startEdit(id) {
  const note = notesCache.find(n => n.id === id);
  editingNoteId = id;
  editingBaselineUpdatedAt = note.updated_at; // the "version" this edit started from
  editingDraft = { title: note.title, content: note.content };
  render();
}

startEdit() captures editingBaselineUpdatedAt once, when editing begins. On save, updateNote() sends that exact value back into its WHERE clause.

Use realtime updates to warn, not resolve, conflicts

You might be tempted to let the realtime subscription resolve conflicts directly: see an incoming change, merge it into the draft, done. This app deliberately doesn't — and the reason matters:

if (eventType === 'UPDATE') {
  const idx = notesCache.findIndex(n => n.id === newRow.id);
  if (idx !== -1) notesCache[idx] = newRow;

  if (editingNoteId === newRow.id && newRow.updated_at !== editingBaselineUpdatedAt) {
    showToast(`"${newRow.title || 'Untitled'}" was changed in another tab while you're editing it.`);
  }
}

This handler never touches editingDraft. It only updates the background cache and, if the edited row just changed underneath the editor, shows a toast. The actual conflict resolution happens later, when Save runs and hits the WHERE clause in updateNote().

That separation is deliberate. Websocket messages can arrive late or not at all, and a dropped connection must never cause a bad write — at worst, it should only delay or drop the warning. The app's correctness can't depend on the realtime message arriving; it depends only on the SQL compare-and-swap, which runs synchronously inside the save itself. Realtime's job is entirely about user experience: it gives someone a heads-up before they hit Save, instead of a surprise after. Delete the realtime subscription entirely, and the conflict detection stays airtight — you just lose the early warning.

Trace a two-tab conflict

Open two tabs on the same note, side by side. Here's the sequence that follows:

Tab A clicks Edit. The app captures editingBaselineUpdatedAt as T1.
Tab B clicks Edit on the same note. Its baseline is also T1.
Tab B saves first. The clause WHERE id = X AND updated_at = T1 matches, the trigger bumps the row to T2, and Tab B's edit lands.
Realtime pushes that update to Tab A. handleRealtimeChange sees that editingNoteId matches and T2 !== T1, so it shows the toast but leaves Tab A's draft untouched.
Tab A clicks Save anyway, missing or ignoring the warning. The query runs WHERE id = X AND updated_at = T1, but the row's updated_at is now T2. Zero rows match, and updateNote() returns null.
saveEdit() treats the null as a conflict. It refetches the current notes from the server, shows a toast explaining that the save failed, and returns Tab A to read mode.

if (result === null) {
  notesCache = await fetchNotes();
  showToast('Save failed: this note changed elsewhere. Showing the latest version — please re-apply your edit.');
  cancelEdit();
  return;
}

Nobody's edit vanished silently. Tab B's write is safely on the server. The app rejected Tab A's conflicting write cleanly, explained exactly why, and gave Tab A a path to redo the edit on the current data.

Apply this pattern beyond notes apps

This pattern extends beyond notes apps. Whenever two clients might write the same row, don't do a "check, then write" in your application code — there's always a race window between those two steps. Push the check into the write, as part of the same WHERE clause, and let Postgres's transactional guarantees make it atomic for free. A database-owned timestamp — or a dedicated version column, if you want one — gives you a value to compare against without trusting the client to report it honestly.

Keep realtime in its lane: it's a way to tell users something changed, not a mechanism for deciding what to do about that change. The moment a postgres_changes handler starts mutating in-progress state, you've reintroduced the exact race condition the SQL layer eliminates.

That's the real overlap between Supabase's JavaScript and SQL layers: not how to call .update(), but where the responsibility for correctness lives — and making sure your client code never quietly takes it back.

Live Demo : https://anthonyonyenaobijeffery-debug.github.io/Notes-app-with-Supabase-vanilla-JS-real-client-overlap-your-/

Wow. When i heard about mythos, i thought it was another upgrade , probably. but later on when i heard about the US government involvement in it , it was clear that this wasn't just an upgrade, it was a big leap.

Jeffery Kachukwucide — Mon, 22 Jun 2026 19:42:50 +0000

Giorgi Kobaidze

Jun 21

AI Psychosis Is No Longer Fiction

#discuss #ai #claude #security

14 min read

Think Before You Prompt

Jeffery Kachukwucide — Sun, 07 Jun 2026 21:07:03 +0000

AI Is Giving Children Answers, But Are They Learning to Think?

The Importance of Critical Thinking in the Age of Artificial Intelligence

*How I Turned 11 Weeks of AI Research Into an Interactive “Think Before You Prompt” Experience 🚀 Project Link
*
👉 https://anthonyonyenaobijeffery-debug.github.io/Think-before-you-prompt/

🧠 Introduction

Over the past few weeks, I explored a topic that kept bothering me:

As Artificial Intelligence becomes more available to children, are they still learning how to think?

AI tools today can solve homework, explain concepts, write essays, and answer questions instantly. While this is powerful, I started wondering if over-reliance on these tools could affect the development of critical thinking skills in young learners.

Instead of writing a normal article, I decided to turn my research into something more engaging.

I wanted to create something that feels like more than just a blog post.

So I built:

“Think Before You Prompt” — an interactive, hacker-style reading experience where the article writes itself on the screen.

The goal was simple: Make readers experience the message instead of just reading it.

🛠️ How I Built It

This project was built using:

HTML CSS JavaScript GitHub Pages for deployment

The core idea was to simulate a “terminal-style research system” that reveals information gradually using a typewriter effect.

*Key features include:
*
Boot sequence animation Typewriter text rendering Progress bar for reading flow Terminal-style UI Live critical thinking prompts 🧩 What I Learned

This project taught me that:

Presentation can change how people perceive an idea Simple JavaScript can create powerful storytelling effects Educational content becomes more engaging when it feels interactive Finishing projects is more important than starting them 🧠 The Message Behind the Project

AI is not the problem.

The real challenge is ensuring that people — especially children — continue to develop:

Critical thinking Problem-solving skills Independent reasoning

AI should support thinking, not replace it.

📌 Final Thoughts

This project started as research and ended as an experience.

Instead of writing about AI and critical thinking, I built a way to feel the message through interaction.

Sometimes the best way to explain an idea… is to make people experience it.

🔗 Live Project

https://anthonyonyenaobijeffery-debug.github.io/Think-before-you-prompt/

Sentient Canvas: A Localized Agentic Workspace Powered by Google's Gemma 4

Jeffery Kachukwucide — Sun, 24 May 2026 22:37:18 +0000

Sentient Canvas: A Localized Agentic Workspace Powered by Google's Gemma 4

Welcome to the future of localized AI interactions. Sentient Canvas is a high-performance, real-time agentic workspace built entirely on top of Google’s revolutionary Gemma 4 open-weights architecture.

Traditional agent workflows are often bogged down by massive latency, fragmented multi-modal interfaces, and severe echo loops during voice interactions. Sentient Canvas solves this by organizing Gemma 4's native cognitive alignment capabilities into four discrete, hardware-accelerated "Architectural Gates," backed by an advanced, feedback-immune client-side audio pipeline.

🔗 Project Links

Live Demo & Source Code: Sentient Canvas on Hugging Face Spaces

⚙️ How it Works: The 4 Architectural Gates
Sentient Canvas exposes Gemma 4’s native capabilities directly via a streamlined UI, dividing complex latency-sensitive tasks into explicit operational lanes:

Speed Mode (Gate A): Utilizes a high-throughput processing pipeline for immediate, low-latency text responses.
Tool Connect (Gate B): Implements Gemma 4's advanced function calling layer to programmatically manipulate the canvas and alter workspace layouts dynamically.
Vision Scan (Gate C): Passes structural physical assets directly into Gemma 4’s unified multi-modal vision layers.
Deep Think (Gate D): Exposes native, token-by-token explicit reasoning streams so users can watch the system build multi-step logical constraints in real time.

🛠️ The Tech Stack & Overcoming Engineering Hurdles

Inference Model: Google Gemma 4 (Open-Weights Cognitive Alignment)
Deployment Hub: Hugging Face Spaces
Voice Protocol: Web Speech API (SpeechRecognition & SpeechSynthesis Core)
Frontend Real-time Sync: Vanilla JavaScript & Tailwind CSS

Resolving the "Acoustic Feedback & Markdown" Problem
During voice-to-voice testing, we ran into two critical bugs common in streaming agent interfaces:

The Asterisk Loop: The Web Speech Synthesis engine would literally read Markdown formatting elements aloud (saying "asterisk asterisk" instead of speaking normally).
The Inner Monologue Leak: Gemma 4's native <|think|> blocks would accidentally blend into the spoken response queue, causing the AI to vocalize its internal reasoning loops.

The Solution: We engineered a custom client-side pipeline filter (sanitizeTextForSpeech) that intercept-checks data streams in real time. It instantly strips out markdown tokens, filters raw code strings, and blocks internal thought markers, keeping the visual text beautifully styled on the screen while routing a polished, completely clean vocal stream directly to the user.

What's Next?
Sentient Canvas proves that highly responsive, multi-modal agent loops don't need closed-source architectures or massive server infrastructure—they can run efficiently on accessible open frameworks. We plan to expand the interface to support broader tool-calling execution blocks and persistent cross-session thread storage.

Built for the Google Gemma 4 challenge. Let's build the future!