3 ms·

And then you use a threading macro to assemble a middleware stack, only to find out that the middleware is applied in reverse order of what's listed as an inbou

And then you use a threading macro to assemble a middleware stack, only to find out that the middleware is applied in reverse order of what's listed as an inbound request comes in... (The outermost middleware being listed last in a threading form). There's a reason for it, for sure, but it's surely a part of the learning curve.

sooheon 8y ago
Yep, it's always possible to have a mismatch in assumptions. That one definitely bit me as well. What's important is that the learning curve is not due to arbitrary rules, it's a faithful application of the logic of the macro. Remember that what is being passed through the threading macro is not the request, but the handler function itself. Each middleware takes the old handler, wraps itself over it to do things before and after the old handler. The threading macro is not a representation of the path your request will take, it is a way to build up a chained function that represents your final handler, which will then receive the request. Suddenly the ordering makes perfect sense :P