> I wonder if there is a way of doing something like this well, so that it's easy to write but also lets you scale later.
It's not obvious that sticky websockets are *necessarily* problematic for typically use cases. Couple of things you'd want: * Have clients be responsible for graceful reconnects. (This seems like a reasonable policy in any case.) * Have instances enforce a maximum number of concurrent websocket requests that they'll accept. (Optionally combined with load-balancing websocket and HTTP to different sets of instances.) A totally different tack would be a websocket load-balancer proxy that transparently handles reconnects across the pool of servers, as required. It doesn't look like Nginx supports that, but it might not be a ridiculous proposal given that it does support acting as a websocket proxy to multiple servers. However what I'd *like* to do would be to write a consumer that routes messages to a channel layer. At that point uvicorn would be a fully fledged alternative implementation to daphne. One question there: The channel layer `.send(...)` method is currently a regular method. Should there be twisted/asyncio equivalents in the spec? Given that I'm writing an asyncio server I'd ideally like to be able to use `await channel_layer.send(...)`. (Granted it's only eg. a quick redis hop, and I do also have the option of running those operations within a separate thread.) -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3fe6c9c3-8cd2-4e22-bb0e-82f28355f866%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
