Fork me on GitHub

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} ...)


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


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


@ianbishop you could do that with middleware chain transformer ( 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.


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


@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 [...]}}).


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


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


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.


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.


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


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


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)))))


Is it possible to use coercion to validate response headers?