Caching is safest when its scope is explicit. Jeston separates process-local response caching from application data caching and makes private data require a variation key.
Response caching for rendered output
The local ResponseCache supports TTLs, fresh reads, stale-while-revalidate, concurrent-miss deduplication, tags, tag invalidation, path invalidation through invalidatePath and revalidatePath, an entry limit, and basic counters. It is process-scoped and disposable, which makes its boundary clear.
In a multi-instance deployment, a process-local cache should not be mistaken for a distributed cache. Use a distributed adapter when instances need to share cached data.
Data cache scope
createDataCache accepts a CacheAdapter and makes scope explicit: request, public, or private. Private entries require a varyKey, preventing accidental sharing between users. That requirement turns a dangerous implicit assumption into a visible API decision.
Development versus production
A process-local memory cache is useful during development and testing. Production applications may choose Redis or another distributed implementation, depending on consistency, topology, and failure requirements. The framework provides the contract; the application chooses the operational behavior.
Cache correctness is more than speed
A cache design must answer what can be shared, how entries are invalidated, what happens during a miss, and what happens when one instance does not have another instance's memory. Jeston's small interfaces and explicit scopes make those questions part of the implementation rather than documentation folklore.
Explore the cache contracts in github.com/kvantjs/jeston.
Top comments (0)