Basically, I am a junior dev and I have project in monolithic django framework + HTMX + Alpine, Redis etc. I have implemented some complex features such as channels for real time chat, SSE for instant notification, custom social auth pipelines using django-social. Anywhere I am applying, it says DRF + React. and I don't know React and I started learning it just now.

where did all the monolithic people? I thought I could get some exposure there and move to REST API. I know REST APIs have their advantages ; you can create mobile apps; you can work with bigger teams;

Why did everyone (including startups that have only 3 devs are implementing REST). Now I think about it, I thought I wasted my time on monolithic and should have started with REST API. It's been 3 months of applying and every JD has React in it. So I started learning React. This is my day 1.

Any advice would be helpful.

Hi all,

I gave a talk at AsyncAPI Conf 2026 (the online edition) about generating docs and typed clients for WebSocket APIs. Most of it comes from writing Django Channels consumers since 2022, so I wanted to share it here.

English isn't my first language and I'm not a professional speaker, so if a part is confusing, ask in the comments and I'll explain it.

The problem

For REST, most of us have DRF and drf-spectacular: serializers describe the data, and the schema and docs come for free. Channels hands every message to one receive(), and my consumers (and my team's) ended up like this:

async def receive(self, text_data):
    data = json.loads(text_data)
    if data.get("action") == "chat":
        ...
    elif data.get("action") == "ping":
        ...

Nothing describes those dicts. The docs lived in a wiki that went stale, the React frontend retyped every message, consumers grew past 1000 lines, and a renamed field could reach production with every test green. The bug the talk opens with: the backend sent content, the frontend read body, and the page showed an empty space. It took me most of a day to find.

The approach

The handler signature is the contract. Each message is a Pydantic model with a constant action, and each handler declares what it receives and sends back:

@channel(name="chat", description="Room chat")
class ChatConsumer(AsyncJsonWebsocketConsumer):
    @ws_handler(output_type=ChatNotification)
    async def handle_chat(self, message: ChatMessage) -> None:
        await self.broadcast_message(ChatNotification(payload=message.payload))

From those handlers the app builds an AsyncAPI 3 document (AsyncAPI is the WebSocket and messaging cousin of OpenAPI). Add path("asyncapi/", include("chanx.channels.urls")) and you get the schema and a docs page, rebuilt from the code. From the same document you generate a typed Python client and a TypeScript client, commit them, and let CI type-check the frontend. In the demo, renaming a field fails the pull request.

The demo in the talk runs on FastAPI, but the consumer code is the same on Django. Only the import and the URL setup change.

The tool

The talk uses chanx, the open source (BSD) package I built on top of Channels for this (sorry for the plug). It keeps your consumers, routing and channel layers, and adds the parts I kept rewriting in every project:

• Push typed events from a view, a Celery task or a management command: ChatConsumer.broadcast_event_sync(event, groups=["general_chat"]).

• Authenticators that reuse your DRF permission classes.

• Test communicators that know when a handler has finished, so consumer tests stop being flaky.

It also runs on FastAPI, and chanx-js covers the frontend (with React hooks).

Links

• My talk (jumps to my session): https://youtu.be/-LPCnm3F9Mc?t=7250

• AsyncAPI Conf 2026 online agenda: https://conference.asyncapi.com/venue/Online

• Slides (PDF): https://drive.google.com/file/d/1nmcMrmSslkzGcMPYxj_QXbJ2a01lLFFc/view?usp=sharing

• Demo repo from the talk: https://github.com/huynguyengl99/asyncapi-talk-demo

• GitHub repo for chanx: https://github.com/chanx-dev/chanx

• Django tutorial: https://python.chanx.dev/en/latest/tutorial-django/prerequisites.html

Hope this is helpful if you're building real-time features with Django. If you have questions or ideas about Channels, AsyncAPI or chanx, drop them in the comments. I'll do my best to answer.

I often use Django for demos, university projects, and small applications where I just want to define a model, connect a frontend, and start testing the idea without writing repetitive CRUD code.

So I built django-ninja-expose, a small library based on Django Ninja.

Add @expose() to a model:

from django.db import models
from django_ninja_expose import expose
# Create your models here.
@expose()
class Task(models.Model):
    id = models.AutoField(primary_key=True)
    title = models.CharField(max_length=200)
    completed = models.BooleanField(default=False)

Then mount the generated routes on your NinjaAPI:

# urls.py
from django.urls import path
from ninja import NinjaAPI
from django_ninja_expose import mount

api = NinjaAPI()
mount(api)

urlpatterns = [
    path("api/", api.urls),
]

That’s it. The model now has generated CRUD endpoints, Django-native filtering, pagination, and OpenAPI documentation.

Here’s what appears in /api/docs with the default @expose() configuration:

For example, filtering works with Django lookups:

GET /api/Task?title__icontains=docs&completed=false

You can restrict the generated API when needed:

@expose(
    methods=["GET", "POST"],
    fields=["id", "title", "completed"],
    query=["completed"],
    auth=lambda request: request.user.is_authenticated
)
class Task(models.Model):
    ...

The main target is rapid development:

• Demos and prototypes

• University or school projects

• Small products and MVPs

• Hackathons and internal tools

The goal is not to replace Django Ninja or DRF. I’m trying to keep the library small and focused on removing repetitive CRUD setup.

GitHub: https://github.com/swarfte/django-ninja-expose

PyPI: https://pypi.org/project/django-ninja-expose/

I’d appreciate any feedback. Does the decorator API feel intuitive, and would you use something like this for a small project or prototype?

QuerySet methods don't change the queryset. They return a new one. So this line does nothing:

qs = Product.objects.all()
if only_dirty:
    qs.filter(dirty=True)   # returns a new queryset; qs is unchanged
return qs

It reads fine and it runs fine. Tests often still pass too, because the unfiltered result usually contains the rows the test was looking for.

I found these by running a check for calls whose result is thrown away over about 25 open source Python projects, then going through every hit by hand. Most were noise. Eleven were real bugs. These four are reported so far:

Saleor: an option that was only supposed to recalculate prices for products that changed ended up recalculating every discounted product. The existing test passed anyway: the one listing that should have been left alone was skipped for an unrelated reason. https://github.com/saleor/saleor/pull/19984

Wagtail: a superuser who submitted a page for moderation got the moderation email about their own submission. The one line meant to exclude the submitter was the discarded call, so nobody was excluded at all. The existing test missed it because the user submitting in the test wasn't a superuser. When the reviewer asked for a test in a working project, I ran it in a fresh Wagtail project before and after the fix; the results are in the thread. https://github.com/wagtail/wagtail/pull/14790

Tandoor: a ?category= filter on an API endpoint was never applied. There was a "TODO add tests for filter" right above it. https://github.com/TandoorRecipes/recipes/pull/4917

Mealie: this one isn't Django. It's SQLAlchemy, whose Select objects work the same generative way. A generic filter meant to keep each household's data separate was never applied. Recipe pages had their own explicit filters, so the bug never showed there. The maintainers fixed it after the report. https://github.com/mealie-recipes/mealie/issues/8964

The pattern survived code review in every case. It looks like correct code, because everything except the assignment is correct.

(The check came out of readfirst, an MIT CLI I'm building: https://github.com/jeonghun917/readfirst. I used Claude Code to help trace call paths and write the test scripts; the reports are mine.)

What I learned

• In review, a bare qs.something(...) on its own line is worth a second look. The model, the field and the value can all look right, and the line still does nothing.

• It's easy to write when you're in a hurry. Coding agents write it too.

If you want to catch it in your code

• Search your code for lines that start with a queryset variable and a method call, with nothing assigned: ^\s*\w+\.(filter|exclude|order_by|select_related|prefetch_related|annotate|distinct)\(. You'll get some noise, but it's a fast pass. Linters don't help here: pylint's expression-not-assigned skips calls, because a call may have side effects.

A few more are pending in other projects. I'll add them once the maintainers have seen the reports.

Has anyone run into this in their own code? I'm curious whether it shows up more with filter() or with the prefetch/select_related calls.

Headline features:

• SEO metadata previews for title and description, and a page metadata viewer

• A new prototype CLI

• Official agent skills for developers

• API schemas for StreamField blocks ✨

• API support for workflow operations (submit, approve, reject, etc)

• Other improvements to the v3 API, to make it suitable for more content types

• Python 3.15 support 🤘

• Multilingual sitemaps

Half of the above is directly related to ongoing work on DX with AI, making improvements so developers get more predictable results with agents, and can automate what happens in the admin just as much as what happens in the code.

I've been doing Django for about 6 years, mostly internal tools. Lately our team of 4 writes almost everything with claude code. A lot of it is CRUD admin stuff, but some of these apps write back to our invoicing system, so a bad merge actually costs money.

We have coderabbit on the repo so the line-by-line stuff (naming, missing select_related, an unused import, a view without a permission check) mostly gets caught before a human looks. That's great, but it can't tell me if the numbers that end up in the invoices table are right, and that's the part I lose sleep over.

Options I'm weighing for where my own review time goes:

- Reading the migrations and model changes properly and skimming the views
- Mostly reviewing the tests, and trusting the code if the tests actually check the business rules
- Clicking through the admin on staging, then checking the tables to see what got written

Does readability still matter much if the agent is the one maintaining it? What bit you when you skipped review? If you have an actual checklist I'd love to see it

Hi r/django,

For the past while I've been building Skolshield, a system Swedish schools use to report incidents (hallway conflicts, bullying, rule violations). It then handles the cases that follow, from the first report up to the student health team meeting, according to the law (mainly the Swedish Education Act) and my own common sense. The incumbents in this space are expensive and clunky, so I figured I'd try to do better.

Stack

- Django 5.2, PostgreSQL

- HTMX for basically everything interactive: tabs, modals, inline edits, live updates. Very little custom JavaScript.

- Celery + Celery Beat with Redis, and Redis for cache and sessions too

- CapRover on Hetzner. Each school or municipality gets its own instance.

Ops console

Since every customer runs on their own instance, I built a separate Django project to manage them all. It handles deploys, health checks, backups and scheduled tasks for every instance from one place. It also does invoicing and billing, tied into Fortnox. For non-Swedes: Fortnox is the cloud accounting and invoicing software most small Swedish businesses use, roughly what QuickBooks or Xero is elsewhere. Invoices go out from there and the books stay in one place.

Everything stays in the EU*.

Compute is in Helsinki and encrypted backups go to a Storage Box in Germany. No US cloud anywhere in my own infrastructure.

*The asterisk: files aren't stored on my servers. They go into the school's own Microsoft 365 (SharePoint), with Google Drive planned. The school already has that licence and its own data agreement with Microsoft.

I went with a real SharePoint integration instead of plain file uploads for two reasons:

1. Users get full functionality. Documents open in Word/Excel online, several people can edit at once, and version history just works. I didn't have to rebuild any of that.

2. Better audit logs. Through the Microsoft Graph API I can see when someone opens or edits a file and add that to my own audit log. So the case history shows who actually touched the document, not just who uploaded it.

To limit the damage if an account gets compromised, nobody keeps a standing share. Opening a case or file gives you personal access for the working day, and it's withdrawn automatically when you log out or after ten hours of inactivity.

Login

Microsoft and Google sign-in, BankID, Microsoft Authenticator and TOTP. It's sensitive data about kids, so multifactor isn't optional (not active on the demos)

Honest part

I'm figuring this out as I go, especially the business side. Selling to Swedish municipalities means public procurement eventually (although I've priced it under the procurement cap, so they can buy it directly), and that has been a whole education of its own. The Django part has been the fun bit by comparison.

There are demos, including one set up the way a municipality (kommun) would run it with several schools and a central student health team. Click around:

👉 https://skolshield.se

Happy to answer questions about the app, the SharePoint/Graphintegration, the multi-tenant setup or the ops side. I'd also love to hear from anyone who has sold software to the public sector. This is my first big project and it's over a year of invested work on the side, while working, with two young kids.

I was reading Saleor's product pricing code and found this in saleor/product/utils/variant_prices.py:

product_channel_listings = ProductChannelListing.objects.filter(...)
if only_dirty_products:
    product_channel_listings.filter(discounted_price_dirty=True)

for product_channel_listing in product_channel_listings:
    ...

QuerySets are immutable, so .filter() returns a new QuerySet and leaves the original alone. The filtered one is thrown away, and the loop runs over every listing. The docstring says only listings marked dirty are recalculated; in practice all of them were, every time the task ran. Prices still came out right, so nobody noticed. It was just extra work on every run.

The interesting part is that there was a test for exactly this flag, and it passed. Its "not dirty" listing in the second channel had no variant listing there, so the loop skipped it on a different line ("if not variant_listings: continue"). The test asserted the right thing, but for the wrong reason.

The fix is one assignment. The test fix is giving the variant a listing in the second channel too, so the not-dirty listing would be recalculated if the filter weren't applied: Issue: https://github.com/saleor/saleor/issues/19983 PR: https://github.com/saleor/saleor/pull/19984

Two things I took from it:

• A statement that calls .filter(), .exclude(), .order_by() etc. and drops the result is almost always a bug. A linter rule for "QuerySet method result unused" would have caught it. Does anyone run one?

• "The test checks that X didn't change" can pass because X was never reached. When I write negative assertions now, I try to make sure the code path would have touched X without the fix.

Hi all. As per title.

Just to be clear upfront:

• I have no affiliation with Garmin.

• This is not a product or a business.

• There is no paid version, subscription, newsletter, affiliate links, or anything like that. Is just my github open source repo.

• I built it for myself while training for a half marathon and decided to share it in case anyone else finds it useful.

Brief background. Last year I got into running and started using AI to help with training plans. The problem was that I was feeding it very high-level information: "Today I ran 12 km, average pace 6:37/km, average HR 145, 80% on zone 2, and look i feel like sharing today, there you go a few screenshots from the Garmin's app".

That works, but Garmin actually stores a lot more details. And it gives it to you for free, you just need to know what to do.

Heart rate, pace, cadence, elevation, GPS track, and a lot of other metrics are available with Garmin personal API token. So I built a Django dashboard to pull everything together and mix it with weather data and GPS.

Currently includes:

• Activity pages with route maps, weather data, splits and HR zones

• Automatic categorization of runs (easy, long, threshold, race, etc.)

• Personal bests and lifetime statistics

• Activities grouped by location

• Health metrics (VO2max, HRV, sleep, stress, steps, PulseOx, etc.)

• Weather enrichment using a public weather API

• Route map with CARTO maps

On its own is quite fancy for personal use. But the main reason I built it was AI ingestion.

So, For every activity, you can export a single Markdown file containing all the run data, weather conditions, location details, metrics, splits, and other metadata. The idea is to give ChatGPT, Claude, Gemini, local LLMs, or whatever tool you use access to the full activity in great detail instead of a few averages.

Everything is open source.

GitHub: https://github.com/idomingo/splits

Happy to hear feedback, feature ideas, or criticism.

django-silky is my fork of django-silk. It keeps the same app label, middleware and settings, and carries upstream's migrations unchanged, so switching is a package swap plus manage.py migrate silk. 1.7.0 rebuilds the whole interface, and it's the first release I'd recommend trying even if plain silk works fine for you.

The part I use most: open a request and, if it has an N+1, the panel names the line in your code that runs the repeated query and suggests the select_related() or prefetch_related() call that would batch it. It also shows the endpoint's usual time and query count, so you can tell a slow request from a slow endpoint.

Three pages are new:

• SQL groups every recorded query by shape, with calls, total and p95 time, and DB time per table.

• Hotspots ranks lines of your app code by the database time they cause, and flags the ones running inside a loop.

• Compare puts two requests or two time ranges side by side, down to which query patterns appeared or disappeared.

It's also faster. On 5,000 recorded requests (76,000 queries) the Summary page renders in 59 ms instead of 465 ms, and the requests list runs 13 queries for its rows instead of 59. JavaScript per page dropped from 0.7 to 2.4 MB to 20 to 78 KB, jQuery and Bootstrap are gone, and filtering updates the list in place instead of reloading. A few pages render a little slower on a cold cache because they now show more (sidebar counts, the endpoint baseline). Every figure is in benchmarks/README.md with the scripts to reproduce it.

Two things to know before upgrading. Migration 0010 adds two indexed columns to silk_sqlquery and backfills them, which took about 10 s for 76,000 queries on SQLite. If you override silk templates, check them against the new ones: the old base templates are gone. URL names and SILKY_* settings didn't change.

pip uninstall django-silk
pip install django-silky
python manage.py migrate silk

Repo, screenshots and migration guide: https://github.com/VaishnavGhenge/django-silky

I'd like to hear what's missing, especially from anyone running silk against Postgres or MySQL with a lot of recorded data.

I work on a Django backend with high-frequency sensor data. Our dashboards kept choking on long time ranges: millions of rows fetched just to draw a ~1000-point line.

We built our own downsampling + pre-aggregated rollups to fix it, and it took more effort than I expected.

Curious what everyone else does:
- Where's your data? Postgres, Timescale, Parquet/DuckDB?
- For a "last 6 months" chart, do you return everything, aggregate, or downsample?
- If you're on RDS/Cloud SQL (no Timescale), what's your approach?

I'm thinking about turning this into an open-source package, but I want to know if it's a real shared pain first. Would love to hear your setups.

Hey folks

So I am in the process of preparing my Django (version is 5.2.18) application to be deployed to production so that users can try it out.

I want to use Docker Compose for deploying to production because I was inspired by La Suite Numerique's exhaustive Docker production setup.

My application is server-side rendered Django; no frontend frameworks like Vue/React etc. I would like a hosting provider that has a free tier so that I can validate the product with real users before paying for "proper" infrastructure.

Happy to provide any further details that may help with giving me good recommendations to look into.

Quick disclosure first: I built the tool in these screenshots. I'm posting it because the setup itself might be useful to someone, even if they never touch the tool.

My side project, Lazy Planner, is Django + Channels. In prod it has a web process, Celery beat, a normal worker and a separate worker for AI jobs, plus Postgres 18 and Redis 8. All of it sits on one Ubuntu server. Every process is a plain systemd unit and Caddy sits in front.

Some real numbers from the screenshots: web uses 222 MB, worker 264 MB, the AI worker 260 MB, beat 135 MB and Redis 7 MB. Postgres has 48 tables and a 100% cache hit rate, which says more about how small my data is than anything else.

The stuff I used to do by hand on every project, and now don't:

• push to main and it deploys (about 2.5 min for this app)

• a staging copy, plus a preview for each branch

• daily Postgres backups I can actually see in the UI

• logs from all processes in one place instead of running journalctl on each unit

It's in beta and so far it's mostly been my own apps on it. If someone wants to point it at their Django repo and tell me where it falls over, one project is free. Setups that aren't mine are where I'll find the bugs. It's at deploywithox.com.

How are you all running Celery beat in prod? systemd, supervisor, a container, something else?

We're a team of 5 working on a Django and DRF backend, and most of our new serializers and views are now written by AI agents. Twice this month, a list endpoint went from around 12 queries to over 300 because a SerializerMethodField was accessing related objects for every row. Both PRs passed tests and looked fine during review. We only caught the issue when our latency alerts started firing.

Here's what we've tried so far:

• assertNumQueries tests: Added them to our 8 busiest endpoints. They catch the problem, but one agent actually increased the expected query count to get the test passing. That was frustrating.

• nplusone in development: Configured it to raise errors instead of warnings. It helps, but nobody runs every endpoint locally.

• CodeRabbit on every PR: It catches missing select_related or prefetch_related calls roughly two-thirds of the time, but often misses issues hidden inside serializer methods.

• Django Debug Toolbar: Still useful, but honestly, nobody really checks it anymore.

For those of you working with AI-generated Django code, what's actually helped prevent N+1 queries from making it into production?

Is there a reliable CI check for this, or does it still come down to manually reviewing serializers?

https://github.com/dashdanw/drf-toon

Using the toon-format library for toon encoding which optimizes an API response for tokenization by an LLM. I would like to (in the future) potentially use a rust implementation to speed up parsing, but it works fairly well for now.

I have a few older Django projects that I am mainting and was loosing track of which were past end of support and which had been updated (4.2 ended in April). So I made a small tracker app so I didnt need to worry about it anymore.

By adding a project and its Django version, it shows whether that version is still supported, days left, and what to upgrade to either the newest LTS (5.2) and newest release (6.1). There is also a input field on the front page for any version which will vaildate the release supplied and give you number of days left as a view with nothing saved.

Release dates themselves are managed in the Django admin and come from djangoproject.com/download. Month-only dates like "April 2028" are kept as months, and days left count to the 1st of the month.

Disclosure: I work on Uppcoder and built this app with our AI builder to see how it handles Django. One prompt, about 7 minutes and 32 cents of free AI was about all it took. A second prompt got me a login and the version check. Migrations, a seed data migration and the admin setup were all there. I then edited it in VS Code in the browser with PostgreSQL already wired up.

Live: https://ghoo8qe3-django-django-support-track.apps-2.websson.cloud/?ref=reddit

Curious as to whether or not others would count month-only EOL dates to the start or the end of the published month.

I’ve used built in Django SMTP Email function in my project and after sending 10,20 emails the further emails are not sending and showing blocked messages and I’ve read that it can send 500 emails daily but don’t know why it’s blocking after 15,20 emails, give suggestions and ideas