releasing talks can be delayed for a number of reasons, and it's been less than three weeks

Any experiences with clojure static site generator like Cryogen, Statis, Perun... ?

I've used perun. Depends on how you like to work, I chose perun because I wanted looser transforms I could combine to build my site the way I prefer. Cryogen for sure and Stasis (if I remember right) have stronger opinions on how the site is structured and assembled.

Cryogen is great for a blog style site, really easy to setup last time I used it

Stasis is way more flexible - the Strange Loop web site is a stasis site and we generate a slew of pages from csv data rather than from text

Oh looks like I remembered Stasis incorrectly. It's a bit more like perun but without the boot tasks and more of a static site gen API (might be nice to combine with clj/deps.edn)! I had confused it with Misaki. Sorry about the misinformation.

@alexmiller if i recall correctly, http://clojure.org is powered by jbake?

yes

no regrets on that - it's been great for our needs there

Okay 🙂

@romain What kind of site are you planning to build?

@jayzawrotny Just a showcase website, but I would like to easily add some news in the front page.

I see, in that case, cryogen would probably be fairly straight forward mostly requiring you to customize the templates which could be a pretty quick build. Stasis and perun could work but may take a bit more time to build up the tooling to organize the site the way you would like.

I could build it with shadow-cljs & reagent/reframe too, and later make a backend if I want to extend it

That could work for sure, but that may miss out on some SEO from not having separate HTML pages generated (assuming you would build a SPA). Though that could be worked around by having the content always available in the HTML template and using re-frame to toggle which portion is visible as a "page".

Yeah that's a SPA issue 😕

I never gave a look in SEO world, maybe it would be easier to integrate some with a front routing lib?

If you're considering adding a backend later then perun and stasis are better options. In the case of perun you would have a task fetch content from an API using a request lib that would add to the boot fileset during the build stage. Stasis could work well for that too but may require a bit more tooling to set that up but on the plus side you would get to choose how to model that process whereas with perun you would be working with boot task and fileset abstractions.

It seems to be a good compromise

How far do people stretch the definition of "caching"... I'm making something which needs to check a database for a query. If no data exists for it, transform the query to a different format that can be made to another external data source, get results, process those results a bit, then save them in the database so that next time I can just return the data in the first step. Depending on the query, some results do "expire" and need to be re fetched after some time. The queries are more complicated than simple key/value check, such as checking if a query time interval is a subset of an existing time intervals in the db. I could make this work by implementing the clojure.core.cache protocols. Is this a bad idea in practice or philosophically? Is it better to just use my own similarly named things?

I realize it doesn't matter much if I implement these protocols or not if the functionality is the same, just kind of wondering if this fits under what people usually classify as "cacheing"

@jjttjj Bear in mind that the core.cache protocols assume an immutable cache (mostly) that you would keep inside an atom...

i have a huge horse in this question race and will answer from a general perspective (not core.cache as @seancorfield is much more invested there), but I'm making cassoulet so give me a bit.

...so I'm not sure that makes sense in your case.

and I'm thinking greater-than-individual-system caching here.

I don't feel particularly qualified on this topic but who is responsible for this project? If it's open-source or a big dev team, then modeling it in a lowest-common-denominator context may be worth it. If it's a small, personal project then if stretching the existing cache protocols do fit the use case, why not?

Yeah, if you're using the database as a cache of some other external system, I'm not sure how much core.cache helps you.

the point of caching is cheap access, be it computationally, on the network, storage, etc.

when you say time based caching, what you really mean imo is indexing.

but what you get on good indexing is a set of keys that you can then grab from an even faster cache than your library/db can provide.

so indexing -> set of keys -> ask for all of those keys -> maybe get them from a cache

but really the question that's most important is.

what are your access patterns?

rick houlihan has an awesome talk about access patterns (in the context of dynamodb design): https://www.youtube.com/watch?v=HaEPXoXVf2k

and much like dynamodb should be designed around access patterns, caching follows the same patterns.

s/same/similar

So basically I need to request data for a given key within a time interval... it gets tricky because when I request a "big" time interval, I want to figure out the missing time intervals and go fetch those from the external source.

so it's basically key:value then time slice?

thanks for the vid i'll check that out

(don't wanna push on the core.cache point too much but isn't the immutable case only true for the pre-packaged implementations, but couldn't someone implement the CacheProtocol on top of a database or am I missing something?)

it's not missing anything at the level I'm assuming your question is at.

but there's levels of caching, and one of those is key caching.

CacheProtocol starts at the key level and builds a good foundation on higher levels of caching.

and that protocol might implement steps 3 and 4 of what I outlined.

or step up and build a wrapper around that for a CacheProtocol around time, but next question is if that's worth it for the access pattern.

that said, you can build access patterns around keys to data

and an access pattern around time to keys.

@jjttjj Yes, you could implement the cache protocol on top of a database but the protocol API is very hashmap-like, and if you wrap one cache in another, everything assume hashmap-like behavior -- and as @gerred says, what is your access pattern? Is it really treating the data as a hash map with key-based access? It doesn't sound like it to me.