Fork me on GitHub

Me again. I've made lots of progress and moved all my routes over to reitit, which was really straightforward! I can't get wrap-resource middleware working though, static things will only be served when I wrap the handler provided by rr/ring-handler. So this works:

    (rr/router ["" 
                ["/" {:handler index-page}]
                ["/banana" {:handler peel}]])) 
But this does not:
  (rr/router ["" {:middleware [[wrap-resource "public"]]}
              ["/" {:handler index-page}]
              ["/banana" {:handler peel}]])) 
What am I misunderstanding?


@conan wrap-resource is special middleware that serves routes behind the scens. Reitit is a route-first architecture: match first, then apply all the middleware for the matched route. Your second example doesn’t work because the route tree handles only exact matches “/” and “/banana” and thus, doesn’t match.


you can add a "/*" path to match anything and serve static resources from that.


but there is a caveat: having both "/" and "/*" will cause a route conflict.


so, you have the following options:


1) wrap the wrap-resouces over the router (your first example) => this is not good as for all routes, the mw check if there is a static file present. This is extra IO and slows the app down. 2) add a wildcard route and serve static resources from there: ["/*" {:middleware [[wrap-resource "public"]]}] + disable the route conflict resolution (with :conflicts router option) 3) wrap the default handler with the ring default handler


thanks. ok yes i see that i don't want to wrap everything in the static check. i'll look into the conflict resolution. i don't quite understand what you mean by 3)?


    [["/" {:handler index-page}]
     ["/banana" {:handler peel}]])


the ring-handler takes optional second parameter which is the default-handler, it’s just a ring-handler


(ring/create-default-handler) creates a default-handler with good’ish defaults.


in 3, it first checks the resource, then serves the 404-406 based on the request, see


oh and of course there's no wildcard route in here so it's ok, that's a great idea!


aside other things, I’m rewriting Immutant core for better perf, plan is to ship a fully async resource handler, as an option to the ring resource-middleware.


would look the same but would be much faster.


not sure if that will be merged back to Immutant, but nice to study how the NIO-stuff works.