This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-03-07
Channels
- # announcements (20)
- # babashka (25)
- # beginners (48)
- # biff (26)
- # calva (5)
- # cider (3)
- # clara (7)
- # clerk (7)
- # clj-kondo (61)
- # cljdoc (3)
- # clojure (6)
- # clojure-austin (1)
- # clojure-conj (8)
- # clojure-europe (58)
- # clojure-nl (1)
- # clojure-norway (4)
- # clojure-poland (1)
- # clojure-uk (9)
- # cursive (2)
- # emacs (11)
- # fulcro (8)
- # graphql (14)
- # gratitude (6)
- # humbleui (10)
- # hyperfiddle (17)
- # integrant (15)
- # introduce-yourself (1)
- # leiningen (5)
- # malli (13)
- # meander (21)
- # nbb (11)
- # off-topic (15)
- # pedestal (15)
- # polylith (15)
- # quil (28)
- # rdf (2)
- # reitit (3)
- # releases (6)
- # sci (21)
- # shadow-cljs (38)
- # spacemacs (3)
- # xtdb (6)
I'm looking for ways to to manage application state that will change during runtime based on certain triggers like: - recreating/recompiling ring handlers with reitit - recreating temporary databases - flushing and rebuilding file/memory caches I'm looking at both mount and integrant to achieve this. I really like integrant so far. It even has an API for doing this (with examples!) with suspend/resume. The README warns us like so: > Note that we only need to go to this additional effort if retaining open resources is useful during development, otherwise we can rely on the default init and halt! behavior. In production, it's always better to terminate and restart. I could also just use other patterns. Like passing around functions that dereference the current state of the above things instead of using suspend/resume. But at the same time it seems like suspend/resume does what I need, judging from the examples.
will all of these triggers happen during development time?
I have a temporary database that gets destroyed and recreated during runtime somewhat frequently
ah okay, i see. what we do in this instance is just restart all systems, by calling halt!
and then prep
+ init
. our system startup is fast enough that this is a pretty good enough solution
that may not suit the runtime situation you have, if you want other systems to be available during the recreation of system state
I need to maintain some websocket connections during all of this so I might not use a full restart
ah yeah no then full restart won’t work sadly. suspend + resume will work, just takes a tiny bit more thought than the brute force restart approach 😄
but thinking about it, I actually should first test your suggestion. It seems more sane.
its a lot simpler, but also our systems are pretty vanilla. some web handlers and a connection to Datomic. nothing too special
its nice because you can use the ‘restart’ workflow both locally and in production. its also great for local, when you want to reset the world but don’t want to wait for JVM startup
thank you for the advice. I might actually have to try the different approaches and see what each gives me!
sure thing. feel free to ask for anything else. we’ve gone pretty far with Integrant, and are really happy with the lib and what we can do with it