Eliminates the per-request DB hit when:
- A user opens a tab they've recently visited (within 30s)
- The 30s AutoRefresh fires while no mutations have happened
- Multiple browser tabs are open and switch between Accounts/Users
- A passing-by request races another request for the same data
How it works:
- web/lib/api.ts: fetchApi() now forwards the next.revalidate/tags
options to Next.js's data cache. getAccounts/getUsers tag their
responses ('accounts'/'users') with a 30-second freshness window.
- web/app/actions.ts: every mutation (update/create/delete X 2 tables)
calls revalidateTag() so the next GET for that table bypasses the
cache and re-reads from MySQL. Stale data never lingers after a write.
The cache lives in the cm-web Node process (per worker). For our
2-worker setup that's at most 2 cached copies; the next AutoRefresh
tick after the 30s window expires triggers exactly one DB read per
worker. If the operator manually clicks Refresh, that's a router.refresh
which also re-fetches.
Tradeoffs:
- External DB writes (e.g., the cm99.net monitor inserting a row) won't
appear in the dashboard until the 30s window elapses or a mutation
happens. The previous behavior had a 30s ceiling too (auto-refresh
interval), so the perceived freshness is unchanged.
- Memory: each cached payload is a few KB to a few hundred KB. Trivial.
If you want stricter freshness later, drop CACHE_REVALIDATE_SECONDS in
web/lib/api.ts. If you want pagination on top of this, the cache key
becomes per-URL automatically, so /acc/?offset=200 caches separately
from /acc/?offset=0 — no further work needed.
yiekheng
549e9b5939