Fork me on GitHub
Joe Lane14:05:22

You can "leverage the interceptor model" by creating your own interceptor chain and run all onmessage events through said chain. Pedestal interceptors are NOT coupled to HTTP, I've used them with queues, my own domain logic, I've even seen them with kafka.


We use them as wrappers around outgoing HTTP requests as well, to add logging/retries/QoS/encoding & decoding ...


lots of libs use that pattern now, it's basically an enhanced middleware pattern (open/modifiable stack/queue). There are also a few libs that make it usable with manifold, completablefutures, cljs etc (basically implementing their own chain runner, with some slight modifications sometimes, since it's not specified)

Joe Lane14:05:21

The difference between middleware and interceptors being functions vs data, respectively.


closure vs explicit context


but yes, kinda

Joe Lane14:05:57

I like your description more.


also interceptors you can modify on the fly the chain


then some impl re-wrap errors, some dont etc etc, small variations


@lanejo01 Thank you for the link. I really love the interceptor model. I find it much easier to wrap my head around than the middleware pattern. I have been looking at Sieppari for a general purpose interceptor chain but if Pedestal interceptors can be adapted, I will go with that instead.

👍 4
🚀 4

FYI, I’ve created to track the creation of a session-aware WebSocketListener impl


If you are accepting PRs for this, I can help. (I am not an expert on frontend technologies though, so it would be good if someone can provide meaningful feedback.)