Clojurians Log v2
interceptors
I see more people mentioning that Sieppari is tied to the request/response model, but isn’t that only if you use the execute function? To me it looks like the execute-context function makes no assumption about the underlying context.
I’m only using sieppari with reitit at the moment, but am trying to understand more about using it in other contexts.
what kind of contexts? Story of sieppari: 1. it was inlined in reitit 2. it was pulled out as a separate library 3. it got new features, which were not all good 4. it’s stable (`0.0.0-alpha13`😉 ) but not actively develop
you can use it in other contexts too
but, like with other dynamic-queue-interceptor-libs, you have a performance penalty of allowing the queue to be modified at fly. If that’s ok, it’s an ok lib.
for example, for #malli, we created a synchronous interceptor runner with static queues instead. For that given problem domain, it’s 1000x faster than sieppari and dead simple.
(actually, it’s faster than composing function with clojure.core/comp)
for dynamic queues &/ async, sieppari is better.
I’m thinking CLI apps maybe, or event processors. But nothing I see coming in the near future.
I guess I’m struggling to understand the reason for using e.g. exoscale interceptors instead of sieppari. Is it just because it’s a simpler implementation, or is it just because sieppari is not maintained anymore?
if sieppari works for you, go for it. It’s not actively developed, but PRs welcome.
I’ll write a post about our https://github.com/metosin/open-source#project-status-model soon.
Alright, that makes sense. Thanks. 🙂