Caching

Zwei Strategien

Art	Caching	Invalidierung	Konfiguration
Single Entity	Automatisch	Automatisch bei Write	Default an
Listen	Explizit	Explizit (invalidateOn)	Opt-in pro Handler

Single Entity: Automatisch

Jeder Read eines einzelnen Entities wird in Redis gecached. Bei Write auf dieselbe Entity wird der Cache invalidiert.

// Automatisch — kein Code vom Entwickler:
r.queryHandler("order.detail", ...);
// → GET: Cache Key "tenant:42:orders.order:123" pruefen
// → Miss: DB Query, Ergebnis cachen
// → Hit: aus Redis, kein DB Query

// Bei Write auf Order 123:
r.writeHandler("order.update", ...);
// → Cache Key "tenant:42:orders.order:123" invalidieren

Cache Key Schema: tenant:{tenantId}:{featureName}.{entityName}:{entityId}

Listen: Explizit

Listen-Queries sind komplex (Filter, Cursor, Rollen, Ownership). Caching nur wenn explizit konfiguriert:

r.queryHandler("order.list", schema, handler, {
  cache: {
    ttl: 30,  // Sekunden
    invalidateOn: ["order.create", "order.update", "order.delete"],
  },
});
// → Ohne cache Option: kein Caching (Default)

TTL

Typ	Default TTL	Ueberschreibbar
Single Entity	300s (5 Min)	Ja, pro Entity
Listen	Kein Default	Muss angegeben werden

Global deaktivieren

createApp({
  features: [...],
  cache: false,  // Kein Caching (Dev/Debug)
});