↓Skip to main content

Django to Browser Push - Without WebSockets, Channels, or Redis

Django to Browser Push - Without WebSockets, Channels, or Redis

You have a Django app. You want to push updates to the browser in realtime. You look it up and immediately get hit with: install Django Channels, set up Redis, configure ASGI, add a routing layer, write consumers, handle WebSocket connections, manage reconnections…

All that for a toast notification that says “Your export is ready”?

I’ve been there. I built a realtime platform years ago called Socketize. It was a full-blown startup. I perfected it for a year and a half. It worked, but the market wasn’t ready. Life threw some curveballs, and I shut it down.

Fast forward to today. Realtime isn’t a nice-to-have anymore. It’s expected. So I decided to rebuild the core idea, but with the 80/20 rule. No startup drama. Just an open-source Django package that does the job.

Meet DjangoRealtime.

What it does #

DjangoRealtime gives you realtime browser updates using Server-Sent Events (SSE) and PostgreSQL NOTIFY/LISTEN. That’s it. No WebSockets. No Channels. No Redis. No Celery. No extra processes to maintain.

If you already have Django and PostgreSQL, you’re good to go.

How easy is it? #

Install it:

pip install djrealtime

Add it to your installed apps, include the URL, run migrations. Standard Django stuff.

Now send an event from anywhere in your backend:

from djangorealtime import publish

publish(user_id=user.id, event_type='task_complete', detail={'task_id': 123})

On the frontend, listen for it:

window.addEventListener('djr:task_complete', (e) => {
    console.log(e.detail);  // {task_id: 123}
});

That’s it. No seriously, that’s it. You just added realtime updates to your Django app. No new infrastructure. You publish an event, the browser hears it. Done.

Why SSE over WebSockets? #

WebSockets are bidirectional. Great for chat apps where both sides talk constantly. But most realtime use cases in web apps are one way: the server pushes something to the browser.

SSE does exactly that, and it works over plain HTTP. No protocol upgrade. No special server config. Your load balancer and CDN already understand HTTP. SSE just works.

And DjangoRealtime uses PostgreSQL’s NOTIFY/LISTEN to broadcast events across multiple Django instances. Your database is already there. Why add another moving part?

What can you build with it? #

  • Background task notifications. “Your CSV export is done.”
  • Live dashboards that update without page refresh.
  • Realtime messaging and chat.
  • In-app notifications without polling.
  • Multi-tab sync. User updates something in one tab, the other tabs reflect it.

I use it in production for Canvify and EmbedAny, both Shopify apps with real users and real traffic.

The stuff you’d expect #

Events are user-scoped by default. So no event leaks between users. Automatic reconnection if the network drops. Event persistence and replay if you need it. Django admin integration to inspect events. And backend subscribers for server-side listeners.

It even supports entity-specific events:

publish(user_id=user.id, event_type='page_imported', detail={':id': 42})

window.addEventListener('djr:page_imported:42', (e) => {
    console.log('Page 42 is ready');
});

Give it a try #

If you’re building with Django and need realtime updates, give DjangoRealtime a try. It took me a decade and a failed startup to get here, but I think it was worth the wait. I’d love your feedback.

If you find it useful, a star on GitHub goes a long way.