Maybe you can share a simplified example of the problem you are facing and how you think to solve it?

What I usually do is that I think that the handler is not the function that runs business logic but an intermediate function that gets rid of the transportation specifics and calls the business logic. Sure you can do all that with middleware but I think it’s simpler this way.

(assuming I understood the problem right)

@U6N4HSMFW You did understand it right. @U0FT7SRLP heres an example of the ring request map after running through reitit,`muuntaja`and malli. The structure (or schema if you want) of this map is highly coupled to the specific stack used, and we dont want our business logic to be coupled to the stack like that. Was wondering if there is a best practice to tackle this - • a middleware that filters just (:parameters req) and passes it to the handler? • Have a record that represents the request data and create an instance of it for each request There is also a question of performance here, important to say. we dont want to choose a solution that has inherent performance drawbacks

@U03086A7P99 I think i’m struggling with something similar. I want to compose small pieces of reusable middleware, but I noticed that when I use normal ring middleware that are interdependent, things are getting complex and it’s hard to follow and debug. You need to mind what middleware is inserted and in what order. And even then you might run into weird situations. Maybe there are best practises that I am unaware of. I’m exploring an alternative way (see https://clojurians.slack.com/archives/C7YF1SBT3/p1644421683409919?thread_ts=1643976596.167169&cid=C7YF1SBT3)

Btw, I think this is more a problem of ring than of Reitit. So far reitit has given me all the knobs I needed to change things for the better

Indeed, its more of a ring issue, but reitit stack is amplifying this