aleph

wcalderipe 2019-11-13T09:07:37.008700Z

@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

wcalderipe 2019-11-13T09:12:14.010Z

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?

wcalderipe 2019-11-13T09:18:51.015700Z

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.

valerauko 2019-11-13T09:29:25.016600Z

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

valerauko 2019-11-13T09:30:06.017200Z

at least i'd expect it not to

ikitommi 2019-11-13T18:18:22.027100Z

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

wcalderipe 2019-11-19T03:42:52.032700Z

Sorry for the late reply and thank you for put that together on a message!