https://clojurians.slack.com/archives/C68M60S4F/p1661965659644209

Ok so this basically boils down to a macro that offloads code from defmutation body into a separate defn so when namespace gets reloaded, the new defn gets called

An alternative approach that works for me is integrant. In general, my resolvers are usually very thin wrappers around a range of different services, so in the end, I often need to both restart those services AND reload the lists of resolvers. As such, I simply use integrant to stop and start everything, and it takes only a few moments, and I know everything is registered properly. e.g. see my integrant configuration: the potentially dynamic list of resolvers https://github.com/wardle/pc4/blob/738fbb9c9d42ec7c3af78aab45ef5267a84fe63f/pc4-server/resources/config.edn#L112 the pathom environment: https://github.com/wardle/pc4/blob/738fbb9c9d42ec7c3af78aab45ef5267a84fe63f/pc4-server/resources/config.edn#L122 the aero reader for referencing integrant components https://github.com/wardle/pc4/blob/738fbb9c9d42ec7c3af78aab45ef5267a84fe63f/pc4-server/src/com/eldrix/pc4/system.clj#L139 [for components that generate resolvers dynamically] and the aero reader for referencing resolvers listed in clojure namespaces: https://github.com/wardle/pc4/blob/738fbb9c9d42ec7c3af78aab45ef5267a84fe63f/pc4-server/src/com/eldrix/pc4/system.clj#L142 so I can be explicit in the list of resolvers to register.

I'm sure you could do the same with some other component library. And you can usually map a hotkey to do the 'stop','load namespace','start' to make it very quick and easy.

I normally use a 0-arity defn instead of a def to hold the collections of resolvers. Then when I create a Pathom index I call each defn and pass the result to pci/register. I'm not sure if this becomes performance intensive to rebuild the index every time a resolver changes, but in my experience with ~10s of resolvers its basically instant.

I pass in a 0-arity function that returns the actual pathom-env to any pathom interface functions. (ie. (boundary-interface (parser-env-fn)) instead of (boundary-interface parser-env)) If all the resolver collections are written as functions (vs cached defs), then you will always have up-to-date parsers. The only issue is performance, since you do not want the indexes to be parsed and rebuilt with every request. I solve this problem with a configuration flag:

(if (:reload-on-request? cfg)
  (fn [] (new-parser-env-fn))
  (constantly (new-parser-env-fn)))

that’s very nice