WebSocket

Channels extends Django beyond HTTP to handle WebSockets, and it integrates with Django's auth and sessions. Write sync consumers by default. Switch to async ones only when async handling helps and every library you call is async-native. Serve everything with Daphne, or keep HTTP on your WSGI server and send only WebSockets to Daphne.

Flask-SocketIO speaks Socket.IO, which is not a WebSocket implementation: a plain WebSocket client can't connect to it. Pick it when your clients use a Socket.IO client library. In return, you get events, rooms, and broadcasting. Start the server with socketio.run(), since flask run lacks WebSocket support.

websockets runs on asyncio by default, which is ideal for servers with many connections. For clients, its threading implementation is a good alternative. It isn't an HTTP server, so run it as its own program that calls serve(), not under a WSGI or ASGI server. For a few real-time features in a Django project, like notifications, its docs find a separate websockets server next to Django well suited, where Channels means switching to a new deployment architecture.

Autobahn|Python implements both WebSocket and WAMP, on Twisted or asyncio. WAMP adds RPC and pub/sub over WebSocket, and every WAMP client needs a WAMP router to talk to. Write components with functions and decorators, the recommended approach.

Always secure WebSocket connections with TLS in production. Any site can open a WebSocket to yours, with your users' cookies attached. If you serve private data, restrict the allowed origins: Channels has AllowedHostsOriginValidator, websockets has the origins argument, and Flask-SocketIO allows only the same origin by default.

Broadcasting across processes needs a message broker such as Redis. Channels' production channel layer runs on it, Flask-SocketIO takes it as a message queue, with sticky sessions at the load balancer, and websockets' docs suggest it for pub/sub.