epic-caching_skill

This skill helps you implement and manage caching with cachified, SQLite and LRU caches to boost Epic Stack performance.

3

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 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 veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill rubenpenap/epic-stack-agent-skills --skill epic-caching

  • SKILL.md13.4 KB

Overview

This skill provides practical guidance and utilities for caching in Epic Stack using cachified, a persistent SQLite cache (replicated with LiteFS), and an in-memory LRU cache. It focuses on when to cache, how to structure keys and TTLs, stale-while-revalidate patterns, validation with Zod, and safe invalidation patterns. The goal is measurable performance wins with minimal complexity.

How this skill works

The skill explains using @epic-web/cachified as the unified API that delegates to either the SQLite cache or an LRU in-memory cache. Use SQLite for persistent, replicated data and LRU for short-lived deduplication or temporary values. It shows how to define keys, TTL, stale-while-revalidate, and checkValue validation using Zod. It also covers server timing integration and multi-region write guarantees via ensurePrimary().

When to use it

  • Cache expensive external API calls or slow queries that are called frequently.
  • Return stale data immediately while revalidating in the background (SWR) to improve UX.
  • Deduplicate simultaneous requests or store very short-lived values using LRU.
  • Persist infrequently changing data across restarts and instances with SQLite/LiteFS.
  • Invalidate related caches after mutations or when underlying data changes.

Best practices

  • Measure performance before adding cache; avoid caching without clear benefit.
  • Use concise, descriptive keys like entity:identifier:data and avoid special characters.
  • Validate cached data with Zod (checkValue); fetch fresh data if validation fails.
  • Prefer short TTLs and use staleWhileRevalidate for safe background refreshes.
  • Invalidate specific keys after mutations and search/delete matching keys when needed.
  • Use ensurePrimary() before writes in multi-region setups to guarantee replication.

Example use cases

  • Cache GitHub events for a username with a 1-hour TTL and 24-hour SWR to reduce API calls.
  • Cache aggregated user stats from Prisma for 5 minutes and revalidate in the background.
  • Deduplicate identical outgoing fetches for 1 second using an LRU or request map.
  • Invalidate user-related caches after creating or updating a note (delete relevant keys).
  • Use SQLite cache for feature flags or scheduled-event lists that change infrequently.

FAQ

Use LRU for very short-lived, in-memory deduplication or temporary values; use SQLite (with LiteFS) for persistent, replicated cache that must survive restarts.

What if cached data fails validation?

cachified will fetch fresh data if checkValue (Zod) fails. Always validate cached data to avoid serving corrupt or outdated shapes.

How do staleWhileRevalidate and TTL interact?

TTL defines when cached data is fresh. staleWhileRevalidate extends how long stale data can be returned immediately while a background refresh is attempted. Beyond that window, the system waits for fresh data.

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