Caching
A page load in Rebask can involve several cache boundaries. The server may reuse rendered HTML, RSC payloads, or data, while the client router may cache route segments for faster navigations. These caches are related, but they store different values and are not interchangeable.
| Cache | Stores |
|---|---|
| Page Caching | Rendered HTML and PPR shells |
| RSC Caching | Server-rendered RSC payloads and shells for pages and layout segments |
| Caching in Server Components | "use cache" results, durableCache data |
| Segment Caching | Rendered route segments and RSC shells retained by the client router |
All server caches use the same APIs to set lifetimes, attach tags, and trigger revalidation.
The client router has separate APIs to control the freshness, tags, and revalidation of route segments it retains in the browser, whether they arrive with the initial page, through prefetching, or during a later request.
Server Cache keys
Page, RSC, and "use cache" entries are scoped to a
deploymentId, which is a way of saying they differ
between builds:
| Cache entry | Logical key |
|---|---|
| Page cache entries | Multiple ph:<deployment-id>: keys |
| Page or layout RSC | pr:<deployment-id>:<pathname> |
| Page or layout RSC shell | ps:<deployment-id>:<route-file> or ps:<deployment-id>:<route-file>:<pathname> for an individual page shell |
"use cache" function | du:<deployment-id>:<function-id>:<encoded-arguments> |
durableCache data | dd:<source-hash>:<args-hash>:<deps> |
Every key starts with a two-letter tag whose first letter is p for a page's HTML or RSC payload and
d for runtime data. A cache handler can tell them apart with isPageCacheKey
from @rebask/core/cache.
We call it deploymentId because it identifies the active deployment across the server and
client. Rebask uses it to namespace cache keys and provide skew protection,
allowing the client to detect when it is communicating with a different deployment.All server cache keys except those created by durableCache include deploymentId because their
values are tied to the build that produced them. A new build can invalidate those values in several
ways:
- It can change route or component code, environment variables, module IDs, client component references, or serialized output
- Some entries contain JSX or RSC payloads with references to components and client modules from the build that created them. Reusing those entries after a build change could point to incompatible or missing code.
Using a new deploymentId for every build avoids tracking all of those dependencies individually. It
gives each build a new cache namespace.
See Cache Handler to configure the storage backend for Rebask's server cache.
Caching in Development
In development, Rebask uses a no-op cache, effectively disabling caching, so every request renders fresh. The client router still caches route segments in the browser's memory.