A complete client cache key
useQuery({
queryKey: ['tickets', { status: 'open', page: 1 }],
queryFn: () => ticketsApi.list({ status: 'open', page: 1 }),
});Every result-affecting input appears in both the key and request.
Topic
Definition
Caching stores a reusable response or rendered result so later equivalent work can avoid repeating a request or computation.
In simpler words
A cache is a speed tool with freshness rules, not another source of truth.
Next server caches and TanStack Query’s browser cache solve different problems and must not be confused.
Next caching concerns server-rendered work and its fetch or route output policies. TanStack Query caches representations that a browser client has requested from Nest.
A cache key is a statement of identity. If a ticket list changes when status changes, the status belongs in the Query key; otherwise one filter can show another filter’s cached result.
useQuery({
queryKey: ['tickets', { status: 'open', page: 1 }],
queryFn: () => ticketsApi.list({ status: 'open', page: 1 }),
});Every result-affecting input appears in both the key and request.
// Wrong — "closed" can reuse an "open" list
queryKey: ['tickets']
// Right
queryKey: ['tickets', { status, page }]A cache cannot distinguish results you do not identify.
Definition
Freshness policy decides when cached work may be reused and when new work is required.
In simpler words
Shorter freshness improves recency; longer freshness reduces repeat work.
Begin conservatively for product data whose correctness matters more than avoiding a request.
Measure a real problem before adding cache complexity or a second client-side copy of server data.
Live playground
Change a filter and inspect which part of the key must change.
Query cache: stale
Next revalidatePath/tag is for Next server caches — not Nest auth.
Test
At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥ 80% (enforced by the API) to save progress.
Checking your session…
10 questions · concept 3 · syntax 2 · practical 3 · logic 2