Curious where people actually draw the line. Celery gets recommended pretty reflexively any time "background task" comes up, but it's also a real piece of infrastructure — a broker, worker processes, monitoring, retry/failure handling you now own. For something like sending a single email or a quick API call, django-q or even a simple threading.Thread can cover it without adding a new moving part to the deployment. For something genuinely long-running or that needs proper retry semantics, scheduled periodic tasks, or distributed workers across machines, Celery clearly earns its place. Where's the actual line for you? Is it request duration, is it "do I need retries," is it team size (nobody wants to debug a Celery worker at 2am solo), or something else entirely? Also curious if anyone's regretted adding Celery early and had to live with the operational overhead for a workload that didn't really need it.

I built this because I wanted to react to PostgreSQL changes from Python without polling, without triggers, and without pulling in a whole CDC platform.

It consumes PostgreSQL logical replication and exposes committed transactions as an async stream in Python.

What it does:

• Keeps a durable checkpoint. If the process dies, it resumes from the last transaction it actually finished, not the last one it started.
• Bounded delivery queue, so a slow handler doesn't let memory grow without limit.
• Reconnects automatically after the connection drops.
• One dependency: psycopg3.

The transactional outbox is one use case, but it works with any published table.

GitHub: https://github.com/mochams/walbox

Curious to hear where this wouldn't fit your setup, or what's missing if you've solved this problem a different way.

Hi Reddit,

I want to introduce a small framework I've been building and using in my own projects for the past few months.

It's called GridViewSpec. The name is not particularly exciting — it's basically a grid/dashboard view described by a spec :) The name stuck, so here we are.

I originally built it because I got tired of implementing the same details every time I needed a table or dashboard:

• global search
• per-column search
• filters that behave consistently
• saved searches / views
• PDF and XLSX exports with templates
• reusable table settings and configurations

The basic idea is to describe the page using a typed Python spec and let GridViewSpec handle the rendering and UI behavior consistently.

For tables, it currently has two backends:

• AG Grid for large datasets and server-side/lazy loading
• Simple Table for smaller datasets with regular pagination

Over time I also added charts, tabs, KPI/info boxes and other blocks, so it became useful for building complete dashboard-style pages rather than just tables.

There is also a built-in MCP server, so coding agents can inspect the available components, validate specs and get guidance on how to build pages with it.

And if you're building a more agentic application, the same spec can be used as an interface between AI and the UI: an agent can analyze collected data and generate an appropriate dashboard, table or chart configuration on the fly, without generating frontend code directly.

I made a demo site where you can play with it:

https://gridviewspec.alpi.net.ua

GitHub:

https://github.com/alpiua/grid-view-spec

Would be interested in feedback, especially from people who build a lot of data-heavy internal tools, dashboards, or agent-driven applications.

Hi guys

I'm learning web dev.

When I watch the course, he logout to test the user login and logout template

But I get this error, I searched but can't find the Solution, and can't understand the error

If anyone know the solution, shere it with me

What AI tools are the models or tools are you using to help you with your Django applications (writing code/debugging)? Are there models that have a marked strength in python/django? Are there models that could be good in js frameworks or laravel, but relatively suck at Django?

Every SaaS project I start ends up needing the same authentication layer. Email verification codes, password resets, JWT with the refresh token in an httpOnly cookie, Google OAuth, throttles. And every time I re-derive the same decisions, usually badly the first time.

I want to start building more SaaS's, and since Django is the backend framework I genuinely love working with the most, I wanted something that lets me move fast without rebuilding authentication from scratch every time.

So I wrote it once properly and open-sourced it. DRF, 18 endpoints, 407 tests so far, most of them covering failure paths: expired codes, replayed codes, forged OAuth state, suspension mid-session. Celery handles email asynchronously so a signup never waits on the email provider etc.

MIT. Billing (stripe) and admin app next.

Repo: https://github.com/fulanii/rebar-backend

Tell me where the security reasoning is wrong.