Caching
When and how to cache responses on the client.
Caching
This page lives inside a nested navigation group (Concepts → Patterns → Caching). Use nested groups in docs.json to organise long sections —
the sidebar collapses them by default and remembers your selection in
the URL.
When to cache
- The response is expensive to compute.
- The data doesn't change often (or you can invalidate on writes).
- The freshness requirements tolerate a short TTL.
What to cache
Public, idempotent reads. Never cache requests that depend on the authenticated user unless you key the cache on the user id.
How long
Short TTLs (30s–5min) handle most cases. For data that changes via writes you control, prefer event-driven invalidation over time-based expiry.