- Home
- Skills
- Thibautbaissac
- Rails Ai Agents
- Caching Strategies
caching-strategies_skill
269
GitHub Stars
1
Bundled Files
3 weeks ago
Catalog Refreshed
2 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstart where the catalogue uses aiagentskills.
npx veilstart add skill thibautbaissac/rails_ai_agents --skill caching-strategies- SKILL.md10.7 KB
Overview
This skill implements Rails caching patterns to improve application performance and reduce DB work. It provides concrete patterns for fragment and Russian doll caching, low-level caching, HTTP caching, memoization, and cache invalidation. Use it to standardize cache keys, TTLs, and invalidation strategies across a Rails 8.1 app.
How this skill works
The skill inspects view partials, models, service/query objects, and controller actions to recommend where to apply fragment, collection, and low-level caches. It suggests cache stores and configuration for environments, generates safe cache keys and namespacing, and outlines invalidation techniques like touch: true, manual deletes, and time-based expirations. It also provides testing and monitoring guidance for hit/miss visibility.
When to use it
- Rendering expensive partials or lists that rarely change
- Optimizing nested content with Russian doll caching
- Caching expensive query results or aggregated stats
- Designing cache invalidation after model updates
- Adding HTTP cache headers or ETag/Last-Modified support
- Writing tests that assert cache behavior and invalidation
Best practices
- Prefer stable cache keys that include model id and updated_at or explicit version tokens
- Use touch: true on child models to cascade invalidation in Russian doll patterns
- Choose a cache store appropriate for environment (memory for dev, solid_cache_store or Redis for production)
- Keep TTLs conservative for dynamic data and use manual invalidation for critical updates
- Namespace keys per account/tenant and use delete_matched only with supported stores (Redis)
- Instrument cache reads/writes to monitor hit/miss rates and guide tuning
Example use cases
- Wrap an expensive event partial: cache event do ... end to avoid repeated rendering
- Cache dashboard aggregates in a service with Rails.cache.fetch and an account-scoped key
- Render a collection with cached: true so each item reuses its fragment cache
- Add touch: true to comments so updating comments invalidates the parent event fragment
- Use stale?(etag: ..., last_modified: ...) in controllers for 304 responses and CDN-friendly caching
FAQ
Use Redis when you need a shared, fast cache across processes or machines. solid_cache_store is fine for simpler deployments where a DB-backed store is acceptable.
How do I handle per-user content in view caching?
Include user-specific context in the cache key (for example [record, current_user]) or avoid fragment caching for user-personalized regions and use client-side techniques.