Real-time (WebSockets)

Some Midsummer features need live updates without polling. These run over Django Channels on the Hypercorn ASGI server, separate from the HTTP/REST path.

The plumbing

  • midsummer/asgi.py defines a ProtocolTypeRouter that splits HTTP vs WebSocket traffic.

  • The WebSocket router composes URL patterns from vendors.routing and register.routing behind AuthMiddlewareStack.

  • Consumers (in each app’s consumers.py) hold the per-connection logic and broadcast updates.

Client ──ws──► ProtocolTypeRouter ──► AuthMiddlewareStack
                                       └─ vendors.routing  (/ws/jurors/<display_id>/)
                                       └─ register.routing (staff-ping polling)

Two real-time features

Vendor jury voting

  • Endpoint: /ws/jurors/<display_id>/ (vendors/consumers.py, JuryVotingConsumer).

  • Jurors rate vendors live on a 1–5 scale with comments.

  • The consumer aggregates ratings and broadcasts the rolling result + deltas to all connected display/voting clients, and can auto-advance through the queue.

  • Frontend service: ui/src/app/services/jury-websocket.service.ts.

Register staff ↔ management ping

  • The check-in staff “Ping Management” channel and the management inbox poll for new messages (5s) with an audible “ding” on new inbound messages and a mute toggle. (This is primarily HTTP polling today, with WS routing available.)

When to use it

Use Channels when you need server-push to multiple clients viewing the same state (collaborative voting, live presence). For simple “is there new data” checks, the codebase favors short HTTP polling (5s) behind the existing REST APIs — that’s why the staff-ping inbox polls rather than subscribing.

Where to look

  • ASGI entry + routing: midsummer/asgi.py

  • App routing: vendors/routing.py, register/routing.py

  • Consumers: vendors/consumers.py, register/consumers.py

  • Frontend WS service: ui/src/app/services/jury-websocket.service.ts