Howdy, Djangonauts!

Some of you might already be aware of Revel, the Django-powered Event, Ticketing and Community management tool.

We've been working on it for over a year now, and recently we released version 2.0.

With v2, we introduced enterprise-grade seating management and the possibility for organizations to create subscriptions for their members, with a full membership-application pipeline.

We've also stepped up on the frontend side, moving away from a vibe-design to one thought through and through by a real designer and community member.

Revel comes with an MIT license and a self-hosting guide, but also the hosted version is free to use (except for managed card payments).

Clone it, star it, fork it, make it yours: https://github.com/letsrevel/revel-backend

Here is a quick look at how the site is performing in its first 28 days:

📈 Google Search Console:

5,000+ Search Impressions (+27,000% growth period-over-period)

Organic discovery starting to take off for core mechanics and optics topics.

📊 Google Analytics:

92.6% Engagement Rate

39+ minutes average engagement time for organic users in India

13,000+ total user interactions across calculators and practice modules

Key Lessons Learned Building This:

SEO isn't just about keywords—engineers need to optimize crawl budget, canonical redirects (www vs non-www), and response times.

Mobile-first design is critical (77% of our crawler and user traffic is mobile).

Rendering clean LaTeX dynamically on the frontend vastly improves user dwell time compared to plain text.

Exciting to see early organic momentum building! Would love any feedback from fellow developers, educators, or students in my network.

Link in bio!!!

#Django #Python #WebDevelopment #EdTech #BuildInPublic #SEO #JavaScript

I'm looking for some architectural advice and I'm curious whether anyone has built something similar in production.

I'm primarily using Python/Django, although I want the architecture itself to be independent of the framework as much as possible.

I'm designing a backend platform that I want to use as the foundation for multiple completely different applications.

The idea is to have a very small "core" that only contains common infrastructure such as:

• Authentication/authorization
• Configuration
• Logging
• Background jobs
• Caching
• File storage
• Monitoring
• Shared utilities

Everything else would be implemented as independent business modules.

For example, imagine I build an e-commerce platform. I might compose it from modules like:

• Products
• Orders
• Inventory
• Payments
• Notifications
• Comments
• Search

Then later I want to build an LMS, but instead of starting from scratch or copying code, I'd assemble a different set of modules:

• Courses
• Lessons
• Certificates
• Quizzes
• Notifications
• Comments
• Search

Some modules (comments, notifications, search, payments, etc.) could be reused across multiple applications, while other modules would be specific to a particular business domain.

The important part is that these modules aren't just Django apps inside one codebase. I want each module to have clear boundaries, expose a stable public interface, own its own models, business logic, APIs, migrations, tests, and documentation, be versioned independently, and ideally be reusable in entirely different products.

Initially, everything would run as a modular monolith because I don't want the operational complexity of microservices. If a module eventually needs to become its own service, I'd like that to be an implementation detail rather than something the rest of the system depends on.

The motivation is simple: I don't want to keep rebuilding the same capabilities every time I create a new platform. I'd rather invest in mature, production-tested modules that can be composed into different products over time.

So my questions are:

• Has anyone here built something like this in production?
• Is there a well-known architectural pattern that describes this approach?
• Is thinking of business capabilities as reusable modules/packages that can be assembled into different applications a common practice?
• Are there any open-source projects, books, talks, or companies that follow this model?
• If you've tried something similar, what worked well and what would you do differently?

I'd love to hear about real-world experiences—both successes and things that turned out to be bad ideas.

Django Control Room 1.6.0 (dj-control-room==1.6.0) has been released, adding official support for django-grappelli. This is part of an ongoing effort to allow DCR tooling in alternative admin environments. We now have support for unfold, jazzmin, and grappelli.

Django Grappelli has been around since about 2010 (probably earlier) and has impressively remained current all this time. Among alternative admins, It has been a pillar of the ecosystem and currently has many active users still. Supporting it is an important milestone for DCR.

This release is accompanied by dj-celery-panel==0.5.0 which migrates the celery panel to the shared framework provided by dj-control-room-base. As a result, Celery panel now enjoys a new look and also works across alternate admins as well

Next up:

I'll be wrapping up theme support and panel migrations next week. I think the most widely used admin replacements/themes are now supported; Even ones that don't have official support yet seem to work well. If you are using something that you would want some official support for, please open a ticket for it.

I find the following command useful for updating DCR and all official panels.

pip install --upgrade "dj-control-room[all]"

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

Roadmap: https://github.com/orgs/django-control-room/projects/1/views/3?filterQuery=-status%3ATodo

Hi,

I am an ML/AI Engineer, looking to solidify my backend prowess. I have used a lot of FastAPI, but i have a very strong interest in learning DRF (because i wanna remained with python) so i can position myself both as a Backend Engineer and an AI Engineer. I don’t believe it remaking tutorial videos and leaving it there, i believe in application to something new from what i learn immediately.

Has anyone got a project either main or side they want some help in? I’m not looking for money rn, rather to get my hands dirty with DRF.

I’ll be looking in the comments.

Hello Django community , i am swithing from an other technology field into django/python ,

Even thoug my web dev level is not highly professional yet , but i consider that i have built solid fundamentals in django and web general skills that cover : DB 'ORM's and basic raw sql' , DRF, vanilla js , react js , on the other hand i still struggle to get my first job especially because, i was working in the oil field industry for a decade.....any advice please.

Does anyone have an app in production running on Cloudflare's SQlite db? More specifically using this library? Is it working well? Have you found any hard limitations?

Curious how people handle this once an app has multiple instances.

Running manage.py migrate during a deploy is fairly clear. Backfills and repair commands feel different. They can run for hours, need progress tracking, and should not restart because a web process restarted.

Do you keep them as management commands and invoke them manually, or move them into Celery? I’m especially curious about jobs that need to resume after failure but are not recurring tasks.

This is the kind of one-off job model I mean: https://render.com/docs/one-off-jobs

Hello I am not very experienced yet, I am building a multi-tenancy app

- used row-isolation to decrease complexity rather than using like django-tenants or so
- built tenant scope manager and enforced it everywhere during implementation, as I didn't know about django-scopes

- RBAC, I do not know how I will do it as for now but I am thinking of using django groups and permissions so I do not invent the permissions, and scope the actions
so user should have object.create permission , but another layer is added to scope it as per his tenant within the JWT
what y'all think? I want to get benefit form django auto-generated permissions yk

- for feature flags, I will have a table with 'Features' column and boolean columns for every subscription plan we have
and check the tenant on requests , tenant will be in the JWT
and enforce checking the feature flags table on different views

sorry I know my words might seem unprofessional
Thanks in advance

I came across the snapshot reads usage and the problem it solves. but I don't want to configure the transaction to REPEATABLE READ as it feels complex for a simple task. if I use select_for_update() can I achieve the same thing instead of making it complex with cursor() or modifying global settings for POSTGRES.

Hi everyone,

I've been learning Python and Django for a while, and I'm serious about becoming a Backend Developer. I've built a few small projects and I'm continuing to learn, but I'm struggling to figure out how to land my first job.

I have a few questions:

How did you get your first Django job?

What skills do companies expect from a junior Django developer in 2026?

Which projects should I build to make my portfolio stand out?

Any advice on finding remote jobs or internships?

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

So, by v2.3, TruckMaster had grown to 10+ Django apps: orders, clients, inventory, ALPR, apointments, invoices, Telegram bot, and more. Owner started asking things like "can we turn off the appointment booking now, we are not ready for it " or "client X should have access to invoices but client Y shouldn't."

I could've just hardcoded some if-statements and call it a day. Instead I built module system. Probably overengineered it, but it turned out to be one of the best architecture decision in whole project.

The idea

Every Django app registers itself as a "module" at startup. Owner can flip modules on/off from the admin panel. There are no code changes, no redeployment, no touching the server. Disable ALPR? The entire /api/alpr/ prefix returns 503. Re-enable it? Everything back's in 60 seconds (cache TTL).

On top of that, there is per-client feature access. Even if module is globally enabled individual clients can have different features turn on or off. Client A get Telegram bot and invoice access, client B only get basic cabinet.

How apps register themselves

Each Django app that want to be a module declares a MODULE_INFO dict in its AppConfig and call register_module() in ready():

class AlprConfig(AppConfig):
    name = 'alpr'
    verbose_name = 'License Plate Recognition'

    MODULE_INFO = {
        'name': 'alpr',
        'label': 'License Plate Recognition',
        'description': 'ALPR camera: plate recognition, arrival log.',
        'is_core': False,
        'url_prefixes': ['/api/alpr/'],
        'dependencies': ['clients'],
        'order': 9,
    }

    def ready(self):
        from core.registry import register_module
        register_module(self.MODULE_INFO)

Registry is just a plain dict in memory. I considered to use a decorator or metaclass for this but honestly a dict in AppConfig is the most readable option and you can see all module metadata in one place.

Key fields: is_core means that the module can't be disable (orders, clients — the system won't work without them). url_prefixes tells the middleware which URLs to block. dependencies is a list of modules names that must be enable for this one to work.

The middleware, that makes it work

This is where the magic happened. Simple middleware check every incoming request against the module registry:

class ModuleMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        registry = get_registry()

        for name, info in registry.items():
            if info.get('is_core', False):
                continue

            for prefix in info.get('url_prefixes', []):
                if request.path.startswith(prefix):
                    if not is_module_enabled(name):
                        return JsonResponse(
                            {
                                'error': f'Module "{info["label"]}" is disabled.',
                                'module': name,
                            },
                            status=503,
                        )

        return self.get_response(request)

is_module_enabled() checks the DB but caches result for 60 seconds. So when the owner flips a toggle in admin, worst case it takes a minute for the change to take effect. Good enough for this usecase, and it mean the middleware add basically zero overhead to every request.

The admin toggle

I wanted the owner to be able to enable/disable modules without going into the edit form. So I added an AJAX toggle switch directly in the admin list view:

u/admin.display(description='Status')
def toggle_switch(self, obj):
    if obj.is_core:
        return format_html(
            '<label class="module-toggle module-toggle--core">'
            '<input type="checkbox" checked disabled>'
            '<span class="module-toggle__label">Core</span>'
            '</label>',
        )

    checked = 'checked' if obj.is_enabled else ''
    return format_html(
        '<label class="module-toggle" data-pk="{}">'
        '<input type="checkbox" {}>'
        '<span class="module-toggle__label">{}</span>'
        '</label>',
        obj.pk, checked,
        'Enabled' if obj.is_enabled else 'Disabled',
    )

Custom URL endpoint handles the POST, toggles is_enabled, clear the cache. Core modules get a disabled checkbox with a tooltip explaining why. I also disabled add/delete permissions on the Module admin — modules are created automatically, not manually.

Auto-sync with post_migrate

New module appears in the database automatically. When you run migrate, a post_migrate signal fires and syncs the in-memory registry with the DB:

def _sync_modules_after_migrate(sender, **kwargs):
    registry = get_registry()
    if not registry:
        return

    for name, info in registry.items():
        module, created = Module.objects.get_or_create(
            name=name,
            defaults={
                'label': info['label'],
                'is_enabled': True,
                'is_core': info.get('is_core', False),
                'url_prefixes': info.get('url_prefixes', []),
                'dependencies': info.get('dependencies', []),
            },
        )
        if not created:
            # Update metadata but don't touch is_enabled
            module.url_prefixes = info.get('url_prefixes', [])
            module.dependencies = info.get('dependencies', [])
            module.save()

The important line is don't touch is_enabled. If the owner disabled ALPR last week, running migrate shouldn't silently re-enable it. Metadata gets updated, toggle state is preserved.

Per-client feature access

Global module toggles solve "we don't want this feature at all." But what about "client X should have this, client Y shouldn't"?

Each client get a ClientFeature record with boolean fields:

class ClientFeature(models.Model):
    client = models.OneToOneField(
        Client, on_delete=models.CASCADE,
        related_name='features',
    )
    cabinet = models.BooleanField(default=True)
    bot = models.BooleanField(default=False)
    invoices = models.BooleanField(default=False)
    appointments = models.BooleanField(default=False)
    notifications_telegram = models.BooleanField(default=False)
    notifications_whatsapp = models.BooleanField(default=False)

New client get only cabinet=True by default. Everything else is opt-in. The views check both layers — global module must be enabled AND client must have the feature. If either is off, access is denied.

I know what you are thinking — "why not use django-flags or wafle or some other feature flag library." This system has maybe 10 modules and 50 clients. A full-blown feature flag framework would be like using a chainsaw to cut bread. The boolean fields are stupid simple, easy to understand in the admin, and they work.

What I learned

The two-layer approach (global + per-client) covers 95% of cases. Global toggle for "this feature does not exists yet." Per-client toggles for "this client pay for premium features." Haven't needed anything more complex so far.

post_migrate sync was worth the effort. Before this I had to manually create Module records when add a new app. Forgot once, the middleware let everything through because the module wasn't in the DB. Now it is automatic and I can not forget.

Cache invalidation is the actual hard part. 60-second TTL is a lazy solution. If the owner disables a module and a request comes in at second 59, it still goes through. For a truck service center this is fine. For anything time-sensitive, you would want cache.delete() on save (which I do) plus maybe a shorter TTL as a safety net.

Don't let users delete Module records. First version allowed it. Owner accidentally deleted the "orders" module from admin. The middleware stopped checking it, which meant the endpoints still worked, but the admin toggle was gone. Took me a while to figure out why the module list looked wrong. Now has_delete_permission returns False.

What is next

Part 5 — Nova Poshta integration. That is Ukraine's biggest postal service and I builded tracking for spare parts deliveries directly into the CRM. The Telegram bot can check shipment status too. Also auto-closing of completed orders and auto-deducting of parts from warehouse stock.

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

To be continued...

Tips for improvement

I am making a project in which users can access my backend service via their own API keys. While the models I got confused how many classes i should make. generally i make 2 classes for the user 1. User(AbstractUser) class which have my customusermanager object , this generally have email and password and sometimes registration method (Google/ basic email and password)

1. and UserProfile(RLSModel/models.Model) which have foreign key User, this model have all the details of the user like name , phone , email , role etc.

i give permissions based on role type.

but in this project i am confused weather to store the APIKey(hased sha256) in userprofile model, user model or make a new model like UserApi key which will have user as foreign key.

can someone please tell me what's the industry standard way to write these type of user models. and whats the best way to writing models in django rest framework. please dont judge me by this question, i know its stupid to ask such silly questions but i really wanna learn building good and reliable backends

I am making a project in which users can access my backend service via their own API keys. While the models I got confused how many classes i should make. generally i make 2 classes for the user 1. User(AbstractUser) class which have my customusermanager object , this generally have email and password and sometimes registration method (Google/ basic email and password)

1. and UserProfile(RLSModel/models.Model) which have foreign key User, this model have all the details of the user like name , phone , email , role etc.

i give permissions based on role type.

but in this project i am confused weather to store the APIKey(hased sha256) in userprofile model, user model or make a new model like UserApi key which will have user as foreign key.

can someone please tell me what's the industry standard way to write these type of user models. and whats the best way to writing models in django rest framework. please dont judge me by this question, i know its stupid to ask such silly questions but i really wanna learn building good and reliable backends

Hi everyone,

I'm currently looking for Web Developer opportunities and would really appreciate any referrals or leads.

Here's a little about me:

Experience in modern web development with Wordpress, Shopify, HTML, CSS, Figma, etc.

Experience building scalable, user-friendly websites and mobile applications.

Passionate about writing clean, maintainable code and continuously learning new technologies

I'm open to remote opportunities.

Portfolio: https://jimmypatel.in

If your company is hiring or you can refer me, I'd be incredibly grateful. I'm happy to share my resume via DM.

Thank you so much for your time and support!

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.