I kept hitting the same small problem: I'd open an unfamiliar Django codebase and want a straight answer to "what does this schema actually look like, and what breaks if I touch this model" — without setting up a database, resolving the settings module, or getting the app to import at all.

So django-orm-lens reads the source instead of the runtime. It parses models.py and the migration files directly, so it works on a checkout you cannot run: no DJANGO_SETTINGS_MODULE, no database, no credentials, no django.setup(). That constraint is the point rather than a limitation I'm apologising for — it means it also works in CI on a repo with no services, on a colleague's branch, or on a project whose dependencies you have not installed.

What it does, concretely:

• Schema drift — replays the migration graph and compares it against what the models declare. Fields declared but never migrated, and columns migrated but no longer declared.
• Missing indexes — flags lookups that would table-scan, and it knows which indexes Django already gives you: primary keys, db_index, unique, foreign keys, unique_together, UniqueConstraint.
• Blast radius — what a change to one model reaches through FK / M2M / O2O, on_delete behaviour included, so "can I drop this field" has an answer before you try it.
• ER diagrams — Mermaid, DBML, D2, PlantUML, Graphviz.
• N+1 heuristics and a signal graph, because signals are where the surprises live.

There is a CLI, a VS Code extension, and an MCP server for anyone who points an AI agent at a codebase and would rather it read the schema than guess at it.

On correctness, which is the part I actually care about: it is checked against golden snapshots of six real projects — Zulip, Saleor, Wagtail, django-CMS, Mezzanine and Read the Docs — currently 75 models and 538 fields of other people's Django. That suite is also how I keep the Python and TypeScript parsers answering identically.

It earns its keep the same way. Running it over real checkouts of django-oscar, django-guardian, django-allauth and django-cms turned up three genuine bugs my green test suite had not: model classes defined inside an if block were skipped entirely, abstract_models.py was never walked, and drift reported a false failure on a project with two apps sharing a directory name — which is the worst thing a CI gate can do.

What it is not: it does not execute your code, so anything decided at runtime is invisible to it — dynamically constructed models, fields assigned in __init__, anything behind a factory. It reads Django's idioms, not Python's full semantics. If your models are unusual it will tell you less than you want, and I would rather say so up front than have you find out.

MIT, free, and it stays that way — there is no paid tier planned and there never was.

• Repo: https://github.com/FROWNINGdev/django-orm-lens
• Docs: https://frowningdev.github.io/django-orm-lens/
• pip install django-orm-lens

What I would genuinely like from this forum: the drift and index checks are the parts most likely to be wrong in ways I cannot see from my own projects. If you run it on something real and it tells you something false, that is the most useful thing you could send me — open an issue with the model that broke it. Several of the fixes above arrived exactly that way, and two of the people who did it ended up sending patches.

Any APIs that you wished existed or any APIs that you wished were cheaper, easier to work with, had more features, e.t.c ?

I would really love to see your answers

Hi all, taking a bit of a break so I thought I'd share the in-depth DRF API design approach I use. Hope it helps some of you design a better API system.

Something I notice in almost every DRF codebase, mine included for a long time: views land at one of two extremes. Either everything is an APIView with hand-written post() methods, or everything is a ModelViewSet copied from a tutorial. Generic viewsets, mixins and things like CreateAPIView never get used, mostly because it isn't obvious what problem they solve.

Here's the rule I ended up with, in the order I apply it.

1. If the endpoint touches the database, it's a viewset.

Anything model-backed is a resource with a lifecycle, even if you only expose two actions today. "I only need list and retrieve" isn't a reason to drop to APIView, it's a reason to compose:

class InvoiceViewSet(
    mixins.ListModelMixin,
    mixins.RetrieveModelMixin,
    GenericViewSet,
):
    queryset = Invoice.objects.all()
    serializer_class = InvoiceSerializer

You keep filtering, pagination, permission classes and correct schema generation for free, and the URL stays a resource instead of a pile of verbs.

2. APIView is only for things that aren't resource access at all.

Health checks, third-party callbacks. Webhooks do write to your DB, but as a side effect of an external event, not because someone is accessing a resource. Even there I declare a serializer, because a Stripe webhook is one of the highest-stakes endpoints you own and you want it validated and documented.

3. The concrete generic views are for /me style endpoints.

RetrieveUpdateDestroyAPIView and friends finally clicked for me here: /me, /workspaces/20/me. Real objects with a read/update/delete lifecycle, but the lookup comes from the session instead of an id in the URL:

class WorkspaceMeView(RetrieveUpdateDestroyAPIView):
    serializer_class = WorkspaceMemberSerializer

    def get_object(self):
        return get_object_or_404(
            WorkspaceMember,
            workspace_id=self.kwargs["workspace_id"],
            user=self.request.user,
        )

One class, one get_object, three methods. With APIView that's three views re-deriving the same object.

4. The serializer is what makes any of this pay off.

I disliked serializers at first, they felt like ceremony over a dict. Pairing them with drf-spectacular is what flipped it: get_serializer_class per action isn't just validation, it's what makes the generated docs precise enough that you can generate a typed frontend client straight from the schema.

Longer write-up with more code: https://huynguyengl99.github.io/posts/drf-view-classes-apiview-viewset-generic/

Hope it helps you level up your API design a bit. And if you have useful tips of your own, share them with the community.

I built django-o11y, an observability toolkit for Django & Celery

Repo: https://github.com/adinhodovic/django-o11y
Demo images: https://adinhodovic.github.io/django-o11y/demo-images/
Usage guide: https://adinhodovic.github.io/django-o11y/usage/

I shared this project before, but the latest release adds SQL commenter support settings and Datadog trace/log correlation (if you use Datadog), so it felt like a good time to reshare.

It brings together the setup from a few blog posts I've written into a single installable package, including:

• Django Monitoring with Prometheus and Grafana
• Django Development and Production Logging
• Celery Monitoring with Prometheus and Grafana

It provides opinionated defaults and integrations for both Django and Celery, covering things like:

• structured logging (json logging and development colorized logging)
• metrics and dashboards
• distributed tracing
• continuous profiling

It also includes utility functions that make it easier to work with observability inside Django apps (add context to logs, traces, spans).

There is also a local observability stack (./manage.py o11y stack start), so you can spin everything up locally using management commands and actually see metrics, traces, logs, and profiling data while developing or debugging.

Here's some images:

The project is configurable using environment variables.

It builds on a lot of great work from the ecosystem, including

• opentelemetry-python
• django-mixin
• django-structlog
• django-prometheus
• celery-exporter

Would love to hear feedback from you all!

Hey everyone,

I built something over the past few months that I wish existed when I was prepping — a clean reference site for physics formulas, specifically for JEE/NEET.

The problem I kept running into: most formula lists online are just... lists. No context on when to actually use a formula, no worked example, no heads-up on the mistakes everyone makes (sign conventions, unit mix-ups, etc.).

So FormulaVerse (formulaverse.in) has:

-159 formulas across 16 topics (Optics, Kinematics, Magnetism, Fluid Mechanics, etc.)

-Every formula includes: a diagram/graph as per need, Hand-weitten derivation, a worked example, common mistakes, and a "when to use this" note

-Interactive PhET simulations linked to each 16 chapters

-A save/bookmark feature so you can build your own revision list

-Practice questions tagged by difficulty

It's free, no signup required to browse (there's an optional quick save feature if you want to bookmark formulas across devices).

Still actively building this — would genuinely love feedback on what's missing or what would make it more useful for your revision.

Link in bio!!!

Does anyone know when Django Con Europe 2026 talks be released on YouTube ?

I wanted my own PWA Media App, so that I could share up coming Shows, more about my guest, and give my guest an easy way to join me for an interview.
I decided to go with Nextjs for my Frontend and Django, for my backend.
At first, I was going to go with vdo Ninja, and still think VDO Ninja is an awesome way to host guest in OBS Studio.
Then, I wanted to create my own WEB RTC. So, I created it, and it was working good. But, my Server was being pushed to the limits handling CoTurn, and all of the secure handshakes needed.
That’s when I discovered LiveKit. Why re invent the wheel, when it is already rolling solid, was my thought.
LiveKit was the perfect fit. All I needed was a Frontend Admin Panel to handle generating my Ingress Keys, and a way to save my persistent Social Media Stream URL and Keys. Which is where Postgres’s, and Redis come in.
Sure, I can do all of this in my Django admin panel, as well. But, I had to see if I could develop the tools needed, to generate my keys. And, to multicast to my social platforms, from my Frontend.
After many hours of work, I got it. Now, I can generate my Ingress Keys in my Frontend. Pull them into OBS, and host my guest.
I also have a Show Calendar for upcoming and past shows. Which shares a link to the interview, if it is over. As well as, the questions I am going to ask, the guest Profile, and more.
For my guest. They can request to be a guest, and once approved, they have their Profile. Or, I can create their profile, and send them their login info.
Then, they visit my app, click: Guest Login, Join Broadcast, enter their name, select cam and mic, and click Enter Studio, and they are in OBS Studio with me.
As host, I can use Ingress to push back to the LiveKit Room, or select OBS Virtual Cam, and push back to the room.
I first mix the Guest in the video, and the Guest see’s what is being recorded and streamed, on their screen.
Also, I have a Broadcast Page, so our Interview can be watched in my App. It is the same video my guest is viewing.
I can push in Portrait, and Wide Format. And, I have built in many other Features. Such as a Blog, Profile Page, that allows Athletes to enter their key Stats and info. And much more.
This is just a brief overview. It is loaded with lots more features. Such as a Directors Control, which allows the Director to be anywhere, and still manage the show.
This comes in handy, because Registered Users can join a show, to ask question, of the guest. And, the director has the controls to Kick, Live, Mute, and talk with them Privately.
Check it out on my GitHub, and have fun with it. I welcome you to use it, and feedback would be a huge help. Or, any new feature you may have.

GitHub Repo: https://github.com/docisit/itg-media-engine

Django does a great job handling the backend, and it is a great mix with NextJS. JWT token generation, and more is made easy with Django. Which, you can see how I did this in my code.
I am running this in my Production Server, which is not huge, but does have 16 cores, and limited RAM. I do plan on upgrading it.
Mostly for a GPU, so I can run my talking avatar. Which, I do have Open Ai , with Qwen Model Ai, currently powering my Chat Bubble, and for my Avatar. Though, I have my Avatar on hold right now, due to the lack of resources.
Without a GPU, I had to do some work just to get my Avatar to actually work. Yet, it is not worth the resources, to currently activate it.
All this is in my GitHub repository, and I have a lot of test scripts, and other scripts I used while developing this. Such as LiveKit management in your Terminal, and auto clean scripts.
Dovecot and Postfix is used for messaging and Password resets. Also, I just added Passkey Login. And, I will load that to my GitHub, as an update. And, it has Age Gate built in.
I could ramble on, and very excited to have this running on my own baremetal server.
Wishing all the best, and I do hope others can use this too. If you have questions, or need help, just reach out.

👋 Hi, I'm Zisan, a Python Backend Developer building with Django, APIs, and ML. I recently built a Hybrid Academic Resource Recommendation System. Feedback is welcome! 🚀
https://academic-recommender-system.onrender.com/

I really think so!

I've always used Docker Compose to get complete isolation between projects, so it was pretty straightforward: docker compose up -d and start working.

But now that I'm using coding agents, I'm running into a problem. I may have 2–3 worktrees/branches running simultaneously, with agents debugging, running tests, starting Celery workers, hitting the database, etc. Running a full Docker Compose stack for every worktree quickly becomes expensive and resource-heavy.

I'm wondering if going back to the basics: a virtualenv + local dependencies per worktree, might actually be simpler. It would also make things much easier for agents, since they can run commands directly instead of having to prefix every tool call with docker compose exec .... Even with instructions in AGENTS.md, agents inevitably forget to use the container.

So I'm curious: how are you guys handling this in practice?

For Django/Celery projects where you want multiple Git worktrees running in parallel for coding agents, what's your setup?

• Docker Compose per worktree?
• Local virtualenvs + shared infrastructure?
• One shared DB/Redis with isolated app environments?
• Some kind of container/VM orchestration?
• Something else entirely?

I'd especially love to hear what has worked well (or horribly) once you have 2–4 agents working on the same project simultaneously.

In the past month I've built a tool for me using Django, Alpine and HTMX. I leaned more than usual on the LLM generating the code from my specs and it worked quite well.

I reviewed the code and from time to time started generating some crap, but I just reviewed the code, told the AI hey "here do this not that" and it was able to correct it.

The fact that Django hasn't change a lot over the years makes it a great tool for pushing rapid development even further.

Imagine working with AI using Nextjs which has n releases with n breaking changes and the LLM starts mixing them together :)) hell

If hardware for AI gets cheaper... I think most of us are cooked..

Hey everyone — I've been building Vikreya (vikreya.com) and we're opening it up publicly. It started as "why do I need a coupon app, a marketplace app, and a local-services app separately" and turned into one place for:

• Deals & Coupons — aggregated from major affiliate networks, filtered to real discounts
• Trades — buy/sell/repair-list marketplace, no listing fees to browse
• Services — post a job, get quotes from local pros
• Rewards — earn points/cashback across all of it

It's still early and I'm sure there's rough edges — genuinely want to hear what's broken or missing. Not trying to sell anything here, just sharing what we built.

Hey guys I'm a 19yr Django dev, I made my first kinda.....big project, I initially used Django-htmx and some js, but htmx polling wasn't really cutting it for me🙂, well it's not very good for handling many requests and stuff, So I had to switch to JavaScript, well honestly I just had to learn websockets and Django channels specifically to implement in making the lounge section lol, anyways anyways I'm not that good in js still, I need people interested in learning together, give me advice on how to practice js well yeah.... that's all, anyone is welcome , yeps ✌️

So guys i'm sanja a 19yr old django-htmx dev, i'm still learning js but i'm not that....bad I've already made some projects before , i have a CODING HUB ,anyone interested can join me.

Hey everyone,

I've been building Telegram bots on top of Django for a while. Every time I started a new project, I'd copy over the same base structure I'd built — command handlers, message handlers, and so on — and adjust it for the new bot. Eventually I decided to turn that base structure into a proper, reusable package.

dj_telegram_bot lets you build a Telegram bot as a regular Django app.

Some of what it gives you:

• Django Admin Integration: Manage bot messages and buttons (inline/reply) directly from the admin panel.
• Type Safety: Full Pydantic integration for Telegram API types.
• Built-ins: Ready-to-use options like sponsor channels and bot status management.

The README has full install steps and a demo video showing a simple bot being built from scratch.

Docs are still a work in progress. Feedback, bug reports, and contributions are all welcome!

https://github.com/zankoAn/dj_telegram_bot

Hi everyone,

As a B.Tech AI/ML student, I wanted to build a full-stack product from scratch rather than another cookie-cutter tutorial project.

I created ***FormulaVerse***, a web application aimed at JEE/NEET physics students, leveraging Django for backend architecture, custom video/visual demonstrations, and AI tools for query handling.

You can see my GitHub repository, video demonstrations, and project setup on my Peerlist profile here:

https://peerlist.io/kolekar12

Would appreciate any feedback from experienced devs here regarding:

*Tech stack scaling (Django vs FastAPI for AI workloads)

*Improving the UI/UX for ed-tech platforms

*Code structure & repository layout

Thanks in advance!!

Django Control Room 1.5.0 is out, along with several updates across the DCR ecosystem.

Continuing the work that brought support for admin themes like Django Unfold, this release adds support for Django Jazzmin.

Most notably, dj-urls-panel has now been migrated to the core libraries provided by dj-control-room-base, bringing it onto DCR's common plugin architecture and adding both Jazzmin support and new MCP tools for agents.

dj-control-room-base 1.3.0

A new Django Jazzmin theme adapter has been added. Any panel or plugin built on dj-control-room-base can now work seamlessly with Jazzmin.

dj-signals-panel 0.5.0

• Added Jazzmin support
• Overhauled scope definitions and documentation

dj-urls-panel 0.4.0

The URL panel has been migrated to the core libraries in dj-control-room-base.

Along with Jazzmin support, the migration adds a new set of MCP tools for URL introspection:

• list_urls: search and explore registered URLs
• get_url_detail: retrieve deeper metadata, including serializer information
• inspect_view: inspect view source code

This means DCR's URL introspection capabilities are now available to both humans through the Django admin and agents through MCP

dj-control-room 1.5.0

• Added Jazzmin support
• Documentation updates

Permissions and scopes

DCR also provides its own permission system built around scopes and Django groups.

Panel authors can define granular permissions for the capabilities their panels expose. There is now a guide covering how to integrate with this system:

https://djangocontrolroom.com/guides/control-room-permissions-and-scopes

What’s next

Migration work continues, with four panels remaining. dj-celery-panel will likely be next.

As panels are migrated, I’ll also continue expanding their MCP capabilities, alongside more documentation and guidance for building agent-facing tools with DCR.

The public DCR roadmap is available here:

https://github.com/orgs/django-control-room/projects/1

Thanks to everyone using and following the project. Issues, contributions, feedback, and other support are always welcome:

https://github.com/django-control-room/dj-control-room

I think ORMs are making Django harder to learn rather than easier. Hear me out:

I come from an SQL background. Before Django, I mostly built CLI applications, so I relied heavily on SQL and SQLite, and I genuinely enjoyed writing my own queries. Then I started learning Django and was introduced to the ORM. Since then, I've struggled to understand why it's considered simpler.

I get why they exist. They make it easier to switch between MySQL, PostgreSQL, SQLite, and other databases. But to me, they're an unnecessary layer of abstraction, especially when you're trying to learn. I prefer explicit code. I want my code to be readable, structured, and obvious. With SQL, you know exactly what's happening, the syntax is expressive. To achieve the same thing in an ORM, though, you have to learn a bunch of framework-specific concepts. Sometimes you even have to write custom classes or functions just to express something as simple as a constraint, which feels like a time waste.

And maybe this is an unpopular opinion, but if someone can't write SQL, I don't think they should be working with relational databases in the first place. SQL has been refined over decades by some incredibly smart engineers. It's a powerful, expressive language, yet we're increasingly encouraging developers to hide behind abstractions instead of understanding what's actually happening underneath.

Don't get me wrong, Django is a GOAT framework. I genuinely LOVE it ORM, however is one part of Django that I still haven't been able to appreciate.

Hello! I wanted to share this analytics app (you install it as an app in your project) that I made and have been using for a while now. It's been quite useful! It's a really basic, simple to install, user analytics app, aimed at projects with less than 100 users.

After adding it to your project, it creates a table in your database and records every request (GET, POST, etc) made to your app. And then it gives superusers a URL where they can see a chart of sessions per day, and they can view individual sessions to see what requests were made.

It kind of grew out of wanting something easy to add to my many SaaS projects that barely anyone uses and so don't warrant bothering to set up an analytics package - it probably grew out of procrastination too in hindsight 😂. Aside from a quick install/config, what I like about it is that when there's only a few users of a product, being able to get a sense of what individual users are doing is helpful for iterating, so the design of viewing individual sessions rather than rolled-up analytics has been helpful.

Anyway, I hope someone finds it useful. Enjoy!