This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-25
Channels
- # beginners (33)
- # cider (40)
- # clara (28)
- # cljs-dev (38)
- # cljsrn (5)
- # clojure (197)
- # clojure-greece (1)
- # clojure-italy (7)
- # clojure-losangeles (1)
- # clojure-nl (10)
- # clojure-spec (32)
- # clojure-uk (154)
- # clojurescript (48)
- # core-async (33)
- # cursive (32)
- # datomic (19)
- # duct (1)
- # fulcro (10)
- # graphql (6)
- # jobs (1)
- # lumo (1)
- # mount (6)
- # off-topic (48)
- # onyx (12)
- # other-languages (2)
- # re-frame (77)
- # reagent (19)
- # reitit (4)
- # ring (5)
- # ring-swagger (18)
- # rum (4)
- # shadow-cljs (52)
- # specter (12)
- # tools-deps (47)
@andreasp1994 compojure-api is built with macros (like Compojure), generating the source code. The :middleware
is resolved at (macro) compilation time, so it can’t see runtime bound things like mw
variable. I believe the evaluation could be delayed so that would work, feel free to create an issue out of that.
@ikitommi Thanks for the explanation! 🙂
In that case.. Do you have any suggestions for applying the authentication middleware conditionally on some routes?
@andreasp1994 you can put code in the :middleware
vector.
are you thinking of applying mw based on request? or just having a code that selects the suitable mw at api creation time?
Basically just having a code that selects suitable mw at api creation time
In the end, it’s not very easy to know with Compojure what happens when - there are at least three stages: 1) compile-time (e.g. the macros get expanded) 2) creation-time (static parts of the routing tree are created - most of the middleware assembly should happen here) 3) request-time - Compojure is a dynamic routing lib and Some things happen at request-time. Fiddling with mw-chain here has a cost (if performance is a factor, usually not)
Thanks for letting me know. I really appreciate your help! Thank you! 🙂
here’s an example:
(api
(context "/api" []
(context "/ipa" []
(GET "/drink" []
(ok {:was "good"})))))
;#Route{:info {:coercion :schema},
; :childs [#Route{:childs [#Route{:path "/api",
; :info {:static-context? true},
; :childs [#Route{:path "/ipa",
; :info {:static-context? true},
; :childs [#Route{:path "/drink", :method :get}]}]}]}]}
(api
(context "/api" []
:query-params [q :- String]
(context "/ipa" []
(GET "/drink" []
(ok {:was "good"})))))
;#Route{:info {:coercion :schema},
; :childs [#Route{:childs [#Route{:path "/api",
; :info {:public {:parameters {:query {Keyword Any, :q java.lang.String}}}},
; :childs [#Route{:path "/ipa",
; :info {:static-context? true},
; :childs [#Route{:path "/drink", :method :get}]}]}]}]}
here all routes are re-created at request-time and the data q
is passed via a closure into the subroutes.
the perf is ok in both cases (thanks to precompiled everything), but the first one is still faster.
I get you! Thanks for the example! 😉