Interceptors are a generalization of the middleware pattern. They were pioneered by Pedestal and since then they’ve shown up in e.g. re-frame and reitit. I’ve been thinking about them and a while ago I wrote a post about their pros and cons.
Something I keep wondering about is that is the ability to manipulate the queue essential? I’m aware of the following use cases for web backends:
- Early return. For example, you might have an authorization interceptor that returns a “403 Forbidden” response if the user is not logged in. In this case you empty the queue.
- Routing. A routing library could look at the request and push new interceptors and a request handler to the queue. This would allow you to chain routing libraries in the same interceptor queue. I’ve chained routing libraries, for sure, but I’m not sure if they need to share the interceptor chain.
- Re-ordering the interceptors. You could have an interceptor that looks at the queue and re-orders it based on the dependencies between the interceptors like angel-interceptor does. I’ve actually used this with Kekkonen, but e.g. angel-interceptor is not an interceptor itself.
Now, Eric Normand’s interceptors do not have the queue exposed but they still support early return. I believe re-ordering is better done from the outside like angel-interceptor does and I’m unsure whether chained routing libraries need to share the interceptor context.
Does anyone know of other use cases for manipulating queue?