Offline Cache

The offline cache works out of the box, but tuning it for your specific app makes a real difference. This article shows the controls.

Settings

• Total cache size: Maximum disk usage. Default 50MB; up to 500MB depending on user's device.
• Per-asset cache strategy: Cache-first, network-first, stale-while-revalidate.
• Cacheable API endpoints: Tick which endpoints' responses to keep.
• Cacheable datastores: Tick which list views and records get persisted.
• Pre-fetch on sync: Define what to fetch proactively (e.g. today's jobs every morning).
• Stale tolerance: How old before cached content is considered too stale.

Tuning by Use Case

• Read-heavy app: Aggressive caching, larger cap, longer stale tolerance.
• Real-time app: Light caching, short tolerance — fresh data matters.
• Mobile-bandwidth-conscious: Pre-fetch only on Wi-Fi; smaller cap.
• Field worker app: Pre-fetch today's work in the morning; expand cache cap; long stale tolerance.

Worked Examples

• Documentation site: Cache everything aggressively. Users frequently re-read articles.
• Live trading app: Cache nothing dynamic. Stale prices are worse than no prices.
• Field service: Pre-fetch each technician's jobs and customer addresses; cache route maps; tolerate 24-hour staleness for the customer's account history.
• Marketplace browser: Cache product images and recent search results; revalidate on every visit.

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).