Skip to content
RevoGrid [Pro]

Caching And Cache Keys

In server-side Pivot, caching is critical for performance and cost management. Analytical queries can be expensive and slow; deduplicating identical requests ensures that the backend only performs the work once.

RevoGrid Pivot uses deterministic cache keys to identify identical analytical windows.

What Is A Cache Key?

Section titled “What Is A Cache Key?”

A cache key is a unique string that represents the exact state of an analytical request. If any part of the request changes (filters, grouping, viewport, or data version), a new key is generated.

This allows both the client-side HttpPivotRemoteStore and your backend analytical engine to:

  1. Deduplicate: Prevent multiple identical requests from hitting the database simultaneously.
  2. Memoize: Return previously computed results for the same analytical window.
  3. Invalidate Safely: Ensure that if the underlying data or field definitions change, old cached results are never shown.

Key Components

Section titled “Key Components”

A stable Pivot cache key is composed of several semantic layers:

| Component | Description | Why It Matters | | :--- | :--- | :--- | | tenantId | Identifies the client or organization scope. | Prevents data leakage between different users/tenants. | | viewId | Identifies the specific analytical view or dashboard. | Keeps caches separate for different reports using the same fields. | | fieldsVersion | A checksum or version of the field registry. | If you change a field's calculation or data type, old summaries must be invalidated. | | datasetWatermark | A timestamp or batch ID representing data freshness. | Automatically invalidates the cache when new data is loaded into the warehouse. | | request | A stable stringification of filters, rows, columns, and windows. | Ensures that changing a single filter or scrolling the viewport yields a specific key. |

How Keys Are Generated

Section titled “How Keys Are Generated”

RevoGrid provides a standard createPivotCacheKey utility that builds these keys. It uses a stable stringification algorithm, meaning that the order of keys in a JSON object does not change the resulting string.

// Internal logic simplified
const cacheKey = `pivot:${tenantId}:${viewId}:${fieldsVersion}:${datasetWatermark}:${stableStringify(request)}`;

Stable Stringification Example

Section titled “Stable Stringification Example”

Even if the UI sends filters in a different order, the cache key remains the same:

// Request A
{ filter: { region: 'US', category: 'Tech' } }


// Request B
{ filter: { category: 'Tech', region: 'US' } }


// Both result in the same stable key:
// "...:{"category":"Tech","region":"US"}"

Observing Cache Status

Section titled “Observing Cache Status”

When using HttpPivotRemoteStore or the recommended backend response format, the grid receives cache metadata in the meta object:

{
  "data": [...],
  "meta": {
    "cacheKey": "pivot:tenant-1:sales:v1:20240424:...",
    "cacheStatus": "hit", // or 'miss', 'warm', 'bypass'
    "elapsedMs": 12
  }
}

This is useful for UI diagnostics and understanding whether your analytical engine is performing efficiently.

Best Practices

Section titled “Best Practices”
  • Keep viewId Stable: Do not use random IDs for views if you want users to benefit from shared caching across sessions.
  • Update datasetWatermark: Your backend should provide a watermark (like a max(updated_at) or a batch ID) to the client so the cache key updates automatically when data changes.
  • Normalize Requests: If you are implementing a custom PivotRemoteStore, ensure you normalize filters and descriptors before generating keys to maximize cache hits.

Next

Section titled “Next”