I think https://github.com/exoscale/interceptor are the generalized version of of what re-frame is doing. However, I've been researching algebraic effects and I think they might be the future for this type of thing. https://youtu.be/hrBq8R_kxI0?si=p1KJy1uMcDUsXk2x is a good intro video. I think algebraic effects are in a really great sweet spots because algebraic effects: • have a strong theoretical foundation for providing guarantees and reasoning about complex systems • are much easier to grok than typical FP theory like monads • are generally intuitive • have existing implementations that are highly performant The one major downside is that algebraic effects generally require support from the runtime, but some languages are already support them (eg. OCaml, Haskell) and I think some more popular languages might add support which would allow them to go mainstream (eg. rust, javascript, more?). You can also look into the free monad for prior art.

Sort of orthogonal things, having a data representation vs how the data representation is built

Effect systems can be annoyingly opaque, because basically you get the effect you want to "call" and a callback that takes the result (very much like a free monad)

And what can you do with a callback besides call it and see what it does

The pattern I end up following on the backend is I extract complicated logic that does lots of reading of databases and calling http apis into a function that is just all the control logic and takes callbacks that do the database and http calls. It ends up being similar to what you would get from a free monad or effects system, but without having to introduce new concepts into the code base.

As for having a data representation of database operations, CAS style read-modify-write loops are key to how I usually approach concurrency control with the database, and a data representation doesn't seem like it can capture the modify and loop parts of that

You could regard log-based systems in this way... each requested operation is serialized (as a 'command' as it were), put on a log or queue, which is saved for auditing and also 'replayed' in real time (and can be replayed any other time for testing)

https://github.com/matterandvoid-space/subscriptions https://github.com/lilactown/flex Could have sworn there was another one - some re- named thing, but I can't find it

Ah here it is. Maybe that works on nodejs, but it's cljs only https://github.com/lynaghk/reflex

the other thing is on the backend manipulating a database over the network has failure conditions that just don't exist when manipulating an in process store

Judging by the source, you'd have to rely on the impl details and create your own spec type by extending the Spec protocol and implementing the explain* method in the way you want. An alternative is to avoid relying on the explanation data and instead prepare it in some way before passing it further. You'd be able to find if the ordered spec, whatever it might be, is violated and preprocess the reported value accordingly. Also, maybe the spec-tools library has something useful for this, but dunno.

yeah i was hoping to run a related spec on map vector coll (rest coll) and let that propagate back up as the error.

I honestly don't know how robust it is, but seems that you might be able to check all the :problems one by one and see if the last spec in :via is the order one, and then you can find unordered items from the :val. No clue how it all works with the multitude of spec features though.

identifying that the order spec is the failure and then post process the collection to find it? Seems workable. Just not quite sure how to return that. I’ll have to read up on some docs again. Thanks @U2FRKM4TW

A brief example:

(s/def ::x (s/map-of keyword? int?))
=> :dev/x
(s/def ::y (s/coll-of ::x))
=> :dev/y
(s/def ::z (s/coll-of ::y))
=> :dev/z
(s/explain-data ::z [[{:x 1}]])
=> nil
(s/explain-data ::z [[{:x ""}]])
=>
#:clojure.spec.alpha{:problems ({:path [1],
                                 :pred clojure.core/int?,
                                 :val "",
                                 :via [:dev/z :dev/y :dev/x],
                                 :in [0 0 :x 1]}),
                     :spec :dev/z,
                     :value [[{:x ""}]]}

👍