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.
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)
The difference between middleware and interceptors being functions
vs data
, respectively.
closure vs explicit context
but yes, kinda
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.
We use them as wrappers around outgoing HTTP requests as well, to add logging/retries/QoS/encoding & decoding ...
FYI, I’ve created https://github.com/pedestal/pedestal/issues/659 to track the creation of a session-aware WebSocketListener impl