Clojurians Log v2

In the UI, I prefer the re-frame dispatch system, it’s a layer on top of a queue system (that could be implemented on top of core.async, although it has it’s own queue implementation I think), and the re-frame subscriptions allow for derived data to be described more easily than manually taping to channels. In re-frame you don’t need to worry about blocking. When having a channel that receives all the events from the server (e.g. websocket), I would dispatch to reframe on a consumer for that channel, and keep re-frame for UI updates. If the server sends huge amounts of events that you might want to discard/buffer some of them, In that case it could make sense to have some core.async design with buffers for that, but I would still keep the UI updates for re-frame. In backend I usually have more need for the fine-grained control over the channels and buffers, in part because of multi-threading, In part because the number of events to handle is bigger, and I end up with designs similar to what you described.

I'm using core.async pub/sub more on server-side. I did have trouble with subtle races and deadlocks for some time, but much less after I made simplified facade/API on top of core.async pub/sub which is closely tailored to my use-cases (rather than exposing the raw pub). I'm also using custom non-blocking buffers that log warnings when they start filling up, which helps debugging and prevents subs from blocking the publisher.

I like the idea of warning buffers.

And I feel the same about core.async feeling more natural server-side, though I can't quite put my finger on why and it doesn't seem fully explained by the obvious platform differences (ie threads).

@yonatanel i'd try doseq

It might also be that the pattern of having a store as single source of truth for your app, as re-frame does, is more extended in the frontend and goes along what redux in js land does, while in the backend there are more moving pieces with their own “state”, decoupled from each other