I’m working on an open-source backend built with Django, ASGI (WebSockets), PostgreSQL, and a small containerized setup.

1. Keep HTTP and real-time separate

Django is excellent for HTTP APIs. ASGI is great for WebSockets. Mixing them too early adds unnecessary complexity.

What worked well:

• WSGI (gunicorn) for standard API endpoints

• ASGI (uvicorn) only for real-time features

• Clear boundaries between sync and async code

This made debugging and scaling much easier.

1. Don’t rely on runserver

Using Django’s dev server behind proxies or tunnels caused connection resets and unpredictable behavior.

Switching early to gunicorn + uvicorn stabilized everything. Even for early-stage projects, using production servers early is worth it.

1. Media handling should be isolated

Once users upload files, media quickly becomes an infrastructure concern.

Separating media into a dedicated service (nginx or object storage) reduced app load and removed an entire class of bugs.

1. Add PgBouncer before you “need” it

With API, ASGI, and workers running, PostgreSQL connections grow fast.

PgBouncer:

• Prevented connection exhaustion

• Made traffic spikes predictable

• Simplified debugging

Transaction pooling with short-lived connections worked best.

1. Open source needs clarity more than polish

Clear README, honest tradeoffs, and a few beginner-friendly issues attracted more meaningful contributions than perfect code.

Final thought: keep the backend boring, isolate complexity, and optimize for contributors early.

Comments

[georgetoloraia]

The repo: github.com/georgetoloraia/selflink...