#Seeking for Async architecture advice
burnt cloudBOT
(from Discourse)
Perhaps GitHub - fsprojects/FSharp.Control.TaskSeq: A computation expression and module for seamless working with IAsyncEnumerable<'T> as if it is just another sequence + Channel<T>?
Hopac is by all means a valid, if overkill and, depending on your taste, exotic, solution 
You would still need to explicitly deal with Disposal. That’s just something Rust does better than any other language. For channels, at work, I ended up implementing a range of homegrown abstractions on top of Channel to idiomatically detect if T is disposable and supply default “item dropped” handler if a channel is configured to drop items on over-capacity (otherwise the T is moved to consumer and disposing is now its responsibility). Another concern that Channel mis-abstracts, depending on how you look at it, is whether writes have back-pressure and may block vs writes that always succeed (even if it results in the item being dropped). Last concern, I suppose, is write cancellation (on backpressure) via CancellationToken. WriteAsync on the Channel luckily handles it as is.
I have something half-ready saved, although it’s more focused on pooling and syntax and does not really deal with aforementioned concerns fully. For select, one way to handle it is to invert the relationship and have multiple jobs write into a single channel with a listener (which I find a little more aesthetically pleasing than dealing with it via Task.WhenAny).
If you are interested, I can throw something together that fits your goal more closely.
Generally, if whatever listens on ClientWebSocket does not need to explicitly synchronize with the rest of the jobs, it’s best to let it go do its job back-to-back or just fire off tasks rather than creating a single serialized chokepoint, but I don’t have a wider context, just something I noticed is a fairly common mistake (for example listening on RabbitMQ for completely independent, transient requests instead of handling them without a queue at all).
(from Discourse)
Thank you very much for the detailed answer. My use case is pretty simple but does require communications between jobs:
- One job to listen to events / responses from the web socket and pass it ordered as strings to a channel without back-pressure to be consumed by other job
- Second job that listens to channel messages and send each in order to the websocket.
- There will be a couple of jobs and channels for parsing JSON and handling different types of responses.
Basically it’s a tray-icon app that communicates with tiling window manager and reflect the changes in the system tray. In Rust I wrote an app with similar scope using tokio and while you’ll be right to say it’s overkill, it was pretty easy to implement .
Thinking again on the problem, there isn’t much difference in scope if I use jobs/channels or MBPs for this kind of scope. In both cases I need to listen and react on exceptions and disposals.
Maybe I’ll try to continue using MBPs and see how it goes…
Thanks
