Fork me on GitHub
Dave Simmons08:03:40

Does anyone have an example of a Duct project that allows both secure and insecure routes. I know you have have a route specific middleware which I think would do this but is there a way to group routes together for specific middleware (rather than a route by route basis)?


If you have the routes v1/secure And v1/insecure You could place the specific Middleware on secure and insecure routes. The shared Middleware could go on v1. Not sure if that's what you mean though

Dave Simmons09:03:38

Hi @kevin.van.rooijen - would I then be able to define v1/secure/foo v1/secure/boo ? not quite sure how that works in config.edn.

Dave Simmons09:03:26

I'm new to ataraxy so I'm assuming you can define a route with various middleware and have subroutes "inherit" that middleware?


Something like this I think

Something like this I think,
{:middleware {:middleware/global #ig/ref :my-app.middleware/global
              :middleware/secure #ig/ref :my-app.middleware/secure
              :middleware/insecure #ig/ref :my-app.middleware/insecure}
   {"/foo" [:my-app.handler/secure-foo]}

   {"/boo" [:my-app.handler/insecure-boo]}}}}


Ah I switched the boo / foo, but you get the idea


Basically anything under /v1 will use :middleware/global.


anything under /secure will use :middleware/secure. anything under /insecure will use :middleware/insecure.

Dave Simmons09:03:37

@kevin.van.rooijen - perfect - many thanks for this. Appreciate the help.


You're very welcome 😄

Dave Simmons18:03:28

Hi @kevin.van.rooijen - a follow up question if I may. Where or how would I define multiple middleware to call. In the example above I'd like :middleware/global to call middleware-1 and middleware-2. Is that possible in EDN or would I have to define that in my-app-middleware-global ig/init to return multiple middleware functions? (hope this makes sense :-))


You can replace ^:middleware/global with

^{:middleware/global true
  :middleware/global2 true}


^:some-key is shorthand for ^{:some-key true}


It being just metadata in Clojure


Note however that middleware take order based on name. So if order matters, you'll either have to name them in an ordered way, or you have to create your own middleware init-key that combines multiple middlewares in order

Dave Simmons18:03:56

Ah thanks - especially about the name order.


iirc it's backwards. so :z/my-middleware will eval before :a/some-middleware


But I might be wrong

Dave Simmons18:03:41

I quite like the explicitness of

Dave Simmons18:03:03

:routes {[:get "/foo"] ^:middleware/global ^:middleware/insecure {[:get "/boo"] ^:middleware/secure [:middle.handler.middle/index]}}}

Dave Simmons18:03:42

I know the example here doesn't make sense but it was just as an illustration.


Yeah it's an interesting way of tackling this issue

Dave Simmons18:03:35

Do you know if there is a "clojure" or "duct" best practise for this - would it be better to return multiple middleware in the ig/init function definition - my problem with this is that it kind of hides the intent of the EDN.


This isn't really a duct or clojure thing. It's pure ataraxy


And I'm not sure how to solve this properly. We use the namespace as a prefix. So :aaa/middleware1 :bbb/middleware2 etc

Dave Simmons18:03:09

Ah right. I must confess I think I prefer reitit to ataraxy so might have a play with that and duct.

Dave Simmons18:03:25

All the same thanks very much for your help on this.


There's a duct-reitit implementation, you could take a look at that

Dave Simmons18:03:21

fantastic - I was thinking to myself - how the hell am I going to implement reitit in duct. Perfect!