@rahul080327 thanks for the insight! 🙌 I did read the article on http://booleanknot.com which is also mentioned in the docstring of the middleware. Have you used this approach in production? Source: https://github.com/ztellman/aleph/blob/5cc7bcab723bf3b64de7998fc782531c554636e5/src/aleph/http.clj#L436-L445

AFAIU, the proposed solution is not backwards compatible and you can't have a mix of sync and async handlers in the application level. Am I right?

At the moment, we have a poor design solution for async handler. Every Compojure sync handler (signature fn [request] -> response) is returning a channel instead of the response map and a downstream middleware is responsible to unwrap the channel and take the value out (same approach of wrap-ring-async-handler but different 😅). That being in place, every application middleware needs to know how to handle a channel instead of a map which is a big deviation from the community standard and it's leading us to have lots of in-house solutions for problems already solved.

i don't think wrap-ring-async-handler would require the middleware to know about deferred

at least i'd expect it not to

@wcalderipe middleware is very async-friendly. The reitit example above uses the interceptor-model (reitit supports both mw & interceptors via separate modules) which allows any step to return an async value (e.g.core.async channel), the interceptor runner unwraps the value automatically for the next step. Pedestal also uses interceptors and yada uses manifold for easy one-way async chaining.