@mkvlr Which use-case do you have in mind for the "persistent cache" functionality ? From my experience it seems to be "very difficult" to guarantee that all forms get persistent successfully via nippy. -> (most ???) things will therfore be re-evaluated after JVM restart one-time (and then they are in the in-memory cache), as most forms depend on each other in some way.

anything that takes more than a few seconds to run. The ease or difficulty of this is largely context dependent I think. When you build up data structures or indices out of pure clojure data as is the case with most code we’re writing this works like a charm.

Yes, indeed, you are right. But "pure data" is then a kind of "key requirement" of the persistent caching. My current use case is "99% pure data" (with 2 functions deep inside the pure data) -> I will try as well to re-think my use case for ways to remove the 2 functions. I think it is important to have logging which explains "what failed to get cached".

Can we have this as a top level function in Clerk ? Like "clear-in-memory-cache!" ?

(reset! webserver/!doc {})

and maybe rename clear-cache to clear-persistent-cache ? So to communicate the 2 layers of caching and a clean way to clear both.

clear-cache! should just wipe the in memory cache as well I think

yes, maybe.

Not sure, if we need to differenciate.

Probably it should do both, just meaning "clear it all !"

https://github.com/nextjournal/clerk/pull/86

Beautifull !!