Caching datastore records on the client makes lists and detail pages instantly available, even offline. But not every datastore makes sense — some are too big, some change too fast, some contain sensitive data that shouldn't sit in browser storage.
What to Consider per Datastore
- Size: A 5,000-row catalogue caches fine. A 5,000,000-row event log doesn't.
- Volatility: A products list is stable; a live order queue isn't.
- Sensitivity: Customer PII may not belong in client storage at all.
- Use pattern: Frequently re-accessed records benefit; rarely-touched ones don't.
Datastores That Cache Well
- Reference / lookup tables: Countries, currencies, tax rates, service codes. Small, stable.
- User's own records: Their profile, preferences, recent jobs. Highly relevant to that user.
- Today's data: Today's bookings, today's tickets. Bounded size, instantly useful.
- Recently-viewed: Last 50 records the user has opened — they're likely to revisit.
Datastores Not to Cache (Default)
- Audit / event logs.
- Other users' personal data (privacy).
- Large product catalogues with rapidly-changing inventory.
- Encrypted-at-rest sensitive data (only cache if cache itself is encrypted).
Worked Examples
- Field service app: Cache today's jobs, the assigned customer addresses, common service codes. Don't cache the full customer base.
- CRM: Cache user's own pipeline records and recently-opened contacts. Don't cache all contacts.
- POS app: Cache full product catalogue (small enough), don't cache transaction history (privacy + size).
- Healthcare: Cache today's patient list with name + appointment only. Full medical records require online access (privacy + audit trail).