Add middleware *before* routes are selected

[Akeboshiwind]

Currently you can only add middleware after the routes are selected.

A case where this might be useful is adding some data to the request then routing based on that:

(defn random-select-middleware [handler]
  (fn [request]
    (handler (assoc request :selected? (rand-nth [true false])))))

(def routes
  [[:selected? #'handler]
   [(complement :selected?) #'other-handler]])

To use this middleware currently you have to build the stack yourself:

(-> router/execute-route
    ;; Other middleware
    (store/middleware {:path "store.edn"})
    (router/select-route-middleware routes)
    random-select-middleware
    invoke/middleware)

[Akeboshiwind]

Proposal 1

• Add :pre-middleware and :post-middleware
• Have :middleware merge/concat onto :post-middleware

It would look something like this:

(def app
  (defaults/make-app routes {:pre-middleware [random-select-middleware]
                             :post-middleware [other-middleware]}))

Downsides:

• Looks kinda icky/clunky

Proposal 2

• Change :middleware to always run before route selection
• Add :middleware key to individual routes
• Add some way of specifying data (like middleware) that applies to all routes

It would look something like this:

(def routes
  [[:selected? #'selected]
   [(complement :selected?) {:handler #'not-selected
                             :middleware [other-middleware]}]])

; With sketched parent data
(def routes
  [(constantly true) {:middleware [other-middleware]}
   [:selected? #'selected]
   [(complement :selected?) {:handler #'not-selected
                             :middleware [other-middleware]}]])

(def app
  (defaults/make-app routes {:middleware [random-select-middleware]}))

Downsides:

• Not sure what the syntax would look like for point 3, but if it's not there can't run middleware for all routes without annoying configuration
• Unclear from syntax when the middleware on the route runs
  • Unclear in general tbh, that's the issue here :/

Proposal 3

Use interceptors? Not thought this through but they can re-order themselves right?

Downsides:

• Rewrite
• Don't really know interceptors that well tbh

[Akeboshiwind]

Proposal 4

Deprecate defaults and instead provide a template project.

Downsides:

• I don't really like them tbh
• Users would end up with more boilerplate in the end

[Akeboshiwind]

Having mulled over these a bit and explored interceptors a bit more, I'm feeling Proposal 2 the most.

I.e:

• Change :middleware in defaults to run before route selection
• Update the built-in middleware (I think just the global admin middleware)
• Maybe later:
  • Add :middleware key to individual routes
  • Add a way to specify middleware that runs after route selection

My thoughts are:

• Interceptors are cool, but it feels like a bit much to expect users to modify a queue of interceptors. They also seem very implementation specific, either I'd roll my own or use a library all of which are subtly different, maybe this isn't such a big issue 🤷
• Middleware feel simpler to me, so I'd rather stay with them until we find an obvious reason to change
  • We can always accept both later
• 99% of cases (that I've come across so far anyway) are served by middleware before route selection
• I think it will work quite naturally if we allow route data with nested routes (#3):

  (def routes
  [{:middleware [do-something]}
   [admin? {:middleware [admin-middleware]}
    ["/private" #'private-handler]]
   [(constantly true) {:middleware [public-middleware]}
    ["/public" #'public-handler]]])

• Gah, a breaking changes so soon!
  • This has made me realise this is really alpha software and I should tell people to expect breaking changes