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.

https://github.com/cognitect-labs/pedestal.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

@joe.lane 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.

FYI, I’ve created https://github.com/pedestal/pedestal/issues/659 to track the creation of a session-aware WebSocketListener impl