sandstrom
commented
1 year ago Piggy-backing on ActiveSupport::Cache sounds like a good idea. Mostly to avoid maintaining that code ourselves.
However, if it was up to me (which it isn't! 😄) I wouldn't spend time on Redis caching or anything advanced (SSR etc).
A static site builder doesn't care much about caching, since build-time performance isn't much of a factor (Bridgetown is already quick enough for development, and in production it's all static files anyway). I know there is an SSR angle, but most people aren't using Bridgetown for SSR anyway, so I wouldn't invest too heavily in that area right now.
jaredcwhite
Summary
Replace Bridgetown's Jekyll-derived cache subsystem with AS's caching infra, bringing Bridgetown in line with Rails' caching strategies.
Motivation
Our current cache feature is extremely simplistic — it's in-memory/on-disk only, there's no expiration feature, and it doesn't support any other caching strategies such as Redis. The API doesn't particularly align with any other Ruby project.
With the new system, caching in both Bridgetown and a Roda-powered backend can offer a robust solution that is still easy to use but will scale with application size and ambition. We can also invest more thought-leadership into Ruby template-based caching strategies to lower build times which is common in Rails applications.
Rollout Strategy
We can swap out the subsystem while maintaining a compatibility layer in case any existing plugins out there need to utilize the cache. That way there's no major ecosystem disruption.