Fork me on GitHub

Question about the REPL workflow: I'm using integrant/integrant.repl, and reitit ring; I've got jetty running as part of my integrant system using a handler that is provided by a different integrant component which is being produced with ring-handler. This seems to work just fine, but whenever I make a change to my ring router definitions - for example to change a spec used for the coercion of the request body, it requires that I do a full system reload. That is fine and expected given how I've got everything wired up. Is there a better way to set things up such that I don't need a full system restart when I modify one of my route configs?


I'm pretty new to the clojure repl workflow / reitit


Hey! Here is an simple example of a reitit friendly setup Let me know if this helps 🙂


I think the #'app in the run-jetty call might be where I'm going wrong


In my integrant component that creates my handler, I am returning the result of a function called make-app that itself just calls ring/ring-handler . So, I am returning a function that is effectively a closure of all my ring/routes config I guess.


That example would also require me to ig-repl/reset if anything changed in the handler setup (edit: or at least I think it would, I've not tried to run it)


> I think the #’app in the run-jetty call might be where I’m going wrong Yes, the #'app bit is key.


I think the integrant example you linked is a bit overkill.


What I would say is try the gist I provided and the only thing that needs to become a part of your integrant system is the (def server (jetty/run-jetty #'app {:port 3000 :join? false}))) call. From there, your routes should be reloadable.


Integrant tip: avoid breaking up your system too much, too early.


I have my handler integrant "component" dependent on my database component as I need (or I think I need) to inject that into my handler component so I can provide it to requests via middleware


This is why I say avoid breaking up the system too early 😉: Makes it harder to see some of the options:

(defn wrap-handler 
  [handler options-map]
  (fn [req] 
    (handler (assoc req :options options-map)))))

(def server 
    (wrap-handler #'app {:db your-db-conn-here})
    {:port 3000 :join? false})))


With the above, you can now pass options-map anywhere you want…and not just the routes, but whoever else needs them.


what you're saying does make sense


I'll give removing that db dependency a try and see if I can't wrap a handler ref with it instead. Thanks