Fork me on GitHub
#reitit
<
2019-10-16
>
nmkip01:10:37

Hi, beginner here 🙂 How do you organize your namespaces when defining a ring router? Do you have a different cohesive namespaces for handlers and then require all in one place to setup the router? For example: (ns book-store.books) books-handler-1 books-handler-2 (ns book-store.users) users-handler-1 users-handler-2 (ns book-store.router (:require [book-store.books :refer [books-handler-1 books-handler-2]] [book-store.users :refer [users-handler-1 users-handler-2]])) (def routes ["/users" {:get users-handler-1} ...)

valerauko04:10:10

depends. for larger projects i prefer to split up my routes into routes.books routes.users and then merge them in a routes.core

valerauko04:10:01

for smaller projects it's not worth the effort splitting up the namespace so i just have a routes and all the routes in one place

ikitommi13:10:36

@ianbishop you could do that with middleware chain transformer (https://cljdoc.org/d/metosin/reitit/0.3.10/doc/ring/transforming-middleware-chain): each chain is transformed per endpoint, so decorating an endpoint with something like :without-middleware [::some-mw], the chain transformer fn could remove the mw based on that.

dimovich18:10:49

@U055NJ5CC is it possible to transform the reitit.ring/ring-handler middleware?

ikitommi18:10:33

@U051951T6 no, because they are applied before any route match and effect also the default handler. You can push common mw under :data option of the router, effecting all routes and can be transformed. E.g. (ring/router ... {:data {:middleware [...]}}).

ikitommi13:10:28

If that's your own mw, it can read the endpoint data in it's :compile and not mount if there is some route data present

ikitommi13:10:37

third option is to use meta-merge hints to override the whole chain with a new one, e.g. :middleware ^:replace []

ianbishop13:10:53

Right on, using a transform makes sense. I wasn't sure if it would be evaluated for each chain but I guess it would need to be. I did originally try the meta-merge hint but it didn't feel great re-defing all the middleware, haha. Thanks a lot for the suggestions. I think I might go with restructuring our app a bit so there is finer control over middleware but I imagine I will end up implementing :without-middleware eventually.

ikitommi13:10:23

I think the chain transformations could have more batteries. There is a reitit.dependency ns, which allows the chain to be re-ordered automatically based on mw/interceptor data. It could have a extra layer which would allow auto-adding required mw/int too. For users, quite far in the land of magic, but, then again, all optional.

ianbishop13:10:03

Oh wow, this is really interesting. I didn't realize there was dependency re-ordering available. That might come in handy!

ccann19:10:29

Anyone have an example of spec’ing a Bearer Token authorization header via request coercion :parameters {:headers ...} ?

ccann19:10:27

This might actually be just fine:

:parameters {:header {:authorization ::bearer-token}}
(s/def ::bearer-token
  (s/and string?
         #(let [[bearer token] (str/split % #"\s+")]
            (and (= "Bearer" bearer) (some? token)))))

ccann20:10:11

Is it possible to use coercion to validate response headers?