What this prompt does
This prompt frames the model as a senior Django engineer adding Django Channels to an existing Django 5 project for a real-time [feature], returning working code rather than pseudocode. You set [feature], [channel_layer], [asgi_server], and [auth_source], and it wires ASGI alongside the existing WSGI views, an authenticated consumer, group broadcasts, channel-layer config, deployment changes, and tests.
The structure works because the real trap is breaking the synchronous request path while bolting on sockets. The first deliverable explicitly keeps existing views working under ASGI. [auth_source] drives how the consumer authenticates and rejects unauthenticated sockets -- the open-door failure the prompt prioritizes. [channel_layer] configures the broadcast backend with connection limits and a documented message schema, and [asgi_server] shapes the deployment, process management, and health checks. Group broadcasts ensure a server-side event reaches every subscribed client rather than just the one that triggered it.
When to use it
- A polling endpoint needs to become a live feed and you want sockets done safely.
- You're adding real-time notifications or presence to an existing Django 5 app.
- You're worried about breaking the synchronous request path while introducing ASGI.
- You need a consumer that authenticates and rejects unauthenticated sockets.
- You want group broadcasts so a server event reaches every subscribed client.
- You need deployment and testing guidance for an ASGI server, not just app code.
- You need a documented message schema so clients and the consumer agree on payloads.
Example output
You get the consumer, the routing, the settings diff, and the tests -- each fenced and copy-ready. Around them: the ASGI setup that runs Channels beside existing WSGI views, the channel-layer config with connection limits and a documented message schema, and deployment adjustments for your ASGI server including process management and health checks. The tests use Channels' communicator to cover connect, auth-fail, and broadcast cases so you can prove the socket behaves before shipping it.
Pro tips
- Set
[auth_source]to your real mechanism (the existing Django session) so the consumer rejects unauthenticated sockets correctly. - Get deliverable 2 right first -- an unauthenticated consumer is an open door, so reject the socket before it ever joins a group.
- Make
[channel_layer]explicit (Redis) so the config includes connection limits and a real message schema. - Match
[asgi_server]to your deployment (Daphne behind Nginx) so process management and health checks fit. - Confirm the ASGI setup leaves existing WSGI views untouched; the first deliverable exists precisely to prevent that regression.
- Run the communicator tests for the auth-fail case specifically; that's the path that's easiest to get subtly wrong.
- Document the message schema in the
[channel_layer]config so clients and the consumer agree on payload shape.
