Forem: Adeniyi Olanrewaju

Building a Secure Django REST API from Scratch - DjangGuard

Adeniyi Olanrewaju — Fri, 06 Mar 2026 15:43:52 +0000

Most Django tutorials teach you how to build an API. Very few teach you how to build a secure one.

In this article, I'll walk you through DjangGuard - a Django REST API boilerplate I built that comes with security built in from the start. Not as an afterthought.

By the end, you'll understand how to implement:

JWT authentication with device binding
Redis-backed token blacklisting
Brute-force login protection
Global and endpoint-level rate limiting
Argon2 password hashing
User agent validation middleware

Let's get into it.

Why Security Needs to Come First

When you build an API, it's easy to focus on features. But the moment your API goes live, it becomes a target.

People will try to:

Guess passwords over and over
Steal tokens and use them from different devices
Flood your endpoints with requests
Reuse tokens after a user has logged out

DjangGuard addresses all of these - and it's designed to be a starting point you can build any project on top of.

The Tech Stack

Before we dive in, here's what we're working with:

What	Technology
Framework	Django 5.2 + Django REST Framework
Auth	SimpleJWT + PyJWT
Brute-force protection	django-axes
Rate limiting	django-ratelimit
Caching & token storage	Redis
Password hashing	Argon2
Config management	python-dotenv

Project Structure

backend/
├── api_services/         # Shared utilities (response helper, Redis, logger, etc.)
├── authentication/       # Login, register, logout
├── exception_handler/    # Custom DRF error responses
├── guard/                # Django settings and root URLs
├── middleWares/
│   ├── authenticate/     # User agent validation
│   └── rateLimit/        # Global rate limiting
├── users/                # User profile
└── requirements.txt

Clean and modular. Each responsibility lives in its own place.

1. Custom User Model

The first thing we do is replace Django's default user model. We don't need a username - we use email instead.

class User(AbstractUser, BaseModel):
    username = None
    email = models.EmailField(unique=True)
    first_name = models.CharField(max_length=100)
    last_name = models.CharField(max_length=100)
    password = models.TextField()
    is_deleted = models.BooleanField(default=False)

    USERNAME_FIELD = "email"
    REQUIRED_FIELDS = []

    objects = CustomUserManager()

We also have a BaseModel that gives every model a hex UUID primary key and created_at / updated_at timestamps:

class BaseModel(models.Model):
    id = models.CharField(primary_key=True, max_length=32, default=hex_uuid, editable=False)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        abstract = True

Using hex UUIDs instead of auto-incrementing integers means your IDs don't leak information about how many users you have.

2. JWT with User Agent Binding

Standard JWT authentication has a problem: if someone steals a token, they can use it from anywhere.

DjangGuard solves this by embedding the user's User-Agent header as a custom claim inside the token at login time.

def get_tokens_for_user(user, extra_claims=None):
    token = AccessToken.for_user(user)
    if extra_claims:
        for key, value in extra_claims.items():
            token[key] = value
    ...

When the user logs in, we capture their User-Agent and bake it into the token:

user_agent = serializer.validated_data.get("user_agent")
token_dict = get_tokens_for_user(user, {"user_agent": user_agent})

Now every token is tied to the device that created it.

3. User Agent Validation Middleware

On every request, our middleware checks if the token's user_agent claim matches the current request's User-Agent.

class UserAgentValidationMiddleware:
    def __call__(self, request):
        auth_header = request.META.get("HTTP_AUTHORIZATION")

        if auth_header:
            token = self.extract_token(auth_header)
            validation_result = self.validate_user_agent(token, request)
            if validation_result is not True:
                return validation_result

        return self.get_response(request)

If there's a mismatch, the token is immediately blacklisted and the request is rejected:

if token_user_agent != current_user_agent:
    redis_service.set(unverified_jti, "blacklisted", expire=timedelta(days=1))
    return JsonResponse(
        {"detail": "User agent mismatch", "message": "Token was issued for a different device/browser"},
        status=401,
    )

This means even if a token gets stolen, it's useless on any device other than the original one.

4. Redis Token Blacklisting

When a user logs out, we blacklist their token's jti (JWT ID) in Redis:

class LogoutView(APIView):
    def post(self, request):
        ...
        payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
        jti = payload.get("jti")
        redis_service.set(jti, "blacklisted", expire=timedelta(days=1))
        return returned_response("success", "Logout successful", status.HTTP_200_OK)

Before any authenticated request is processed, the middleware checks Redis for that jti:

has_been_blacklisted = redis_service.get(unverified_jti)
if has_been_blacklisted and has_been_blacklisted.decode("utf-8") == "blacklisted":
    return JsonResponse({"message": "Token has been blacklisted"}, status=401)

The token expires from Redis automatically after 1 day - matching the token's own lifetime. No cleanup needed.

5. Single Active Session

When a user logs in, we store a mapping of user_id → jti in Redis:

redis_service.set(user.id, token_dict[1], expire=timedelta(days=1))

On each request, the middleware checks if the jti in the token matches what Redis has stored for that user:

is_accessible = redis_service.get(user_id)
if is_accessible and is_accessible.decode("utf-8") != jti:
    return JsonResponse({"message": "Invalid/Revoked Token"}, status=401)

If the user logs in from a new device, the old token becomes invalid. This gives you single active session behavior out of the box.

6. Brute-Force Protection with django-axes

Django-axes tracks failed login attempts and locks accounts automatically.

In settings.py:

AXES_FAILURE_LIMIT = 5       # Lock after 5 failed attempts
AXES_COOLOFF_TIME = 1        # Lockout lasts 1 hour
AXES_RESET_ON_SUCCESS = True # Reset counter on successful login

And we add the axes middleware and backend:

MIDDLEWARE = [
    ...
    "axes.middleware.AxesMiddleware",
    ...
]

AUTHENTICATION_BACKENDS = [
    "axes.backends.AxesBackend",
    "django.contrib.auth.backends.ModelBackend",
]

Axes handles the rest. If someone tries the wrong password 5 times, they're locked out for an hour.

7. Rate Limiting

We have two layers of rate limiting.

Global middleware limits all traffic - 100 requests/hour per IP (unauthenticated) or per user ID (authenticated):

class GlobalRateLimitMiddleware:
    def __call__(self, request):
        if request.user.is_authenticated:
            rate = "100/h"
            key_func = self.get_user_id_key
        else:
            rate = "100/h"
            key_func = self.get_ip_key

        limited = is_ratelimited(request=request, group="global_rate_limit",
                                  rate=rate, key=key_func, method="ALL", increment=True)
        if limited:
            raise Ratelimited()
        ...

Endpoint-level limits on login and register to stop credential stuffing:

@method_decorator(
    [
        ratelimit(key="post:email", rate="5/m", method="POST", block=True),
        ratelimit(key="ip", rate="10/m", method="POST", block=True),
    ],
    name="post",
)
class LoginView(APIView):
    ...

When a limit is hit, the custom exception handler returns a clean 429 response:

if isinstance(exc, Ratelimited):
    return returned_response(
        "failed",
        status=status.HTTP_429_TOO_MANY_REQUESTS,
        message="Slow down a bit!, You are making too many requests.",
    )

8. Argon2 Password Hashing

Argon2 is the strongest password hashing algorithm available today. It won the Password Hashing Competition and is recommended by OWASP.

In settings.py, we set it as the default:

PASSWORD_HASHERS = [
    "django.contrib.auth.hashers.Argon2PasswordHasher",
    "django.contrib.auth.hashers.PBKDF2PasswordHasher",
    "django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher",
]

Django tries each hasher in order. All new passwords use Argon2.

We also enforce strong passwords:

AUTH_PASSWORD_VALIDATORS = [
    {"NAME": "...UserAttributeSimilarityValidator"},
    {"NAME": "...MinimumLengthValidator", "OPTIONS": {"min_length": 12}},
    {"NAME": "...CommonPasswordValidator"},
    {"NAME": "...NumericPasswordValidator"},
]

Minimum 12 characters. No common passwords. No all-numeric passwords.

9. Consistent API Responses

Every response in DjangGuard follows the same structure:

{
  "status": "success",
  "message": "Login successful",
  "data": {
    "access": "<token>"
  }
}

This is handled by a single returned_response helper used everywhere. No more inconsistent error formats across different views. Your frontend always knows what shape to expect.

10. Redis Caching for Profile Data

The user profile endpoint caches the response in Redis for 1 hour to avoid hitting the database on every request:

def get(self, request):
    user = request.user
    key = f"user_profile:{user.id}"
    user_dict = cache.get(key)

    if user_dict:
        return returned_response("success", "User profile retrieved successfully",
                                  status.HTTP_200_OK, user_dict)

    user_dict = {
        "first_name": user.first_name,
        "last_name": user.last_name,
        "email": user.email,
        "date_joined": user.created_at,
    }
    cache.set(key, user_dict, timeout=60 * 60)
    return returned_response("success", "User profile retrieved successfully",
                              status.HTTP_200_OK, user_dict)

Simple but effective. As your user base grows, this matters a lot.

The API Endpoints

Here's a summary of all available endpoints:

Method	Endpoint	Description	Auth Required
`POST`	`/api/auth/register`	Create a new account	No
`POST`	`/api/auth/login`	Login and get a JWT token	No
`POST`	`/api/auth/logout`	Invalidate your token	Yes
`GET`	`/api/users/me`	Get your profile	Yes

Getting Started

1. Clone and install

git clone https://github.com/your-username/DjangGuard.git
cd DjangGuard/backend
pip install -r requirements.txt

2. Create your .env file

SECRET_KEY=your-secret-key-here
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_DB=0
CACHE_REDIS_URL=redis://127.0.0.1:6379/0

3. Run migrations and start the server

python manage.py migrate
python manage.py runserver

That's it. Your hardened API is running.

What You Can Add Next

DjangGuard is a starting point, not a finished product. Here are some things you can layer on top:

Email verification on registration
Password reset via email
Refresh token rotation
Swap SQLite for PostgreSQL before going to production
Docker + docker-compose for easier deployment
Two-factor authentication (2FA)

Final Thoughts

Security isn't something you add at the end. It's something you design from day one.

DjangGuard brings together JWT binding, Redis blacklisting, brute-force protection, rate limiting, and strong hashing - all in one clean codebase you can start a real project with.

If this was helpful, give the repo a ⭐ on GitHub.

engrmarkk / DjangGuard

DjangGuard

A security-focused Django REST API boilerplate with built-in authentication, rate limiting, JWT token management, and Redis-backed caching. Designed to serve as a hardened starting point for building production-ready APIs.

Overview

DjangGuard is a batteries-included Django REST Framework (DRF) backend template built with security at its core. It combines JWT-based authentication, brute-force protection, user-agent binding, Redis-backed token blacklisting, and global rate limiting — all wired together and ready to extend.

Features

JWT Authentication via djangorestframework-simplejwt with custom claims (user agent binding)
Token Blacklisting using Redis — tokens are invalidated on logout and revoked on device mismatch
Brute-Force Protection via django-axes — accounts are locked after 5 failed login attempts (1-hour cooldown)
Global Rate Limiting — 100 requests/hour per IP (unauthenticated) or…

View on GitHub

and share it with someone learning Django.

Have questions or suggestions? Drop them in the comments - I read every one.

Building MatchMetric-AI: A Real-Time Resume Tailoring Engine with Django, WebSockets, and LLMs

Adeniyi Olanrewaju — Tue, 17 Feb 2026 14:45:07 +0000

Applying for jobs is hard. Every resume needs to match the job description perfectly. To solve this, I built MatchMetric-AI, a tool that uses Artificial Intelligence to analyze resumes and give instant feedback.

What does this project do?

Reads PDFs: It extracts text from your resume using the PyPDF library.
AI Analysis: it sends that text to Google Gemini AI to see how well you match a job.
Live Updates: It uses WebSockets so you don't have to refresh the page to see results.
History: It saves your past scans so you can see your progress.

The Tech Stack

Django: The main framework.
Channels & Redis: To make the "Live" WebSocket connection work.
Google Gemini API: The "brain" that reads the resume.
PyPDF: To turn PDF files into plain text.

Here is a deep dive into how I built it.

The Core Vision MatchMetric-AI isn’t just a simple wrapper for an LLM. It’s a full-cycle service that:

Extracts raw text from uploaded PDF resumes.
Analyzes the resume against a specific Job Description.
Streams feedback back to the user instantly using WebSockets.
Persists the history so users can track their application improvements.

Technical Deep Dive

A. Modular Project Structure
I followed a "Service-Oriented" architecture to keep the project clean. Instead of bloating the Django views.py, I separated the logic into distinct modules:

ai/google_genai: Handles all communication with Gemini.
pdf_extract/pypdf_extractor: Contains the logic for parsing PDFs.
apis/resumehistory: Manages the WebSocket consumers and database history.

B. PDF Extraction with PyPDF
One of the first hurdles was converting complex PDF layouts into clean text that an AI can understand. I utilized PyPDF to iterate through document pages and clean the whitespace to ensure the AI prompt doesn't get cluttered with "junk" characters.

from pypdf import PdfReader


class PyPDFExtractor:
    def __init__(self, file_obj):
        self.reader = PdfReader(file_obj)

    def extract_text(self) -> str:
        text = ""
        for page in self.reader.pages:
            page_text = page.extract_text()
            if page_text:
                text += page_text + "\n"
        return text

C. Real-time Communication with Django Channels
Unlike standard HTTP where the user has to wait for a long AI processing time, I implemented WebSockets. This allows the server to maintain an open connection with the client.

The ResumeConsumer handles the connection. Because Gemini’s processing is synchronous, I used sync_to_async to ensure the server remains responsive while the AI "thinks."

D. Solving the ASGI "Handshake" Challenge
The most difficult part of the project was configuring the asgi.py to handle both standard HTTP (for logins) and WebSockets (for AI analysis) simultaneously. I had to ensure that the AuthMiddlewareStack was correctly positioned to allow my WebSocket to "see" the logged-in

application = ProtocolTypeRouter({
    "http": get_asgi_application(),
    "websocket": AuthMiddlewareStack(
        URLRouter(websocket_urlpatterns)
    ),
})

How to Run the Project

Prerequisites
Redis (for the message broker)

Google Gemini API Key (you can get it here: https://aistudio.google.com/)

Installation

Clone & Install, the repo url: https://github.com/engrmarkk/MatchMetric-AI:

pip install -r requirements.txt

Environment Variables: Configure your .env with GOOGLE_API_KEY and REDIS_URL and other variables in the env.example file.
Migrations:

python manage.py migrate

Launch:

chmod +x runapp.sh
./runapp.sh

Testing with Postman

Since this uses WebSockets, you can't test it like a normal website with a frontend library consuming the api.

Login to Django admin with a superuser credential, inspect the browser page and get the sessionid from cookies in the application tab.
Open Postman and start a WebSocket Request.
Go to the headers and set Cookie as the key and sessionid=
Connect to ws://127.0.0.1:8000/ws/resume-tailor/.
Send a JSON message with your resume text and the job description. You need to access the upload endpoint to extract the text from uploaded resume(.pdf).
Watch the AI response appear in real-time!

What I Learned

The biggest challenge was Authentication. I had to make sure the WebSocket knew which user was logged in. I learned how to use Django's sessionid cookies to securely connect the user to their history.

Django 6 Released: Here's How to Use Its Game-Changing Task Feature

Adeniyi Olanrewaju — Mon, 08 Dec 2025 09:21:24 +0000

Attention Django Developers: Exciting developments have just been announced: Django 6.0 has been released, introducing a highly anticipated feature: built-in task queues.

Eliminate the need for third-party Celery setups and complex Redis configurations. Django now seamlessly integrates task management directly within the framework.
Let me show you what this looks like and how you can use it today.

What Are Django Tasks?

Think of Django Tasks as Django's answer to Celery, but built-in. You can:

Run background jobs
Process data asynchronously
Send emails without blocking requests
Handle long-running operations

And the best part? It's all native Django code.

Setting Up Tasks in Django 6

First, make sure you're on Django 6.0+:

pip install Django==6.0

Important: Django 6 requires Python 3.12 or higher! If you're on an older Python version, you'll need to upgrade first.

Your First Django Task

Let's create a simple task that logs a message:

# tasks.py in your app
from django.tasks import task

@task
def log_message(message):
    print(f"Task received: {message}")
    return f"Processed: {message}"

That's it! You've created your first task. The @task decorator tells Django this function should run as a background task.

Running Tasks from Views

Here's how you enqueue tasks from a Django view:

# views.py
from django.http import HttpResponse
from .tasks import log_message

def trigger_task(request):
    # This queues the task to run in background
    log_message.enqueue(message="Hello from Django 6!")

    return HttpResponse("Task enqueued!")

The .enqueue() method adds your task to the queue. Your view returns immediately while the task runs in the background.

Configuring Task Backends

Django 6 comes with two built-in backends:

Immediate Backend (Default) Tasks run right away in the same thread:

# settings.py
TASKS = {
    "default": {
        "BACKEND": "django.tasks.backends.immediate.ImmediateBackend"
    }
}

Good for: Testing and development.

Dummy Backend Tasks don't run at all:

# settings.py
TASKS = {
    "default": {
        "BACKEND": "django.tasks.backends.dummy.DummyBackend"
    }
}

Good for: When you want to test task queuing without execution.

Real-World Example: Email Sender

Let's build something useful - an email sender task:

# tasks.py
from django.tasks import task
from django.core.mail import send_mail

@task
def send_welcome_email(user_email, username):
    subject = f"Welcome, {username}!"
    message = "Thanks for joining our platform."

    send_mail(
        subject=subject,
        message=message,
        from_email="noreply@example.com",
        recipient_list=[user_email]
    )

    return f"Email sent to {user_email}"

Use it in a view:

# views.py
from django.http import JsonResponse
from .tasks import send_welcome_email

def register_user(request):
    # Get user data from request...
    email = request.POST.get('email')
    username = request.POST.get('username')

    # Queue email task (won't block the response)
    send_welcome_email.enqueue(
        user_email=email,
        username=username
    )

    return JsonResponse({"status": "Registration complete!"})

The user gets an immediate response while the email sends in the background.

Need Production-Ready? Use django-tasks

For production use, you'll want a proper backend. The Django community is already building solutions. Here's one option:

pip install django-tasks

Configure it in settings:

# settings.py
INSTALLED_APPS = [
    'django_tasks',
    'django_tasks.backends.database',
    # ... your other apps
]

TASKS = {
    "default": {
        "BACKEND": "django_tasks.backends.database.DatabaseBackend"
    }
}

Run migrations and start the worker:

python manage.py migrate
python manage.py runserver
python manage.py db_worker  # In a separate terminal

Current Limitations

As Django 6 just released, keep in mind:

Built-in backends are basic – Immediate and Dummy only
Community backends are emerging – Watch for django-tasks-redis, django-tasks-rabbitmq
Python 3.12+ required – Time to upgrade!

Wrapping Up

Django 6's built-in tasks are exciting! They won't replace Celery overnight, but they offer a simpler alternative for many use cases.

When to use Django Tasks:

Simple background jobs
Email sending
Data processing
When you want minimal setup

Note: As Django 6 is brand new, expect rapid improvements to the task system. Check the official Django documentation for the latest updates.

Beyond Database Locks: Managing Concurrent User Transactions

Adeniyi Olanrewaju — Thu, 23 Oct 2025 09:53:22 +0000

The Simultaneous Update Anomaly

Imagine this nightmare scenario:

Your user, Sarah, sells a product for $100.
Two buyers pay her at the exact same moment.
Two "credit alert" webhooks hit your server simultaneously.
Both payments are for the same amount, to the same user.

What happens?

Worker 1 checks Sarah's balance: $0.
Worker 2 also checks Sarah's balance: $0.
Worker 1 adds $100. New balance: $100.
Worker 2 adds $100. New balance: $100.

Result: Sarah only received $100 instead of $200! Money has vanished.

This isn't a multiple-user problem. This is a single-user concurrency problem, and it's every payment processor's worst nightmare. Your database's with_for_update() lock is useless here because the two transactions are operating on separate connections from different workers.

Why Your Database Can't Save You

Think of your database row lock as a lock on Sarah's account file in a filing cabinet.

Worker 1 walks up, opens the cabinet, and takes out Sarah's file.
Worker 2 walks up at the same time, opens the same cabinet, and takes out the same file.
Both make copies, update them, and put them back.

They never knew the other was there! This is the chaos of concurrent systems.

The Solution: The "One-Operation-Per-User" Lock

We need to put a "BUSY" sign on Sarah herself. Not just her file, but on the very idea of processing her transaction. We need to ensure that for any critical operation on a user, only one request is processed at a time.

Let me show you the exact weapon we need, a distributed user lock.

Code Deep Dive: Building the User Traffic Cop

Here's how we implement a lock that works across all your servers:

from threading import Lock
from .responses import http_response_400
from functools import wraps
from apis.utils import get_redis_counter

lock = Lock()
top_up_locks = {}

def one_deposit_at_a_time(f):
    @wraps(f)
    def decorated_function(*args, **kwargs):
        from apis.crud import get_user_by_account_number
        # get account number from request
        payload = request.get_json()
        user = get_user_by_account_number(payload["account_number"])
        user_id = user.id
        key = f"one_top_up:{user_id}"
        with lock:
            if key not in top_up_locks:
                top_up_locks[key] = Lock()
            top_up_lock = top_up_locks[key]
        with top_up_lock:
            # This is to get the counter to check if it exist (increment = False)
            one_top_up = get_redis_counter(key, ex_time=5, increment=False)
            if one_top_up:
                return http_response_400(
                    {
                        'status': 'failed',
                        'msg': 'One transaction at a time pls'
                    }
                )
            # This is to set the counter and set it to be released in 5 secs
            get_redis_counter(key, ex_time=5, increment=True)
            return f(*args, **kwargs)
    return decorated_function

Let's break down the example provided, step-by-step.

Step 1: The Tools We Need

We use two main tools to build our distributed lock:

A Global Dictionary (top_up_locks): This stores our lock objects for each user.
A Master Lock (lock): This is a safety lock to make sure we don't create two locks for the same user at the same time, a lock for our locks!

from threading import Lock
lock = Lock() # The master lock
top_up_locks = {} # The locker where we store all user locks

Step 2: The "Decorator" - A Reusable Shield

The code uses a decorator called @one_deposit_at_a_time. Think of a decorator as a wrapper. It lets you add extra logic (like a lock) to any function without changing the function's own code.

def one_deposit_at_a_time(f): # 'f' is the original function
    @wraps(f)
    def decorated_function(*args, **kwargs):
        # ... OUR LOCKING LOGIC GOES HERE ...
        # Once the lock is acquired, we run the original function
        return f(*args, **kwargs)
    return decorated_function

Step 3: Creating a Unique Key for Each User

Every user needs their own personal lock. We don't want to lock everyone because one user is making a deposit! We create a unique key based on the user's ID.

payload = request.get_json()
user = get_user_by_account_number(payload["account_number"])
user_id = user.id
key = f"one_top_up:{user_id}" # e.g., "one_top_up:user_789"

Step 4: The Two-Step Locking Dance

This is the genius part. We perform two locking steps to be perfectly safe.

Step 4a: Get (or Create) the User's Personal Lock

We use the master lock to safely look inside our global dictionary.

With the master lock held, we check: "Does a lock for user_789 already exist?"
If not, we create a new Lock() object and store it in the dictionary.
We then immediately release the master lock. We are now only dealing with the one user's lock.

with lock: # Hold the master lock very briefly
    if key not in top_up_locks:
        top_up_locks[key] = Lock() # Create a new lock for this user
    top_up_lock = top_up_locks[key] # Get a reference to it

Step 4b: Acquire the User's Personal Lock

Now we try to acquire the lock for user_789.

with top_up_lock: will wait here if another request for the same user is already holding the lock.
Once the first request is done, this one will acquire the lock and proceed.
This ensures that for this user, requests are processed one after the other, even across multiple workers.

with top_up_lock: # This waits here if the lock is already held
    # Now we are safe to check the database and perform the operation

What Happens Now When Two Payments Arrive:

TIMELINE:

T=0s: Payment A and Payment B arrive simultaneously for Sarah
T=0.1s: Payment A acquires the lock for user_sarah_123
T=0.1s: Payment B tries to acquire the lock → FAILS! Gets "please wait" message
T=1.1s: Payment A finishes processing, releases the lock
T=1.2s: Payment B automatically retries, acquires the lock, processes successfully
T=2.3s: Payment B finishes

Result: Sarah gets $200 correctly! The second payment was simply asked to wait its turn.

Conclusion: From Chaos to Control

The double deposit scenario reveals a fundamental truth: database transactions alone cannot protect you from distributed system problems. You need application-level coordination.

By implementing a simple user-based distributed lock, you transform your system from one that loses money under pressure to one that calmly queues transactions and processes them with perfect accuracy.

Next time two credit alerts arrive at once, your system will handle them with the grace of a seasoned traffic director: "You first, then you." No panic, no lost money, just rock-solid reliability.

Handling 404 and 500 Errors Gracefully in Django with Custom JSON Responses

Adeniyi Olanrewaju — Sat, 30 Aug 2025 11:12:33 +0000

When building RESTful APIs with Django, the default error pages 404 Not Found (when you try to access an unavailable url), 500 Internal Server Error, return HTML responses. While this is fine for traditional web apps, API clients expect JSON responses instead.

In this article, I’ll walk through how to override Django’s error handlers using handler404 and handler500, and return consistent, structured JSON responses for your API.

Why Customize Error Handlers?

By default, Django shows pages like this when an error occurs:

404 → “Page not found” (HTML template)
500 → “Server error” (HTML template)

For API consumers, this is not helpful. Instead, something like this should be returned:

{
  "status": "Failed",
  "message": "he requested resource was not found"
}

{
  "status": "Failed",
  "message": "Internal Server Error"
}

Setting Up Custom Exception Handlers

First, create a file called custom_exceptions.py inside your API service folder (for example api_services/custom_exceptions.py).

# api_services/custom_exceptions.py
from django.http import JsonResponse

class CustomException:
    @staticmethod
    def custom_404_view(request, exception=None):
        return JsonResponse(
            {"status": "Failed", "message": "The requested resource was not found"},
            status=404
        )

    @staticmethod
    def custom_500_view(request):
        return JsonResponse(
            {"status": "Failed", "message": "Internal Server Error"},
            status=500
        )

custom_404_view → handles invalid routes.
custom_500_view → handles unexpected server errors.

We’re using JsonResponse here because it works outside of Django REST Framework (DRF) and guarantees valid JSON output.

Registering Handlers in `urls.py`

Now tell Django to use these handlers globally. In your project’s main urls.py file:

from django.contrib import admin
from django.urls import path, include
from django.conf.urls import handler404, handler500
from api_services.custom_exceptions import CustomException

BASE_PREFIX = "api/v1"

urlpatterns = [
    path("admin/", admin.site.urls),
    path(f"{BASE_PREFIX}/users/", include("apis.users.urls")),
]

# Attach custom error handlers
handler404 = CustomException.custom_404_view
handler500 = CustomException.custom_500_view

Important: Turn Off Debug Mode

By default, Django shows detailed debug pages when DEBUG = True.
This is useful for developers, but it overrides your custom error handlers.
To make your JSON handlers work, set this in settings.py:

DEBUG = False
ALLOWED_HOSTS = ["*"]  # Or set to your domain(s)

Now Django will call your custom_404_view and custom_500_view instead of showing HTML pages.

Testing the Setup

Run your server

python manage.py runserver

Try hitting an invalid endpoint:

GET http://127.0.0.1:8000/api/v1/use

You’ll now get a clean JSON response:

{
  "status": "Failed",
  "message": "The requested resource was not found"
}

For 500 errors, you can temporarily raise an exception in a view and see the JSON response.

Why This Matters

✅ Cleaner API: Clients always get JSON, no ugly HTML errors.
✅ Consistency: Same error format as your success responses.
✅ Better UX: Frontend apps can handle errors gracefully.

When to Use LabelEncoder and OneHotEncoder in Machine Learning

Adeniyi Olanrewaju — Mon, 28 Jul 2025 13:32:18 +0000

Imagine trying to teach a computer what Small, Medium, and Large mean.
To you, these words are simple. But for a machine, they’re just strange strings of letters.
Machines don’t understand text, they only understand numbers.
So before we train a machine learning model, we need to translate these text categories into numbers that the model can actually process.
Two popular translators are:

LabelEncoder
OneHotEncoder But when do you use each one? Let’s make this super clear.

1. What Is Categorical Data?

Categorical data is data made up of labels or names, not numbers.
Think about these examples:

Size: Small, Medium, Large
Weather: Sunny, Rainy, Cloudy
Cities: Lagos, Abuja, Kano We can’t just throw these words at a model, we need to convert them into numbers first.

2. Label Encoding

Label Encoding simply assigns a number to each category, starting from 0.

Example with sizes:

Small  → 0  
Medium → 1  
Large  → 2

When Should You Use Label Encoding?

Use it when the categories have a natural order or ranking.
Examples:

Low < Medium < High
Cold < Warm < Hot
Small < Medium < Large

Never use LabelEncoder for categories like colors or city names — because the model will think Green (2) > Red (0), which is meaningless!

from sklearn.preprocessing import LabelEncoder

sizes = ["Small", "Large", "Medium", "Small", "Large"]

label_encoder = LabelEncoder()
encoded_sizes = label_encoder.fit_transform(sizes)

print("Original:", sizes)
print("Encoded:", encoded_sizes)
print("Classes:", label_encoder.classes_)

Output:

Original: ['Small', 'Large', 'Medium', 'Small', 'Large']
Encoded: [2 0 1 2 0]
Classes: ['Large' 'Medium' 'Small']

Notice how it encoded alphabetically (Large=0, Medium=1, Small=2).
If you want Small=0, Medium=1, Large=2, you can map it manually:

size_order = {'Small': 0, 'Medium': 1, 'Large': 2}

3. One-Hot Encoding

One-Hot Encoding creates separate columns for each category and marks them with 0 or 1.
One-Hot Encoding creates separate columns for each category and marks them with 0 or 1.

For example:

Color: Red   → [1, 0, 0]
       Blue  → [0, 1, 0]
       Green → [0, 0, 1]

This way, no category is greater or less than another.

When Should You Use One-Hot Encoding?

Use it when the categories have no order, like colors, cities, or animal names.
It avoids the fake ranking problem that LabelEncoder might create.

from sklearn.preprocessing import OneHotEncoder
import numpy as np

colors = np.array(["Red", "Blue", "Green", "Blue", "Red"]).reshape(-1, 1)

onehot_encoder = OneHotEncoder(sparse_output=False)
encoded_colors = onehot_encoder.fit_transform(colors)

print("Original:", colors.flatten())
print("Encoded:\n", encoded_colors)
print("Categories:", onehot_encoder.categories_)

Output:

Original: ['Red' 'Blue' 'Green' 'Blue' 'Red']
Encoded:
 [[0. 0. 1.]
  [1. 0. 0.]
  [0. 1. 0.]
  [1. 0. 0.]
  [0. 0. 1.]]
Categories: [array(['Blue', 'Green', 'Red'], dtype=object)]

4. LabelEncoder vs OneHotEncoder

Think of it like this:

LabelEncoder says: I’ll give each category a number. You figure out what it means.

OneHotEncoder says: I’ll give each category its own column so no one feels more important than the other.

Aspect	LabelEncoder	OneHotEncoder
Best for	Ordered categories	Unordered categories
Output	Single column (0, 1, 2...)	Multiple columns (0/1)
Risk	Fake order for labels	No fake order
Example	Small < Medium < Large	Red, Blue, Green

5. What About 2 Categories?

If you only have 2 categories, LabelEncoder is fine because it will just give 0 and 1.

Example:

from sklearn.preprocessing import LabelEncoder

binary = ["Yes", "No", "Yes", "No"]

encoder = LabelEncoder()
encoded = encoder.fit_transform(binary)

print("Encoded:", encoded)  # [1 0 1 0]
print("Classes:", encoder.classes_)  # ['No' 'Yes']

Here:

No  → 0
Yes → 1

6. Things to Keep in Mind

Use LabelEncoder when your data has a natural order (e.g., Small < Medium < Large).
Use OneHotEncoder when your data has no order (e.g., colors, cities).
For 2 categories, LabelEncoder automatically uses 0 and 1.
The order of rows in your CSV does not matter.

Think of LabelEncoder as the tool for ranking categories that have order.
Think of OneHotEncoder as the tool for naming categories when order doesn’t exist.

If you mix them up (like using LabelEncoder on colors), your model might get confused and make bad predictions.

ACID Operation in Backend Engineering: Building Data Integrity Like a Pro

Adeniyi Olanrewaju — Thu, 24 Jul 2025 10:02:37 +0000

When you build a banking app, an e-commerce checkout, or any critical backend system, data integrity is everything. A single failed transaction could cause duplicate charges, missing payments, or worse.

To prevent such disasters, databases use ACID properties:

Atomicity
Consistency
Isolation
Durability

In this article, we’ll break each property into plain English explanations with Python code examples using SQLAlchemy.

1. Atomicity – All or Nothing

Atomicity means that a transaction is indivisible.

If part of the transaction fails, the entire operation is rolled back.

Example Scenario

Alice is transferring $300 to Bob:

Subtract $300 from Alice’s balance.
Add $300 to Bob’s balance.

If step 2 fails, step 1 must be undone.

Code Example

from sqlalchemy import create_engine, Column, Integer, String
from sqlalchemy.orm import sessionmaker, declarative_base

Base = declarative_base()

class Account(Base):
    __tablename__ = 'accounts'
    id = Column(Integer, primary_key=True)
    name = Column(String, unique=True)
    balance = Column(Integer, default=0)

engine = create_engine("sqlite:///bank.db", echo=False)
Session = sessionmaker(bind=engine)
Base.metadata.create_all(engine)

def atomic_transfer(session, from_id, to_id, amount):
    try:
        from_acc = session.query(Account).filter(Account.id == from_id).with_for_update().first()
        to_acc = session.query(Account).filter(Account.id == to_id).with_for_update().first()

        if from_acc.balance < amount:
            raise ValueError("Insufficient funds")

        from_acc.balance -= amount
        to_acc.balance += amount

        session.commit()  # Only commit if all steps succeed
        print("Transfer completed.")
    except Exception as e:
        session.rollback()  # Undo everything if something fails
        print("Transfer failed:", e)

# Run a test
session = Session()
atomic_transfer(session, from_id=1, to_id=2, amount=300)
session.close()

2. Consistency – Valid State Before and After

Consistency ensures that data always follows rules.
For example:

Balances cannot go negative.
Total money in the system should remain correct.

Example

# Consistency check
if from_acc.balance < amount:
    raise ValueError("Insufficient funds: cannot go negative")

Here, we ensure no transaction breaks the system’s rules.

3. Isolation – Transactions Don’t Interfere

Isolation means that concurrent transactions behave as if they’re running one after another, even when they’re processed at the same time.

Example

Two transfers happening at once:

Alice transfers $200 to Bob.
Bob transfers $100 to Charlie.

Without isolation, their operations might overlap and cause wrong balances.
Code Example

Using with_for_update() to lock rows during the transfer:

from_acc = (
            session.query(Account)
            .filter(Account.id == from_id)
            .with_for_update()
            .first()
        )
to_acc = (
            session.query(Account)
            .filter(Account.id == to_id)
            .with_for_update()
            .first()
        )

This works for a single worker, but when you have multiple workers or parallel requests, isolation gets tricky.

4. Durability – Changes Persist

Durability guarantees that once a transaction is committed, the changes survive crashes.

Example

def durable_deposit(session, account_id, amount):
    try:
        acc = session.query(Account).filter(Account.id == account_id).with_for_update().first()
        acc.balance += amount
        session.commit()
        print(f"Deposited {amount} to {acc.name}. This change is permanent.")
    except Exception as e:
        session.rollback()
        print("Deposit failed:", e)

Even if your server restarts after session.commit(), the deposit remains in the database.

5. Full Example: Deposit + Transfer

def deposit_and_transfer(session, deposit_to, deposit_amt, transfer_from, transfer_to, transfer_amt):
    try:
        # Deposit
        acc = session.query(Account).filter(Account.id == deposit_to).with_for_update().first()
        acc.balance += deposit_amt
        print(f"Deposited {deposit_amt} to {acc.name}. New balance: {acc.balance}")

        # Transfer
        from_acc = session.query(Account).filter(Account.id == transfer_from).with_for_update().first()
        to_acc = session.query(Account).filter(Account.id == transfer_to).first()

        if from_acc.balance < transfer_amt:
            raise ValueError("Insufficient funds for transfer")

        from_acc.balance -= transfer_amt
        to_acc.balance += transfer_amt

        session.commit()
        print("Deposit and transfer successful.")
    except Exception as e:
        session.rollback()
        print("Operation failed:", e)

This ensures all steps succeed or all fail.

Why ACID Matters

Atomicity: No partial transfers.
Consistency: No invalid states.
Isolation: No clashing transactions.
Durability: Data persists after commit.

Coming Next: Isolation Under Pressure

Our examples work well when there’s one worker.
But with 4 workers handling two webhooks at the same time, things can break.
We’ll uncover why with_for_update() is not enough and how to use distributed locks or queues to fix it.

Poetry Explained: A Better Tool for Managing Python Projects

Adeniyi Olanrewaju — Wed, 23 Jul 2025 09:44:56 +0000

If you’ve worked with Python, you’ve probably used pip to install packages. It’s the default tool in Python to add libraries like Flask, Requests, or Pandas.

But there's another tool called Poetry that does more than just install packages. Poetry helps manage your whole Python project: dependencies, virtual environments, versioning, and publishing, all in one place.

In this article, we’ll explain:

What Poetry is
How to install and use it
How it compares with pip
When to choose Poetry over pip

Let’s begin!

📦 What Is Poetry?

Poetry is a Python dependency and package manager. It was created to solve the common problems Python developers face, such as:

Messy requirements.txt files
Confusing virtual environments
Publishing packages to PyPI manually

Poetry uses a single file — pyproject.toml — to manage your dependencies and project configuration.

It also creates and manages a virtual environment automatically, so you don't have to use tools like venv or virtualenv.

🔧 Installing Poetry

To install Poetry, you can run this one-line command in your terminal:

curl -sSL https://install.python-poetry.org | python3 -

After installation, make sure it works:

poetry --version

If that prints something like Poetry (version 2.1.3), you’re good to go!

🚀 How to Use Poetry

1. Create a New Project

poetry new my_project

This creates a folder my_project with this structure:

my_project/
├── pyproject.toml
├── README.rst
├── my_project/
│   └── __init__.py
└── tests/
    └── test_my_project.py

2. Add a Dependency

poetry add requests

Poetry:

Adds requests to the pyproject.toml
Installs it in a virtual environment
Creates or updates the poetry.lock file

3. Activate the Virtual Environment

Poetry creates a virtual environment automatically.
To activate it, run:

eval $(poetry env activate)

After this, you are inside the Poetry-managed environment.
You can now run Python directly:

python main.py

4. Run Without Activating

You can also run commands without manually activating the environment:

poetry run python main.py

5. Install All Dependencies

When you clone a project, simply run:

poetry install

It installs all the packages listed in pyproject.toml and poetry.lock.

📁 Poetry vs pip: Key Differences

Feature	`pip`	`poetry`
Dependency management	Manual via `requirements.txt`	Automatic via `pyproject.toml` and `poetry.lock`
Virtual environments	You set it up yourself	Automatically created and managed
Adding packages	`pip install`	`poetry add`
Removing packages	`pip uninstall`	`poetry remove`
Dependency resolution	Basic	Advanced (checks compatibility)
Lock file	No built-in support	Yes (`poetry.lock`)
Project creation	Not available	`poetry new` or `poetry init`
Publishing to PyPI	Manual (twine etc.)	Built-in (`poetry publish`)

In short, pip only installs packages. Poetry manages the whole project.

✅ Why Use Poetry?

Use Poetry if:

You want a clean and consistent environment
You are building a Python library or application
You want to avoid manually editing requirements files
You want built-in tools for versioning and publishing

Use pip if:

You're working on simple scripts
You don’t want extra tools
You prefer traditional virtualenv setups

pyproject.toml Example

[tool.poetry]
name = "my_project"
version = "0.1.0"
description = "My awesome Python project"
authors = ["Your Name <you@example.com>"]

[tool.poetry.dependencies]
python = "^3.10"
requests = "^2.31.0"

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

This is what controls your project. It replaces setup.py, requirements.txt, and MANIFEST.in — all in one file.

🏁 Conclusion

Poetry upgrades your Python workflow. It takes care of dependencies, virtual environments, and even publishing. With just one command: eval $(poetry env activate), you can start coding without worrying about setup. While pip is great for simple tasks, Poetry is better for serious projects.

If you are tired of managing requirements.txt and venv by hand, try Poetry. It makes Python development faster, cleaner, and less frustrating.

Introducing Quart: A Modern Alternative to Flask (with Async Support)

Adeniyi Olanrewaju — Mon, 14 Jul 2025 13:17:21 +0000

If you've used Flask before and loved how simple it is to build APIs, you’ll probably enjoy Quart too. Quart is like Flask, but with built-in async support, making it better for handling modern, high-speed web applications.

💡 Why Quart?

Flask is great, but it wasn’t built with async/await in mind. In today’s world where performance and speed are critical, especially for APIs having support for asynchronous code (without workarounds) is a big win.

Quart gives you:

The same API and structure as Flask
Support for async views, database calls, etc.
Works well with tools like SQLAlchemy, JWT, and more

🔁 Flask vs. Quart (Basic Example)

Flask:

from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello from Flask!"

Quart:

from quart import Quart

app = Quart(__name__)

@app.route("/")
async def hello():
    return "Hello from Quart!"

You’ll notice the main difference is async def instead of def. That allows you to use await inside the route, like calling an async database or HTTP request.

🔐 JWT Authentication Example in Quart

from quart import Quart
from quart_jwt_extended import JWTManager, jwt_required, create_access_token

app = Quart(__name__)
app.config["JWT_SECRET_KEY"] = "your-secret-key"

jwt = JWTManager(app)

@app.route("/login", methods=["POST"])
async def login():
    # Dummy example
    access_token = create_access_token(identity="user123")
    return {"access_token": access_token}

@app.route("/protected")
@jwt_required
async def protected():
    return {"message": "This is a protected route"}

📁 Example Project

I’ve created a small Quart project that shows how to:

Set up Quart with async SQLAlchemy
Use JWT for authentication
Organize routes and config

👉 Check it out on GitHub:

engrmarkk / quart-api

Quart API

A Python-based asynchronous REST API built with Quart, SQLAlchemy (async), and [PostgreSQL], using Poetry for dependency management.

🚀 Features

Fast async API with Quart
PostgreSQL + SQLAlchemy (async ORM)
JWT authentication with quart-jwt-extended
Fully typed models
Alembic for migrations

🛠️ Requirements

Python 3.10+
Poetry
PostgreSQL database

📦 Installation

1. Clone the repository

git clone https://github.com/engrmarkk/quart-api.git
cd quart-api

2. Install dependencies

poetry install

3. Create `.env`

touch .env

Edit .env and set your database credentials or JWT secret, e.g.:

DB_URI=postgresql+asyncpg://username:password@localhost:5432/quart-api # or your external db (but +asyncpg: should be present in the uri)
SECRET_KEY=supersecretkey

🗃️ Database Setup

Create the PostgreSQL database

CREATE DATABASE quart_api;

Run migrations

poetry run alembic upgrade head

🔐 JWT Auth (Optional Setup)

Ensure you're using quart-jwt-extended. Poetry handles this if you ran poetry install.

▶️ Running the Server

chmod u+x run_it.sh # to give the file permission the first time

…

View on GitHub

🧠 Final Thoughts

Quart is a great choice if you're already familiar with Flask and want to step into the world of asynchronous Python. It lets you build scalable, modern APIs without changing much in your existing workflow.

So if you're starting a new project, give Quart a try!

What is host "0.0.0.0"?

Adeniyi Olanrewaju — Thu, 24 Apr 2025 20:38:22 +0000

When you're building a web application or server in any programming language, at some point you might come across this line:

host="0.0.0.0"

Let’s break down what host="0.0.0.0" means, why it’s used, and when to use it. This article will help you understand the concept in a simple way, even if you're not using Python or Flask specifically.

What is `host="0.0.0.0"`?

0.0.0.0 is a special IP address. It doesn’t point to a single device. Instead, it means “all IPv4 addresses on the local machine.”
When you set host="0.0.0.0", you are telling your program to listen for requests on any network interface your machine has.
In simpler terms:

If someone tries to connect to your server through localhost, 127.0.0.1, your private IP (like 192.168.x.x), or even a public IP (if allowed), the server will respond.
It opens the app to the outside world (your local network or the internet, depending on your setup).

Why Use host="0.0.0.0"?

By default, many programs only listen on 127.0.0.1 (also known as localhost). That means they only accept connections from your own computer.
But what if:

You want to test the app from your phone or another device on the same Wi-Fi?
You’re building an API for others to use from outside?
You’re running the server inside a Docker container and need it to be accessible from your host machine?

That’s where host="0.0.0.0" comes in. It allows your app to receive requests from other devices.

Real-Life Example Using Python

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello():
    return "Hello from the server!"

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=4000)

With host='127.0.0.1', you can only visit http://localhost:4000 from your own machine.

With host='0.0.0.0', you can also visit http://<your-ip>:4000 from:

Your phone
Another laptop on the same network
Other machines in your environment

Important Note on Security

Using 0.0.0.0 can make your app accessible to everyone, even over the internet if your firewall and router allow it. That’s useful for testing, but dangerous if the app is not secure.
For production, it’s better to:

Use firewalls to block unwanted access
Use HTTPS and authentication
Consider using a reverse proxy like Nginx or a cloud provider that adds security layers

Summary

0.0.0.0 means "listen on all network interfaces".
It's useful when you want others (other devices or users) to connect to your app.
It works across many programming languages.

How to Set Up GitHub Actions to Deploy a Simple Docker App on an EC2 Server

Adeniyi Olanrewaju — Wed, 23 Apr 2025 08:53:29 +0000

If you're working on a web app and want to automate your deployment from GitHub to your server, this article is for you. I’ll walk you through everything step by step—from creating an EC2 server on AWS to setting up GitHub Actions to deploy your Docker app.

🧱 What You Need

A GitHub repository with your app (Dockerized)
An AWS account
Basic knowledge of the command line

🖥️ Step 1: Launch an EC2 Instance on AWS

Login to AWS Console → Go to EC2
Click Launch Instance
Choose a free-tier AMI, like Ubuntu 22.04 LTS
Select t2.micro (free-tier)
Create a new key pair (this will give you a .pem file to SSH later)
Allow port 22 (SSH) in security group
Launch the instance

🔑 Step 2: SSH into Your Server
Once your instance is running, SSH into the server from your local:

chmod 400 your-key.pem  # Make the key secure
ssh -i your-key.pem ubuntu@<your-ec2-public-ip>

You’re now inside your server 🎉

🐳 Step 3: Install Docker & Git
Run the following commands on the server:

sudo apt update
sudo apt install docker.io docker-compose git -y
sudo usermod -aG docker $USER
newgrp docker

Make sure Docker works:

docker --version

🗝️ Step 4: Setup SSH Key for GitHub Access
We’ll generate an SSH key to allow this server to pull from your GitHub repo:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Press Enter to save at the default location (/home/ubuntu/.ssh/id_rsa), and also press Enter when asked for a passphrase.

Then:

cat ~/.ssh/id_rsa.pub

Copy the output.

Go to GitHub > Settings > SSH and GPG Keys > New SSH key
Paste the public key there.

Now test:

ssh -T git@github.com

It should say Hi <your username!> You’ve successfully authenticated.

🐙 Step 5: Clone Your Repo

Visit your repo on github
Click the code button
Switch to the SSH tab
Copy the Git URL.

git clone git@github.com:your-username/your-repo.git

Make sure your app is using Docker (e.g., you have a Dockerfile and docker-compose.yml).

🔐 Step 6: Add Your EC2 Private Key to GitHub Secrets
Go to the GitHub repository of your project:

Click Settings > Secrets and variables > Actions
Click New repository secret
- Name: SSH_PRIVATE_KEY
- Value: Paste the content of your .pem file (e.g., your-key.pem) Also add:
HOST → EC2 PUBLIC IP
USERNAME → ubuntu

⚙️ Step 7: Add GitHub Actions Workflow
In your project folder, create:

.github/workflows/deploy.yml

Here’s the content:

name: Deploy App
run-name: Deploy - ${{ github.event.head_commit.message }}

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 5

    steps:
    - name: Deploy via SSH
      uses: appleboy/ssh-action@v0.1.10
      with:
        host: ${{ secrets.HOST }}
        username: ${{ secrets.USERNAME }}
        key: ${{ secrets.SSH_PRIVATE_KEY }}
        port: 22
        script: |
          cd your-repo-folder
          git pull origin main
          docker compose up --build -d --force-recreate
          docker image prune -f

🚀 Step 8: Push and Watch it Deploy
Every time you push to main, the workflow will:

SSH into the server
Pull the latest changes
Rebuild and restart your Docker app

You can view logs on GitHub under Actions tab.

Synchronous vs. Asynchronous in Python: Understanding the Key Differences

Adeniyi Olanrewaju — Sat, 29 Mar 2025 15:35:19 +0000

Introduction

When building applications, it’s important to know how tasks are handled. Python allows both synchronous and asynchronous programming, and each has its benefits and drawbacks. Choosing the right approach can make your application faster and more efficient. In this article, we will explain the difference between these two methods and look at the frameworks that support them in Python.

What is Synchronous Programming?

Synchronous programming means tasks run one after another. Each task must finish before the next one starts. This makes it simple to follow, but it can be slow when dealing with multiple operations.

Real-Life Example

Imagine you are at a bank, and there is only one cashier. Each customer must wait in line and can only be served after the previous customer is done. This is how synchronous programming works—one task at a time, in order.

Pros and Cons of Synchronous Programming

✅ Easy to understand and debug
✅ Simple to implement
❌ Can be slow when handling multiple tasks
❌ Blocks execution, causing delays in performance

Python Frameworks for Synchronous Programming

Flask – A simple web framework that processes requests one at a time.
Django (Default Mode) – Django processes requests synchronously unless modified.
Requests – A popular library for making HTTP requests, but it runs synchronously.

What is Asynchronous Programming?

Asynchronous programming allows multiple tasks to run at the same time. This is useful for operations that involve waiting, such as database queries or API requests. Instead of blocking the whole program, asynchronous programming continues running other tasks while waiting for a response.

Real-Life Example

Imagine you are downloading multiple files from the internet. Instead of waiting for one file to finish before starting the next, your computer can download several files at the same time. You can even browse the internet or work on something else while the downloads continue in the background. This is how asynchronous programming works—multiple tasks can run independently without blocking each other.

Pros and Cons of Asynchronous Programming

✅ Ideal for tasks that involve waiting (e.g., API calls, database queries)
✅ Improves performance for applications with multiple users
✅ Helps build real-time applications like chat apps
❌ More complex to understand and debug
❌ Requires knowledge of event loops and coroutines

Python Frameworks for Asynchronous Programming

FastAPI – A high-performance web framework that runs fully asynchronously.
Django (With ASGI and Django Channels) – Supports async processing when configured with ASGI.
Asyncio – Python’s built-in library for handling asynchronous tasks.

When to Use Synchronous vs. Asynchronous Programming?

Use Synchronous Programming When:

Your application is simple and does not need to handle many tasks at once.
You are working with CPU-heavy tasks rather than waiting for responses.
You prefer a straightforward approach that is easy to debug.

Use Asynchronous Programming When:

Your application involves making lots of API calls or database queries.
You need to handle many users at the same time without slowing down.
You are building real-time applications like chat apps or live notifications.

Conclusion

Choosing between synchronous and asynchronous programming depends on your project. Synchronous programming is easier to use, but asynchronous programming is better for handling multiple tasks at once.

Frameworks like Flask and Django (default) work well for simple applications, while FastAPI, Django with ASGI are better for handling multiple users at once.

Understanding these two approaches will help you build better applications that perform well. If you have experience with synchronous or asynchronous frameworks, feel free to share your thoughts in the comments! 🚀

Forem: Adeniyi Olanrewaju

Building a Secure Django REST API from Scratch - DjangGuard

Why Security Needs to Come First

The Tech Stack

Project Structure

1. Custom User Model

2. JWT with User Agent Binding

3. User Agent Validation Middleware

4. Redis Token Blacklisting

5. Single Active Session

6. Brute-Force Protection with django-axes

7. Rate Limiting

8. Argon2 Password Hashing

9. Consistent API Responses

10. Redis Caching for Profile Data

The API Endpoints

Getting Started

What You Can Add Next

Final Thoughts

engrmarkk / DjangGuard

DjangGuard

Table of Contents

Overview

Features

Building MatchMetric-AI: A Real-Time Resume Tailoring Engine with Django, WebSockets, and LLMs

What does this project do?

The Tech Stack

Technical Deep Dive

How to Run the Project

Testing with Postman

What I Learned

Django 6 Released: Here's How to Use Its Game-Changing Task Feature

What Are Django Tasks?

Setting Up Tasks in Django 6

Your First Django Task

Running Tasks from Views

Configuring Task Backends

Real-World Example: Email Sender

Need Production-Ready? Use django-tasks

Current Limitations

Wrapping Up

Beyond Database Locks: Managing Concurrent User Transactions

The Simultaneous Update Anomaly

Why Your Database Can't Save You

The Solution: The "One-Operation-Per-User" Lock

Code Deep Dive: Building the User Traffic Cop

Step 1: The Tools We Need

Step 2: The "Decorator" - A Reusable Shield

Step 3: Creating a Unique Key for Each User

Step 4: The Two-Step Locking Dance

Step 4a: Get (or Create) the User's Personal Lock

Step 4b: Acquire the User's Personal Lock

What Happens Now When Two Payments Arrive:

Conclusion: From Chaos to Control

Handling 404 and 500 Errors Gracefully in Django with Custom JSON Responses

Why Customize Error Handlers?

Setting Up Custom Exception Handlers

Registering Handlers in urls.py

Important: Turn Off Debug Mode

Testing the Setup

Why This Matters

When to Use LabelEncoder and OneHotEncoder in Machine Learning

1. What Is Categorical Data?

2. Label Encoding

When Should You Use Label Encoding?

3. One-Hot Encoding

When Should You Use One-Hot Encoding?

4. LabelEncoder vs OneHotEncoder

5. What About 2 Categories?

6. Things to Keep in Mind

ACID Operation in Backend Engineering: Building Data Integrity Like a Pro

1. Atomicity – All or Nothing

Example Scenario

Code Example

2. Consistency – Valid State Before and After

Example

3. Isolation – Transactions Don’t Interfere

Example

4. Durability – Changes Persist

Example

Registering Handlers in `urls.py`

3. Create `.env`

What is `host="0.0.0.0"`?