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.

Use aggregationSemantics: 'server' to pin plugin/controller execution to the trusted backend. A pin prevents accidental engine switching; it does not guarantee identical local/server results. Choose null, count, distinct, totals and precision policies in the backend contract and validate them against independent facts. For local analysis, use the V2 numeric/scalar aggregation configuration.

What Is A Cache Key?

Section titled “What Is A Cache Key?”
Interactive example

Caching and cache keys

Dedupe concurrent signal-free requests; signalled requests independent; no completed browser cache

The example loads when visible.

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.

HttpPivotRemoteStore shares identical in-flight, signal-free reads. Once a request settles, its entry is removed; a later call fetches again. Calls with an AbortSignal use independent transports so cancelling one caller cannot cancel another caller’s request. The store does not cache completed results.

Your backend or application cache can use these keys to memoize completed results. It owns expiration and invalidation when data, permissions, or field semantics change. The cacheStatus returned by the backend reports that cache’s outcome; it does not prove a browser cache hit.

Key Components

Section titled “Key Components”

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

ComponentDescriptionWhy It Matters
tenantIdSeparates keys for the client or organization scope.Backend authentication and authorization must independently enforce tenant access.
viewIdIdentifies the specific analytical view or dashboard.Keeps caches separate for different reports using the same fields.
fieldsVersionA checksum or version of the field registry.If you change a field’s calculation or data type, old summaries must be invalidated.
datasetWatermarkA caller-supplied timestamp or batch ID representing data freshness.Changing the value separates keys; your cache owns expiration and invalidation.
requestA stable stringification of filters, rows, columns, and windows.Ensures that changing a single filter or scrolling the viewport yields a specific key.

The HTTP store’s tenantId and datasetWatermark options affect its client key. They are not automatically added to request bodies or headers. Use the existing authProvider or an application-owned transport for authenticated routing, and resolve tenant access and data freshness on the server. Recreate the store when its constructor-level key scope changes.

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”

Object property order does not change the key. Array order remains significant, including boolean filter trees; this helper does not normalize semantically equivalent predicates. These objects illustrate stable serialization, rather than the tuple-based PivotFilterExpression transport grammar:

// 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”