@fmind The second- and third- most recent episodes of the defn podcast (https://defn.audio) are interviews with David Nolen (one of the main contributors to om.next) and Tony Kay (author and maintainer of fulcro), respectively. Having listened to both, I think you would be really well-served to hear each of their takes on pros, cons, and most critically what problems each library is trying to solve and what tradeoffs their authors chose to make in building them.

It’s not “just use Rails, mang” as simplicity of answers go, but I really do feel that one of the really important benefits of working in and with the Clojure community is that you have both access to the really powerful and generous minds that build the tools we use, and the leisure time - thanks to the quick work our sharp tools make of most mundane programming tasks- to really dig into the hows and whys of the tools you choose to add to your personal arsenal. Very, very few communities of working engineers in this era of technology have anything akin to what’s available to the working Clojurist; you owe it to yourself to at least once arrive at a decision about using library B over library A because you understand both A and B really well and not because Google PageRank or a co-worker pointed you to one or the other. 😇

I have written some in om.next and always have the experience where I read the docs and think I get it, then switch over to the code and have no idea what to do. The fundamental ideas are very good but I am not at all sure about the api tbh.

@chris_johnson I think the core principles of the Clojure community are wonderful: simplicity, modularity, innovation. The community managed to create both mature language and a nice lab to test new ideas

In the area of web development, the community pushed some nice ideas: the react architecture, query on the client side, management of state ...

it takes time and efforts to appreciate all these innovations. I do it during my free time, and I enjoyed learning through projects like Pedestal and om.next

but in term of productivity, I would love to have some sane defaults I could use in my projects

that's why I appreciate the feedback from experienced developers on their tech choice

Hi. Would it be a good idea to lift Interceptors out of Pedestal into a more common concept for Clojure? Like Ring, which defines just a spec that different libs could use - and produce Interceptors that can be used with other libs - like Ring. Currently, I know at least 5 different interceptor runners, inspired by Pedestal, but bit different. I don’t think this helps in the big pic. There are :before and :afters, :in & :outs, different keys for errors, queues, stacks etc.

The interceptors are a separate module, but still it has deps to things like core.async, pedestal.log etc. which are opinions that not everyone agrees. Also, the keys are namespaced to Pedestal (`:io.pedestal.interceptor.chain/error` etc.)

@ikitommi checkout io.pedestal.interceptors.chain/execute

@souenzzo thanks for the pointer! It nicely describes the how the interceptor should look like, but not the context. Context has things like ::queue, ::error and ::stack. Re-frame has :queue and :stack etc. Writing a portable interceptor that does error-handling requires to access the ::error.

I think programming against a contract (like https://github.com/ring-clojure/ring/blob/master/SPEC) instead of a helper api makes things more portable.

My 2 cents would be to use non-qualified keys for the context (`:queue`, :stack, :error etc.) like Ring does. This also enables perf optimizations as the context could be a Record with fast access to that info. Re-reading via a hash-lookup makes the chain execution much slower.

P.S.: I'm using the ctx/`chain` concept in various/non-http context in my app.

cool. the pedestal chain or just the concept?

one "own" chain, to interact with #datomic (when I implemented, I did not know that pedestal chain was easy to use), and a websocket chain, using chan/execute.