Fork me on GitHub
Harel Opler11:02:26

Hi everyone, A general question that relates to reitit but not limited to it. We are using reitit+`malli`+`muuntaja` as our web ring stack, and we love it. One thing we havnt figured out yet, is how to pass the request to the handler. What i mean is - once an HTTP request processing is done by muuntaja and malli , the request map has many keys that are related to these libraries. for example, the coerced request is found under (:parameters req). It doesnt make sense for the handler to be aware of these keys, as it makes the handler highly coupled to the web-stack libraries in use. We’re trying to figure out if there is a best practice - in general or specifically for these libraries - to transforming the request to something less coupled to the web-stack. One option we thought about is to create a middleware that transforms the request map to some record, representing the data passed in the request. A bit like a DTO in java, completely decoupled from the transportation layer. Would like to hear your thoughts, Thanks!


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.

👍 1

(assuming I understood the problem right)

Harel Opler20:02:58

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

Harel Opler12:02:08

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