I'm starting a new Django series where I'll post one common Django error every day and walk through how to fix it with a simple, beginner-friendly explanation.

Whether you're just getting started or you've been building with Django for a while, I hope these posts help you debug your projects a little faster.

Feel free to follow along, ask questions, and even suggest errors you'd like me to cover next. Happy coding! 🚀

When in my beginner days, every side project started the same way.. it's usually, that Django or DRF on one side, a Svelte app on the other, and a weekend gone on wiring auth, CORS and two deploys before writing a single actual feature. like, for work-scale projects, fair enough. but for small and medium projects, like mine, solo ones, that was always more hassle than the project itself. so back in August 2022 I started a project called fymo, to make one-repo Python+Svelte projects a normal thing to build.

I got stuck early, compiling Svelte from Python and making the two sides talk to each other was beyond me then, so it sat there for a while, like my other side projects did. between years, i came back and forth, but this time it stuck, and I finished it.

fymo renders real Svelte 5 components from Python stuff like; esbuild compiles them at build time, one long-lived Node process does the SSR, and the browser hydrates them like any Svelte app.

day to day it'll feel familiar: controllers are basically views that return a dict, and the dict lands in Svelte as props. functions under app/remote/ become typed imports in Svelte, so no serializer, no endpoint, no fetch code. fymo new gives a running app with sign in, fymo generate resource posts gives a routed page, CRUD endpoints and a passing test file. fymo destroy takes it back out, unless you edited the files, then it refuses.

Anything misconfigured fails at boot with the fix right there in the error message. Nothing falls back silently. that's most of the design philosophy really.

But to be clear, it's not Django and it's not trying to be. no ORM, no admin, no forms, bring your own data layer. if you need those, Django is still the right call. this is for when Django plus DRF plus a separate frontend repo felt like three tools for a one-tool job.

But limitations, honestly: you need Node installed (build and runtime), it's WSGI not asyncio, no ORM, one maintainer, and it's v0.20 so things still break between versions, loudly though.

Repo: https://github.com/Bishwas-py/fymo pip install fymo

I'd honestly like to hear where it breaks, unusual project shapes are exactly what I can't simulate on my own.

🚨 Django Error #001

Debugging is part of every developer's journey. In this series, I'll be sharing common Django errors I've encountered, why they happen, and how to fix them.

Today's error: RelatedManager Object Has No Attribute.

I hope this saves someone hours of debugging! 💚

💬 Have you ever encountered this error? Let me know in the comments.

💾 Save this post for later and follow for more Django Errors & Solutions.

I recently launched a side project called Glyph Game, built with Django.

link: https://glyphgame.dev/

I chose Django because I wanted a framework that could handle the backend logic, daily puzzle generation, user sessions, and future expansion without adding a lot of complexity.

Some of the things Django is handling:

• Daily puzzle generation and serving
• Database models for game data
• User statistics and progress
• API endpoints for the frontend
• Admin panel for managing content

This project has been a great way to learn more about structuring a Django application beyond a typical CRUD app.

I'd love feedback from other Django developers:

• How would you structure a game backend like this?
• Any recommendations for improving scalability or performance?
• Are there Django packages or patterns you've found particularly useful for browser games?

If anyone is interested in the implementation details, I'm happy to share more about the architecture and the challenges I ran into while building it.

After 18 months solo, I shipped Sijal — the core of Fasil, an Arabic structured debate platform where every argument gets AI-scored in real time and every audience vote carries a cryptographic hash.

Stack: Django 4.x + Channels (WebSockets for live phase turn notifications), PostgreSQL, Redis, Auth0, Azure Blob, Stripe. The debate has 3 goals, each running through 6 ordered phases — opening, counter-argument, rebuttal, counter-rebuttal, questions, answers. One designated speaker per phase, enforced by a PHASE_SPEAKER_RULES map at the application layer.

Two modes: TimeLocked (a watchdog daemon polls every N seconds against Timeline records, computes wall-clock windows, and enqueues agent tasks when a phase is open and unfilled) and Filibuster (phases advance the moment a contribution is submitted — zero polling needed, the chain fires from _notify_next_speaker() in submit_contribution()). For AI agents, Filibuster is the right choice on CPU Ollama — no deadline pressure while the model generates for 90 seconds.

The trickiest engineering problem was the dedup lock. Agents run in daemon threads spawned from enqueue_agent_task(). Without a per-slot Redis lock (agent_lock:{debate_id}:{goal_id}:{phase}), a watchdog tick and a late-arriving Filibuster trigger would both enqueue tasks for the same slot and double-submit. The lock is acquired before spawning, released in the finally block. Every LLM failure has a MAX_RETRIES=3 inner loop and MAX_TOTAL_ATTEMPTS=9 across re-enqueues before escalating to the organiser via push + email. Nothing fails silently.

Hey everyone, following up on my original post (https://notatask.com) about NotaTask (simple task + note management app). Thanks for all the feedback last time — here's what changed:

UI got a full rewrite. The old UI was Bootstrap and, frankly, kind of shitty. It's now completely rebuilt on Tailwind CSS with a proper dark theme. Several of you said the old UI felt complicated/cluttered — this was the direct fix for that.

Android app is live. There was no mobile app before — it's completely new, built with Flutter, and talks to the same backend. You can grab it here: https://play.google.com/store/apps/details?id=com.notatask.app&hl=en

iOS — PWA for now. No native iOS app yet (no paid Apple dev account), but the web app is now fully responsive, so it works well as a PWA / installed home-screen app on iPhone in the meantime.

Web is responsive too. If you're not on Android, the site itself now works properly on mobile browsers as well.

Behind the scenes: added automated daily database backups, so things are more production-safe than before.

Still just me building this on the side around a full-time job, but slowly chipping away at the feedback from last time. Let me know what you think of the new UI, and if the Android app breaks on you, happy to fix it.

https://notatask.com

After 18 months solo, I shipped Sijal — the core of Fasil, an Arabic structured debate platform where every argument gets AI-scored in real time and every audience vote carries a cryptographic hash.

Stack: Django 4.x + Channels (WebSockets for live phase turn notifications), PostgreSQL, Redis, Auth0, Azure Blob, Stripe. The debate has 3 goals, each running through 6 ordered phases — opening, counter-argument, rebuttal, counter-rebuttal, questions, answers. One designated speaker per phase, enforced by a PHASE_SPEAKER_RULES map at the application layer.

Two modes: TimeLocked (a watchdog daemon polls every N seconds against Timeline records, computes wall-clock windows, and enqueues agent tasks when a phase is open and unfilled) and Filibuster (phases advance the moment a contribution is submitted — zero polling needed, the chain fires from _notify_next_speaker() in submit_contribution()). For AI agents, Filibuster is the right choice on CPU Ollama — no deadline pressure while the model generates for 90 seconds.

The trickiest engineering problem was the dedup lock. Agents run in daemon threads spawned from enqueue_agent_task(). Without a per-slot Redis lock (agent_lock:{debate_id}:{goal_id}:{phase}), a watchdog tick and a late-arriving Filibuster trigger would both enqueue tasks for the same slot and double-submit. The lock is acquired before spawning, released in the finally block. Every LLM failure has a MAX_RETRIES=3 inner loop and MAX_TOTAL_ATTEMPTS=9 across re-enqueues before escalating to the organiser via push + email. Nothing fails silently.

I added license plate recognition from security cameras to my Django CRM — here's how it works

Part 1 | Part 2 — production CRM for a truck service center, built with Django + DRF.

So the service center already had security cameras at gate. One day the owner goes: "hey can we make the system know when a client's truck arrives?" He wasn't asking for some fancy AI thing — just, camera sees a plate, system tells us who pulled in and if they have an appointment booked.

I thought it will be a massive project. It really wasn't.

How ALPR talks to Django

Camera side runs a separate ALPR script that handles the actual recognition part (not my code, there's plenty of off-the-shelf stuff for this). I just needed Django to receive the result and do something smart with it.

The whole thing is one POST endpoint:

@api_view(['POST'])
@permission_classes([AlprApiKeyPermission])
def alpr_event(request):
    serializer = AlprEventInputSerializer(data=request.data)
    serializer.is_valid(raise_exception=True)

    plate = normalize_plate(
        serializer.validated_data['license_plate']
    )
    camera_id = serializer.validated_data.get('camera_id', '')
    confidence = serializer.validated_data.get('confidence')

Camera script just sends something like {"license_plate": "AA1234BB", "camera_id": "gate-1", "confidence": 94.5} with an API key in X-ALPR-Key header. I wrote a tiny custom permission class that checks it against env var. Nothing fancy but keeps random requests out.

The ignore list — built this before anything else

Ok so here's the thing nobody tells you about vehicle recognition systems. Before you write any matching logic, you need to deal with the noise. The service center shares parking area with other businesses, so there's staff cars, parts delivery vans, neighbors just driving through all day long. Without filtering, the staff Telegram chat was getting like 50 "VEHICLE ARRIVED" pings a day. Completely useless.

class IgnoredVehicle(models.Model):
    REASON_CHOICES = [
        ('staff', 'Staff'),
        ('delivery', 'Parts delivery'),
        ('neighbor', 'Neighboring business'),
        ('other', 'Other'),
    ]
    license_plate = models.CharField(max_length=20, unique=True)
    reason_type = models.CharField(max_length=20, choices=REASON_CHOICES)
    description = models.CharField(max_length=255, blank=True)
    is_active = models.BooleanField(default=True)

Plates get normalized on save (uppercase, spaces stripped). And here's the thing — ignored vehicles still get logged, they just don't trigger notifications. I added this after the owner asked why the delivery guy was showing up in the log 4 times a day. Because he was. And it was drowning out actual clients.

The matching pipeline

Ok so plate comes in, it's not on the ignore list. Now our system does three things:

1. Find the truck and client. Just match plate against the Truck table. If it hits, you get the client for free through the foreign key. Easy.

2. Check today's appointments. This is where it gets actually useful. Quick note — today here is timezone.localdate(), not datetime.date.today(). Learned that one the hard way when test server was in UTC and "today" didn't match local appointments:

today = timezone.localdate()
appointment = (
    Appointment.objects
    .filter(
        license_plate=plate,
        scheduled_dt__date=today
    )
    .exclude(status__in=[
        'cancelled', 'completed', 'no_show'
    ])
    .order_by('scheduled_dt')
    .first()
)

3. Ping the staff. Telegram message goes to staff group chat — client name, phone number, truck model, whether they have appointment or not. Unknown plate? Message says that in chat too. The mechanic on duty sees it before the driver even gets out of the cabin.

How appointments feed into this

ALPR on its own would be kinda meh without the appointments app I built in previous version. The flow goes like this:

• Client calls or texts, gets a pending appointment
• Staff confirms, post_save signal fires, Telegram confirmation goes out
• Day before — Celery task sends reminder
• Truck shows up at the gate — ALPR matches the plate, closes the loop

One thing that bit me early: you gotta track whether the status actually changed, not just what it is now. Otherwise you end up spamming the client every time someone edits the appointment description or fixes a typo. I override __init__ to stash the original status:

class Appointment(models.Model):
    # ... fields ...

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._original_status = self.status

Then post_save just compares instance.status vs instance._original_status. Zero extra DB queries. My first attempt used a pre_save signal that did a .get() to fetch the old value from DB every time, which... yeah, don't do that if you're ever updating records in a loop.

Stuff that surprised me

The ignore list matters way more than the smart matching. I spent most of my time on the fun parts — truck lookup, appointment matching, formatting Telegram messages just right. But day to day? 80% of the real work is maintaining that ignore list. New delivery company shows up? Add their van. Staff member buys new car? Update plate. Boring but essential.

False positives kill trust faster than anything. Missing an arrival is fine — driver walks in, says hello, life goes on. But sending "CLIENT ARRIVED" for some random delivery van? Staff stops checking the notifications within a week. The confidence score from ALPR helps a bit, but the ignore list does the real work here.

The appointment thing actually changed how they operate. Before, mechanic would check paper list taped to the wall when truck pulled in. Now his phone buzzes with client name, appointment type, scheduled time — truck is still parking. It is a small thing, but the owner said it made the shop feel like a "real operation".

Why I made certain choices

API key instead of JWT for the ALPR endpoint. It is a camera script talking to Django, not a human. Static key in env var, done. No token refresh dance, no expiration headaches.

Logging ignored arrivals anyway. Owner wanted to know total vehicle count per day for insurance. Two extra lines of code and I saved myself from a future feature request. Always log everything, filter later.

Telegram over dashboard widgets for mechanic notifications. These guys are literally under trucks, not sitting at monitors. Phone buzzes, quick glance, back to work. Anything more complicated and they just won't use it.

What's next

Part 4 — TruckMaster goes modular. I built a feature flag system, so the owner can flip entire modules on and off (ALPR, appointments, invoices) from the admin panel. Plus Nova Poshta integration for tracking spare parts deliveries. That one has its own set of fun problems.

Previous posts: Part 1 | Part 2 GitHub (demo repo): github.com/VNmagistr/truckmaster_demo — branches demo/v2.1 and demo/v2.2

Been building django-orm-lens for the past couple weeks and it's at a spot where I'd love Django-people's eyes on it.

What it does

Three surfaces, one static parser (ast module — no Django import, no DB, no credentials):

1. VS Code extension — sidebar tree with apps/models/fields/Meta, interactive React Flow ER diagram, hover cards on FK/O2O/M2M
2. Python CLI — pip install django-orm-lens — pipe-friendly JSON output for shells and CI
3. MCP server — 9 read-only tools for Cursor / Claude Desktop / Aider (find_relations, cascade_preview, suggest_indexes, signal_graph, describe_migration_dependency, etc.)

Regression-tested against 63 real models from Zulip, Saleor, Wagtail, and django-CMS — not synthetic examples.

Why static-only

You can point it at any Django project without setup:

• No DJANGO_SETTINGS_MODULE
• No installed dependencies except our parser
• Runs in CI or on the plane

Trade-off: things that require runtime (custom get_queryset overrides, dynamic model classes) are invisible. But 95% of what you actually want to see is in models.py and signals.py — that's parseable.

What I'd love

• Screenshots of what breaks on your codebase — the 8 open good-first-issues cover known edges but your codebase probably has an edge case I haven't seen
• Feedback on which MCP tools would be most useful for AI coding agents — I'm about to add detect_n_plus_one and migration_risk_report in v0.6, want to prioritize based on what devs actually pain-point on
• Contributions welcome — MIT, translations (RU/ZH/ES issues open) count as first-class contributions via the all-contributors bot

Not selling anything, no plans to monetize while it's small — just want it to be genuinely useful for the Django community.

Fire away.

Hi everyone,

I'm a beginner Django developer, and I recently finished my first full-stack project called Luna Books, an online book shopping application.

The project is working well overall, but I'm stuck on one deployment issue that I haven't been able to solve.

Everything works correctly on my local machine, including product image uploads and display. However, after deploying to Render, all of my product images are missing. The rest of the application works as expected, including the PostgreSQL database connection.

Current situation

Local development

• Product images display correctly.
• Image uploads work normally.

Live deployment (Render)

• Website loads correctly.
• Products are loaded from the PostgreSQL database.
• Product images don't display.
• ❌ Image URLs return 404 Not Found.

For example:

/media/book_images/Ikigai-frond.jpg

After deploying the project, I noticed that product images were missing only in the live version. I first checked my Django code, media settings, and deployment configuration but couldn't find the cause.

As part of my troubleshooting, I then configured Cloudinary for media storage. The images appeared briefly on the live site, but after another deployment they disappeared again.

So far I've tried:

• Checking my media and Cloudinary settings.
• Adding the required Cloudinary environment variables.
• Re-uploading the images.
• Redeploying the application.
• Verifying that the database still contains the correct image paths.

My project uses:

• Django 6.0
• Python 3.13
• Render
• PostgreSQL
• Cloudinary
• WhiteNoise (for static files)

At this point, I'm not sure whether the issue is related to my Cloudinary configuration, my Django media setup, or something specific to Render.

Has anyone experienced something similar or have suggestions on what I should check next?

I've attached a screenshot showing the issue on the deployed version. If any additional information or relevant code would help, I'm happy to share it.

Thanks in advance for any guidance!

Hi everyone,

I'm a beginner Django developer, and I recently finished my first full-stack project called Luna Books, an online book shopping application.

I recently resolved a deployment issue with product images thanks to this community, and now I'm trying to solve my last remaining deployment issue.

Everything works correctly on my local machine, including the Forgot Password feature. However, after deploying the project to Render, the password reset process no longer works.

Current situation

Local development

• Forgot Password works correctly.
• Password reset email is sent successfully.
• The complete password reset flow works.

Live deployment (Render)

• Website loads correctly.
• Clicking Forgot Password opens the password reset page.
• After entering an email address and submitting the form, the page shows "Loading..." for a while.
• It then returns an Internal Server Error (HTTP 500).
• ❌ No password reset email is received.

My project uses

• Django 6.0
• Python 3.13
• Render
• PostgreSQL
• Gmail SMTP
• WhiteNoise
• Cloudinary

At this point, I'm not sure whether the issue is related to my Gmail SMTP configuration, Render environment variables, or something else in the deployment.

Has anyone experienced something similar or have suggestions on what I should check next?

If any additional information, Render logs, or relevant code would help, I'd be happy to share it.

Thanks in advance for any guidance!

Recently discovered an interesting tool called django-browser-reload. Maybe it’ll be useful to someone else too.

It lets you avoid refreshing the browser page manually after every code change. There is only one downside, in my opinion, which can be a bit annoying sometimes, especially when you are already used to automatic reload - it only works on the last opened tab. However, I still haven’t come across any better alternatives yet.

Setup is very simple:

uv add --group dev django-browser-reload

INSTALLED_APPS = [
    "django_browser_reload",
]

MIDDLEWARE = [
    "django_browser_reload.middleware.BrowserReloadMiddleware",
]

I would be grateful if you share similar libraries that make your django development easier and more pleasant. But only the ones you actually use, so you can share your real experience.

Over the years I’ve gradually started introducing a service layer into my Django applications.

I found that as projects grew, business logic would often end up spread across views and models. Views became bloated, rules were harder to reuse, and it was not always obvious where a particular piece of logic belonged.

My current approach is to have a reusable base service, with model-specific services extending it. Views interact with the service rather than accessing Model.objects directly, while the models remain focused primarily on the data itself.

A simplified version looks something like this:

```
from typing import Generic, TypeVar

T = TypeVar("T")

class BaseService(Generic[T]):
model: type[T]

def __init__(self, user=None):
self.user = user

def get_queryset(self):
return self.model.objects.all()

def list(self, **filters):
return self.get_queryset().filter(**filters)

def create(self, **fields):
instance = self.model(**fields)
instance.created_by = self.user
instance.full_clean()
instance.save()
return instance

def update(self, instance, **fields):
for name, value in fields.items():
setattr(instance, name, value)

instance.updated_by = self.user
instance.full_clean()
instance.save()
return instance
```

A model-specific service can then handle its own rules and queries:

```
class ProjectService(BaseService[Project]):
model = Project

def get_queryset(self):
return super().get_queryset().filter(created_by=self.user)

def create_project(self, payload):
return self.create(**payload.as_dict())
```

The view is then kept fairly lightweight:

```
@login_required
def project_create(request):
form = ProjectForm(request.POST)

if form.is_valid():
service = ProjectService(request.user)
service.create_project(ProjectPayload(**form.cleaned_data))

return render(request, "project_form.html", {"form": form})
```

This has worked well for keeping business rules in one place, particularly when the same logic is used across standard views, HTMX endpoints, management commands or APIs.

I’m still refining the approach, and I’m curious how other people structure this.

Do you use a service layer in Django, keep the logic on models, use standalone functions, or follow another pattern entirely?

Hello guys, i think i want to start my own software company and i want to see some real examples of projects because i want to start building some projects and start offering them on local businesses

Thanks

Hi everyone!

Over the past few months, I built SmartStock AI as my graduation project during the ITI Full Stack Web & Generative AI Program.

The idea was to create an inventory management system that does more than just track stock. It uses AI to help businesses make smarter inventory decisions.

Some of the features include:

• AI-powered demand forecasting
• Multi-agent purchasing recommendations
• Hybrid RAG with source citations
• Multimodal invoice processing
• Real-time inventory alerts

Tech Stack

• Django 5 + DRF
• React 19
• PostgreSQL + pgvector
• LangChain
• Celery & Redis
• Prophet
• Docker

🎥 Demo:
https://www.youtube.com/watch?v=DQJqs6bgE98

🌐 Live Demo:
https://smart-stock-dev.vercel.app/

💻 GitHub:
https://github.com/Eng-Ayman-Mohamed/SmartStock-AI

Demo account:
Email: [[email protected]](mailto:[email protected])
Password: Viewer123!

I'm still improving the project, so I'd really appreciate any feedback—whether it's about the architecture, UI/UX, AI features, or anything else. Thanks!

I like Django and I always choose it for my indie projects. However, at work, from project to project, I constantly have the FastAPI + React stack, even where django could actually be used.

Recently I started thinking, is it really worth spending time on django, keeping track of updates, testing different libraries, etc? Yes, it is clear that ai can say a lot about this, but I would like to read examples from real developers. Where do you actually use django, preferably in enterprise?

If you're building a web application today, chances are you aren't writing your own authentication system. Managed identity providers like Clerk, Auth0, and Kinde have become the default choice, offering out-of-the-box support for passkeys, multi-factor authentication, and enterprise SSO. That convenience introduces a distributed-systems problem, though: data synchronization. When a user creates an account on a managed auth provider, that system has to notify your primary application database so you can create a matching user record. Please read the complete article here - https://instawebhook.com/blog/bulletproofing-user-sync-handling-clerk-and-auth0-webhook-failures

This happens through webhooks. But what happens if your server is down, your serverless function cold-starts and times out, or your database is momentarily locked when that webhook arrives? A user successfully signs up with your auth provider, but your application has no idea they exist. That breaks the very first login experience, and it's how phantom accounts, broken onboarding flows, and frustrated users happen.

This guide walks through the anatomy of webhook-driven auth architecture, current Auth0 and Clerk webhook practices, and how a resilience layer — using InstaWebhook as a worked example — closes the gap that idempotency and signature verification alone can't.

Really had enough of PA servers being down like every other day, and their same excuse for past 2 years.

DigitalOcean is an option, but was wondering if there is something a bit simpler to quickly transfer over to?

Some of you might remember djapy. Typed Django API framework, pydantic validation, swagger, no serializers, no viewsets, no routers. I built it two years ago, posted it here a few times, and then basically disappeared. Prolly, the issues sat for a year. I lost the djapy.io domain because I couldn't justify the renewal cost. The package was pinned to Django <5.2 so it wouldn't even install next to current Django.

A couple weeks ago I finally sat down and cleaned it up:

• went through every open issue, verified each against the code, closed the stale ones
• fixed a bug where a validation error with a non serializable input returned a 500 instead of a 400
• docs are back at djapy-docs.pages.dev
• wrote a test suite, 123 tests, it had none before, I know
• CI across Python 3.10 to 3.14 and Django 4.2 to 6.0
• releases auto publish now, so PyPI can't silently go stale again

The whole idea of djapy is that a view stays a plain Django function in a plain urls.py:

from djapy import djapify, Schema

class PostSchema(Schema):
    title: str
    body: str

@djapify
def create_post(request, data: PostSchema) -> {201: PostSchema}:
    post = Post.objects.create(**data.model_dump())
    return 201, post

Query params, JSON body and form data all validate through pydantic v2. Status codes are part of the return annotation. Django's own decorators like cache_page work on top without adapters. Need async, use async_djapify.

Someone asked here in 2024 how djapy compares to django ninja and nobody answered, me included. So:

Django Ninja:

api = NinjaAPI()

@api.post("/posts", response={201: PostSchema})
def create_post(request, data: PostIn):
    post = Post.objects.create(**data.dict())
    return 201, post

# urls.py
path("api/", api.urls)

djapy:

@djapify
def create_post(request, data: PostSchema) -> {201: PostSchema}:
    post = Post.objects.create(**data.model_dump())
    return 201, post

# urls.py
path("posts/", create_post)

ninja gives you an API object and routers. djapy gives you a decorator and gets out of the way. ninja is more mature and has a much bigger community, if you're happy with it, stay there. djapy does less, on purpose.

Repo: https://github.com/Bishwas-py/djapy

Docs: https://djapy-docs.pages.dev/

Next on the roadmap is streaming/SSE support, there's an open issue with a proposed design if anyone wants to weigh in. If you try it and something breaks, tell me where. Slow issue responses are what killed it last time, not planning to repeat that.

We have a Django-based microservices application that uses JWT for authentication. To avoid calling the Customer Service on every request, our JWT access token contains user metadata such as customerId, username, email, and phoneNumber.

When a user updates their profile (e.g., changes their email or phone number) from one session, we immediately issue a new JWT containing the updated information for that session. However, all of the user's other active sessions continue using their existing JWTs, which now contain stale data until those tokens expire.

Reducing the access token expiry (e.g., to 15 minutes) only reduces the duration of the inconsistency—it doesn't eliminate it. Since JWTs are stateless, we also can't invalidate or update all of the user's existing tokens without introducing server-side state.

What is the recommended approach to handle this scenario in a microservices architecture?

Hi guys, so i just read this cool case study from Beetroot about an industrial software project they did for a green energy company. The client’s manufacturing process was already in full swing, but they were effectively operating blindfolded. They lacked a centralized digital infrastructure to track heavy equipment components, validate real-time production processes, or run deep data analytics.

The developers built a production data system completely from scratch using Python and Django. Its primary function is to store, organize, and validate certifications for all raw materials used across the manufacturing floor to maintain absolute quality compliance.

To automate the operational overhead, they embedded a custom AI motor that scans, identifies, and traces complex industrial documentation, linking those files directly to specific production cycles automatically. It completely eliminated human indexing errors and cut down compliance tracking times drastically. It’s a great example of how old-school heavy manufacturing setups can modernize their compliance framework without stopping their assembly lines.

What strategies do you use to migrate data and deploy updates without causing physical downtime on the assembly floor?

I'm just starting my backend development journey with Python, mainly Django (and maybe FastAPI later).

Right now I'm working on a Django project, and honestly I've only been using models and the ORM. I haven't had to write any raw SQL queries because the ORM handles everything I need.

I do have a basic understanding of SQL, but I'm curious about how important raw SQL is in real-world backend development. In the future, will there be situations where knowing raw SQL well becomes necessary? Or is a solid understanding of the ORM enough for most projects?

I'd love to hear from developers who have worked with Django or FastAPI in production.

Everyone learns the standard ORM queries, basic class-based views, and how to map URLs early on. But Django is huge, and there are so many built-in utilities buried in the docs that completely eliminate the need for third-party packages or complex custom code.

For example, when I finally discovered F() expressions, it blew my mind. Being able to update a database field based on its current value directly in the DB (like F('shares') + 1) without pulling the object into memory and risking race conditions felt amazing.

Another one is utilizing select_related and prefetch_related to instantly drop an app from 150 database queries down to 2.

What’s that one underrated Django feature, decorator, field option, or management utility you stumbled upon that made you think, "Why wasn't I using this the whole time?"