FuncName() and FuncNameAsync() are common patterns in .NET land with async/await. The snake case translation would be funcname_async. From a quick scan, the JS world hasn't settled on a convention yet, though there is a bit of discussion about how to differentiate the names. Personally I don't mind the _async suffix, and I've been using it where there are both sync and async versions.
On Saturday, 17 June 2017 01:01:46 UTC+10, Andrew Godwin wrote: > > Right - as long as you make clients deal with reconnection (which > obviously they should), then as long as your load-balancing has a way to > shed connections from a sticky server by closing them then all should be > fine. > > Honestly, I have always been annoyed at the no-local-context thing in > channels; it makes writing code a lot easier, and while the current design > may technically be more scalable I'm not sure that holds true given that > sockets already have to be sticky thanks to TCP, and my own personal views > on "scaling down". My ideal solution is one that allows both approaches, > and I'd like to investigate that further. I think you're getting closer to > the sort of thing I'm imagining with the uvcorn designs, but I feel like > there's still something a little extra that could be done so it's possible > to offload over a network easily (as you mention, letting consumers go to > channel layers). > > This is one of the original reasons the message specification is separate > from the channel layer stuff; I always knew that my particular arrangement > of send-and-receive-in-processes wouldn't work for everyone and everything, > so I wanted a common message format we could definitely all agree on too. > If we end up with one format for channel names and messages that is spread > across two consumption forms (in-process async and cross-process channel > layers), I think that would still be a useful enough standard and make a > lot more people happy. > > As for making send() async - I resisted this so far on the grounds that it > is "non-blocking", but it involves a network call, so it's not actually > non-blocking, obviously. It also technically returns a result, in that you > have to be prepared to catch the ChannelFull exception, so it's not like > you can have a synchronous API that then ends up being fire-and-forget on > an async backend. > > I wish there was a nicer way to achieve this than having send_async() and > send_group_async() methods (etc.), but the only other alternative I see is > having the methods all mirrored on an .async object, as in > "channel_layer.async.send()". I'm not sure how I feel about that - thoughts? > > Andrew > > On Fri, Jun 16, 2017 at 5:49 PM, Tom Christie <[email protected] > <javascript:>> wrote: > >> > 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/django-developers/3fe6c9c3-8cd2-4e22-bb0e-82f28355f866%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/b61642ba-6066-4727-87e0-c3fce54c2ab0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
