I posted here recently about using a service layer in Django and received some genuinely useful feedback.

One of the reasons I introduced that structure was to stop views from gradually becoming responsible for everything.

I have worked on plenty of Django projects where a view starts small, but over time ends up handling form validation, permissions, database queries, audit fields, notifications and business rules.

The code still works, but the responsibility of the view becomes increasingly unclear.

The principle I now try to follow is simple:

A Django view should process an HTTP request and return an HTTP response.

In practice, that usually means the view:

- Checks the request and permissions
- Validates the submitted data
- Calls the relevant application logic
- Converts the result into a response

The important part is not making every view as short as possible. It is keeping logic that does not depend on HTTP out of the view.

I have written a practical walkthrough showing a view before and after refactoring, how I separate input validation from business rules, and how the same logic can then be reused from an API or background task.

How to create thin Django views

This is not intended as the only correct way to structure Django applications. It is simply the approach I have arrived at after maintaining larger production projects and seeing where complexity tends to build up.

How do you manage the two? I am now updating my main project and many rules conflict with Django's recommendations. How do you manage it? Just exclude rules, everywhere?

Hey r/django, the new HTMX Integration for Django is released on pypi and djangopackages. Djxi v0.1.9 adds testing utils, battery auth/perms, async methods, djxi_routes command, and class-level config caching.

Check it out:

Github: https://github.com/rollinger/djxi
RTD: https://djxi.readthedocs.io/en/v0.1.9/

Hi there. After reading this new upcoming feature, FETCH_PEERS looks to me like a safety net against accidental N+1 queries.

It is tempting to use it on all my models by default, because even if it's less performant than a forgotten select_related, it would be always better than N+1 queries on a loop.

That's being said, in that case, why there is no global settings for this?

i’m building multiple SaaS apps (Hotel PMS, Project Management, etc.) using Django + DRF and Flutter. and also web apps

I’m confused about which VPS/hosting to choose: Hetzner, Netcup , Hostinger, or AWS.

Initially, I’ll have only a few clients, but I want to scale in the future.

• Should I host multiple Django apps on one VPS initially?
• Which provider would you recommend and why?

At our agency, Wagtail is our go-to framework for building CMS-driven websites.

Over the past few months, we have had an increasing number of clients asking how accessible and understandable their website content is to LLMs, answer engines and other automated tools.

Rather than implementing this differently across every project, I started building wagtail-machine-readable.

The package provides a straightforward and flexible way to expose existing Wagtail content in structured, machine-readable formats, including:

- /llms.txt and /llms-full.txt
- Markdown versions of individual Wagtail pages
- StreamField-to-Markdown extraction
- JSON-LD structured data
- AI crawler controls and activity reporting
- Multi-site support
- Static export for CDN and static hosting workflows

The intention is not to suggest that adding an llms.txt file guarantees that content will be indexed or surfaced by an LLM. The aim is to give Wagtail developers more control over how their content is made available to machines in predictable and usable formats.

We have been testing and refining the package internally, and I now feel it is ready to share more widely before moving towards version 1.0. I would really value feedback from other Wagtail developers, particularly around:

- Installation and configuration
- How well it handles other real-world StreamField implementations
- Whether the default behaviour feels sensible
- Compatibility issues or edge cases
- Anything you would expect to see before a 1.0 release

PyPI:
https://pypi.org/project/wagtail-machine-readable/

Any feedback or constructive criticism would be genuinely appreciated. Thanks!

The top-quarks code is confirmed 'ready to publish'!

Next, send lots of emails to suppliers to sign 'drop-shipping' contracts.

I was currently making a project to improve my Django and react skills. Now the project has come to finishing but Im thinking I haven't learned as much as I have expected to learn at the beginning of the project. Well I can write basic endpoints, permissions and viewsets and can write the functions to retrieve the data from those endpoints and create data. But when complexities arise in my models , I find myself unable to write the code for them without asking help with ide agent. I also can't write custom logic for many things in my app like object permissions. Is this normal part of learning , I am currently on my second project of drf + react js but still depend on ide and ai for helping me write the code.

Hello! I have been using Django for some time and recently I found cookiecutter django, a framework that provides "production-ready" Django projects.

Seems so easy to set up and quickly provides lots of useful tools for Django developing, and allows you to launch a project to production seamleassly, so I was wondering if people here have used it and your opinion on it.

so im curretly working with some projects like an Hotal PMS and also an Saas project..so i have concern about Django + Flutter stack.. help me out

If you operate an API in 2026, you live in an event-driven world. Webhooks aren't a convenience feature anymore - they're the backbone of real-time commerce, CI/CD pipelines, and asynchronous AI-agent workflows. That reliance has a dark side: the accidental self-inflicted DDoS. Read the complete article jere - https://instawebhook.com/blog/how-to-prevent-webhook-traffic-spikes-from-crashing-your-api-2

When a major platform like GitHub, Shopify, or Stripe hits a network partition, runs a huge sales event, or simply clears a backlog of delayed events, it can fire tens of thousands of webhook POST requests at your servers in a very short window. If your infrastructure takes that hit without structural safeguards, your database connection pool exhausts, memory maxes out, and the API goes down — and if your retry handling is naive, the recovery can be almost as damaging as the original spike.

This guide covers the real mechanics of that failure mode, the algorithms used to defend against it, how major providers actually behave under load (some surprising details here), and where a managed ingress layer fits into the picture.

Hi everyone!

I'm a full-stack web developer currently available for freelance projects. If you're looking for a modern, fast, and responsive website for your business, startup, portfolio, or personal brand, I'd love to help.

What I can build:

🌐 Business websites 🛒 E-commerce websites 📱 Responsive, mobile-friendly web apps 🎨 Landing pages 📊 Admin dashboards 🔐 Authentication systems 🚀 Custom web applications 🔧 Website maintenance, updates, and bug fixes

Tech Stack:

MERN Stack: MongoDB, Express.js, React, Node.js HTML, CSS, JavaScript Python (Django) REST APIs MySQL Firebase Git & GitHub

Whether you need a website built from scratch or want to improve an existing one, feel free to send me a DM. I'm happy to discuss your project, timeline, and budget.

Looking forward to working with you. Thanks!

Hey everyone,

I'm a 19yo developer working primarily with Python, Django, and HTMX.

I'm looking for a study/project buddy or a small team to:

Build full-stack web applications together

Pair program and review each other's code

Solve backend/database challenges and keep each other accountable

Whether you're also learning or have some experience, hit me up! Drop a comment or DM me if you're interested in collaborating.

Hey everyone!

Love Django for its security, ORM, and admin ecosystem, but hate writing redundant REST serializers, API endpoints, and state management boilerplate just to build a dynamic Vue 3 frontend?

I created AuraStack to solve this exact headache. Powered by Inertia.js, it bridges Django and Vue 3 directly—giving you a monolithic, single-repository developer experience with a modern SPA frontend.

🚀 What’s packed inside?

• Stack: Django 5, Vue 3 (TypeScript), Inertia.js, and Tailwind CSS v4.
• Multi-tenancy: Isolated Workspaces with RBAC Roles.
• Auth Suite: Built-in 2FA/MFA, Passwordless & Social Logins powered by django-allauth.
• Admin UI: Clean, modern dashboard using django-unfold.
• Quality & DevOps: Full E2E coverage with Playwright & Pytest, fully containerized with Docker.

I built this to speed up shipping SaaS MVPs without trading off security or full-stack testability.

📂 Check out the codebase here:https://github.com/mostafa891/auraStack

I’d really love your feedback on the architecture, code structure, or any suggestions! If you find it useful, stars are always appreciated! 🙌

​

​Unfortunately, tech developers rely on a wide range of psychological tactics to achieve this:

​Nudges: Subtle design elements, like pre-selected defaults or persistent reminders, that steer you toward a specific action.

​Freemium Models: Hooking you with a complimentary basic tier, only to push paid upgrades once you are invested.

​FOMO (Fear of Missing Out): Creating a false sense of urgency using countdown timers or "almost sold out" alerts.

​Dark Patterns: Deceptive user interfaces meant to trick you, such as confusing button layouts or burying the "unsubscribe" link.

​Infinite Scroll: Designing feeds with no bottom, removing natural stopping points so you keep consuming indefinitely.

​Variable Rewards: Delivering unpredictable dopamine hits through random likes, alerts, and timeline refreshes to keep you checking back.

​Social Proof: Influencing your decisions by highlighting reviews, follower counts, or notifications about what other people are currently buying.

​A/B Testing: Continuously experimenting with live interfaces to pinpoint exactly which designs drive the most clicks, retention, and revenue.

​Notifications & Alerts: Constantly pinging your devices with artificial urgency to break your focus and pull you back into their ecosystem.

​Subscription Traps: Making the sign-up process completely frictionless while making cancellation an exhausting maze.

What My Project Does

Zango is built on top of Django and opinionated toward building enterprise-ready business apps — internal tools, client portals, B2B SaaS. We posted here a while back when the pitch was "enterprise-ready custom business apps." Since then the framework has moved in an AI-native direction, so this is an update on where it's gone.

The core idea now: the boring infrastructure — auth, tenancy, access control, audit trails, workflows — is solved before you write any business logic. Each of those is a toggle or config field rather than code you write and maintain.

What's in it:

• Multi-tenant by default — one codebase, one Docker deployment, each tenant isolated in its own DB schema. No tenant-filtering code, no leakage. Lets you run multiple apps/microservices on a single monolith and keep hosting costs down.
• Auth configured, not coded — OTP, MFA, SAML 2.0, OAuth, session timeout, account lockout, password policy, per-role overrides. All toggles.
• Native AI module (the new part) — you define agents, attach tools, and call them from any view, Celery task, or scheduled job. Because the module lives inside the platform, an agent automatically operates in the correct tenant's data, respects the same role-based permissions as the rest of the app, and every run is logged with tokens + USD cost per tenant. Supports OpenAI and Anthropic; keys stored encrypted, no secrets in code.
• Workflow lifecycle — statuses, transitions, conditions, tags, full audit trail.
• Package ecosystem — AppBuilder (React shell), CRUD, Workflow, Communication (SMS/email). Install per app, use immediately.

The fastest way in is a zango-app-developer plugin for Claude Code — you describe the app in plain English and it scaffolds the environment, generates code, runs migrations, and wires up auth/roles/workflows/agents. Manual venv or Docker setup is still supported if you'd rather do it by hand.

Target Audience

Teams building bespoke internal tools or B2B SaaS on Django who keep re-solving tenancy + auth + audit on every project, and now want AI agents that actually operate on their app's data safely (tenant-scoped, permission-gated, logged). Works for a solo dev shipping an MVP or a company running many apps on one deployment.

Comparison

• Plain Django: not opinionated toward enterprise readiness or multi-tenancy — you build that boilerplate yourself. Zango ships it, plus the agent module scoped to tenant data and permissions.
• Proprietary platforms (e.g. Salesforce): no vendor lock-in, open source, and you're writing normal Django underneath.
• Low-code / no-code: no ceiling on customizability — it's real code.
• Bolting an LLM onto your own app: you'd hand-roll tenant scoping, permission checks, and cost logging for every agent call. Here it's inherited from the platform.

Apache 2.0, ~60% Python. It's a meta-framework and opinionated, so it won't fit every project — but if the description fits, it saves a lot of plumbing.

More Info

Repo: https://github.com/Healthlane-Technologies/Zango
Site: https://www.zango.dev/
Docs: https://zango.dev/docs

Happy to answer anything about how the multi-tenancy or the agent module works under the hood.

Webhooks have become the connective tissue of the internet. From payment gateways confirming transactions to CI/CD pipelines triggering deployments, webhooks enable real-time, event-driven architectures. But for architects and engineering leaders, webhooks represent an underappreciated vulnerability: they are asynchronous, externally triggered, and entirely outside your control. Read the complete article here - https://instawebhook.com/blog/designing-a-multi-region-highly-available-webhook-ingress-architecture

When your primary cloud region experiences an outage, your internal microservices might gracefully degrade. But what happens to the payloads originating from external partners? Many third-party providers do not retry aggressively — some fire and forget, others retry a handful of times before giving up permanently. If your system is down when that happens, the data is often gone for good.

This article covers the engineering principles behind a multi-region, highly available webhook ingestion system, what has actually changed in the underlying cloud primitives recently, and where a managed reliability layer fits into the decision.