Fork me on GitHub
#interceptors
<
2022-09-09
>
mdiin06:09:03

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.

👍 1
mdiin06:09:58

I’m only using sieppari with reitit at the moment, but am trying to understand more about using it in other contexts.

ikitommi11:09:38

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

👍 1
ikitommi11:09:45

you can use it in other contexts too

ikitommi11:09:52

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.

ikitommi11:09:30

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.

ikitommi11:09:08

(actually, it’s faster than composing function with clojure.core/comp)

ikitommi11:09:02

for dynamic queues &/ async, sieppari is better.

👍 1
mdiin11:09:07

I’m thinking CLI apps maybe, or event processors. But nothing I see coming in the near future.

mdiin11:09:54

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?

ikitommi12:09:31

if sieppari works for you, go for it. It’s not actively developed, but PRs welcome.

mdiin12:09:35

Alright, that makes sense. Thanks. 🙂