caching-strategies_skill

This skill helps you implement Rails caching patterns to boost performance with fragment, Russian doll, and low-level caching strategies.

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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational