Comments URL: https://news.ycombinator.com/item?id=47624069

Points: 2

# Comments: 1

Published as `reinhardt-web` on crates.io, imported as `reinhardt` in your code.

I built it after moving from Django/DRF to Rust and repeatedly assembling the same Axum + ORM + migrations + auth stack.

Two things I'd especially like feedback on: a built-in WASM+SSR reactive frontend (Pages), where a DSL-to-Rust codegen step (page!/head!/form! macros) produces both client WASM and server HTML from one source; and auto-generated migrations from #[model(...)] definitions.

Quickstart is here for anyone who wants to try it immediately: - Website: https://reinhardt-web.dev - Crates.io: https://crates.io/crates/reinhardt-web

v0.1.0-rc.15 (https://github.com/kent8192/reinhardt-web/releases/tag/reinh...), BSD 3-Clause. Looking for feedback on the API design, not production use yet.

Comments URL: https://news.ycombinator.com/item?id=47614697

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47555620

Points: 2

# Comments: 1

https://aisaastemplate.com/tools/django-cookiecutter/

Main reason: I kept repeating the same command-line flow when starting projects, and I’d occasionally mistype inputs or need to backtrack.

This is a small attempt to make that process smoother. It’s free, requires no login, and is meant for anyone who already uses or wants to try Django Cookiecutter.

I’ve been using Django Cookiecutter for a long time, and I’ve bought every edition of Two Scoops of Django, so this came from genuine appreciation for the project.

Feedback is very welcome.

Comments URL: https://news.ycombinator.com/item?id=47555587

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47493665

Points: 3

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47452347

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47411368

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47400089

Points: 442

# Comments: 171

I'm a self-taught developer from Malawi, and I built DJX because I was tired of writing the same Django boilerplate over and over.

Django is powerful, but starting a new feature means manually creating models, views, templates, URLs, and wiring everything together. Rails solved this 20 years ago with scaffolding. Django deserves the same.

DJX brings convention over configuration to Django:

    pip install djx-cli                                                                                            
    djx new myblog && cd myblog                                                                                    
    djx scaffold Post title:string content:text published:boolean                                                  
    python manage.py migrate && python manage.py runserver                                                         
    # → http://127.0.0.1:8000/posts/ — full CRUD. Done.                                                            
                                                                                                                   

Other commands: - `djx routes` — see all URL routes (Django doesn't have this built-in) - `djx destroy scaffold Post` — clean removal of generated code - `djx add django-crispy-forms` — install and auto-add to INSTALLED_APPS - `djx model`, `djx controller` — generate pieces individually

It follows Rails conventions: pluralized app names, RESTful URLs, automatic timestamps, and sensible defaults.

I built this because I wanted Django development to feel as fast as Rails. It's early stage, but it's already saving me hours on every project.

PyPI: https://pypi.org/project/djx-cli/ GitHub: https://github.com/RedsonNgwira/djx-cli

Would love your feedback and contributions. What other Rails-like features would make Django development faster?

Comments URL: https://news.ycombinator.com/item?id=47368925

Points: 5

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=47258426

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47216153

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47209151

Points: 2

# Comments: 0

I run a dev shop called Crudloop. With the UK PSTN copper network shutting down in 2027, I noticed many businesses panic-buying SaaS subscriptions (RingCentral/Webex/8x8) at ~£25/user/mo, despite wholesale SIP trunking costing fractions of a penny.

We spent the last 6 months engineering a production-ready VoIP stack to solve this.

The Business Model: This is not a SaaS and it is not Open Source. Instead of renting seats, I license the source code and deploy the entire stack to your private VPS (AWS/Hetzner/DigitalOcean). You pay a one-time fee for the code/setup, and then you pay wholesale rates directly to the carrier (Telnyx).

The Infrastructure: - Backend: Django (DRF) + Celery + Redis. Handles dynamic routing via Telnyx Webhooks (TeXML). Scalable via Docker Swarm/K8s. - Web: React + TanStack Query + @telnyx/webrtc SDK. - Mobile: Native iOS (Swift) integration for reliable background calls.

The Economics: For a company with 30 employees, switching from a £25/user SaaS to this private stack saves ~£8,000/year and guarantees data sovereignty. You own the metal, you own the logs, and you control the routing logic.

I'm looking for agencies or SMEs who want to own their infrastructure.

Happy to answer questions about self-hosting economics, scaling Django for real-time SIP events, or maintaining a private VoIP cloud.

Comments URL: https://news.ycombinator.com/item?id=47207428

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47192769

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47154958

Points: 3

# Comments: 0

- Redis inspection - cache visibility - Celery task introspection - URL discovery and testing

All of these tools have been built inside the Django admin.

Instead of jumping between tools like Flower, redis-cli, Swagger, or external services, I wanted something that sits where I’m already working.

I’ve grouped these under a single umbrella: Django Control Room.

The idea is pretty simple: the Django admin already gives you authentication, permissions, and a familiar interface. It can also act as an operational layer for your app.

Each panel is just a small Django app with a simple interface, so it’s easy to build your own and plug it in.

I’m working on more panels (signals, errors, etc.) and also thinking about how far this pattern can go.

Curious how others think about this. Does it make sense to consolidate this kind of tooling inside the admin, or do you prefer keeping it separate?

Comments URL: https://news.ycombinator.com/item?id=47151995

Points: 134

# Comments: 54

Key Features:

- Native HTTP/2 & HTTPS: No need for a reverse proxy just to get modern protocol support; Duck handles multiplexing out of the box.

- Lively Components: Think Phoenix LiveView but for Python. Build reactive, stateful UIs that update over WebSockets without writing a single line of JavaScript.

- Django Compatibility: You can keep your existing Django models and logic. Duck acts as a high-performance transport layer.

- Zero-Dependency Automation: A built-in task system that replaces Cron/Celery for 90% of use cases.

- Real-time Observability: A built-in terminal monitor (duck monitor) to watch your app's hardware impact in real-time.

Why build this?

I love the Python ecosystem, but I felt we were falling behind frameworks like Elixir’s Phoenix or Go’s Fiber in terms of "out-of-the-box" performance and developer velocity. Duck is my attempt to bridge that gap.

Docs: https://docs.duckframework.xyz GitHub: github.com/duckframework/duck

I’d love to hear your thoughts on the architecture, especially regarding the Lively component implementation!

Comments URL: https://news.ycombinator.com/item?id=47142493

Points: 3

# Comments: 2

Hit a wall with preview.

Instructors don't want a fake preview.

They want to actually take the exam they just built — real timer, real submission, real grading, state persisted across requests — then either publish it or throw everything away.

Looked at three options.

PostgreSQL schema separation is conceptually the cleanest but Django migrations get painful fast.

is_draft flags end up as conditionals in every layer.

Snapshot tables can't run real workflows.

What I actually want is pytest-style DB isolation in production.

Persistable, discardable.

Does this exist? How do systems like this usually handle it?

Comments URL: https://news.ycombinator.com/item?id=47135209

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47110023

Points: 11

# Comments: 5

Comments URL: https://news.ycombinator.com/item?id=47087025

Points: 1

# Comments: 0