Files
16dcebe792 Stabilize custom cache handlers and changing memory size. (#57953)
This PR stabilizes the previously introduced experimental config options
for providing a custom cache handler (for both ISR as well as the Data
Cache) and for disabling or configuring the in-memory cache size. The
example usage would be as follows:

```js
// next.config.js
module.exports = {
  cacheHandler: require.resolve('./cache-handler.js'),
  cacheMaxMemorySize: 0 // disable default in-memory caching
}
```

This PR also updates the documentation to better reflect how to use the
custom cache handler when self-hosting. Further information will be
added in a following PR that also includes a full example of a custom
cache handler that implements `revalidateTag` as well as passing in
custom cache tags. The API reference docs have been updated here, as
well as a version history added.

I also noticed that we currently have two duplicated versions of the ISR
docs in the Pages Router docs: both for rendering and for data fetching.
Data Fetching is the correct location for this page. There were no other
references to the rendering version in the docs, so that must have been
an accident. I'll need to a get a redirect going for that regardless.

Tests have been updated for `cacheHandler` and I added a new test for
`cacheMaxMemorySize`.

---------

Co-authored-by: Jiachi Liu <[email protected]>
2024-01-17 23:42:52 +01:00

60 lines
2.7 KiB
Plaintext

---
title: Custom Next.js Cache Handler
nav_title: cacheHandler
description: Configure the Next.js cache used for storing and revalidating data to use any external service like Redis, Memcached, or others.
---
In Next.js, the [default cache handler](/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating) for the Pages and App Router uses the filesystem cache. This requires no configuration, however, you can customize the cache handler by using the `cacheHandler` field in `next.config.js`.
```js filename="next.config.js"
module.exports = {
cacheHandler: require.resolve('./cache-handler.js'),
cacheMaxMemorySize: 0, // disable default in-memory caching
}
```
View an example of a [custom cache handler](/docs/app/building-your-application/deploying#configuring-caching) and learn more about implementation.
## API Reference
The cache handler can implement the following methods: `get`, `set`, and `revalidateTag`.
### `get()`
| Parameter | Type | Description |
| --------- | -------- | ---------------------------- |
| `key` | `string` | The key to the cached value. |
Returns the cached value or `null` if not found.
### `set()`
| Parameter | Type | Description |
| --------- | -------------- | -------------------------------- |
| `key` | `string` | The key to store the data under. |
| `data` | Data or `null` | The data to be cached. |
| `ctx` | `{ tags: [] }` | The cache tags provided. |
Returns `Promise<void>`.
### `revalidateTag()`
| Parameter | Type | Description |
| --------- | -------- | ---------------------------- |
| `tag` | `string` | The cache tag to revalidate. |
Returns `Promise<void>`. Learn more about [revalidating data](/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating) or the [`revalidateTag()`](/docs/app/api-reference/functions/revalidateTag) function.
**Good to know:**
- `revalidatePath` is a convenience layer on top of cache tags. Calling `revalidatePath` will call your `revalidateTag` function, which you can then choose if you want to tag cache keys based on the path.
## Version History
| Version | Changes |
| --------- | ------------------------------------------------------------------------ |
| `v14.1.0` | Renamed `cacheHandler` is stable. |
| `v13.4.0` | `incrementalCacheHandlerPath` (experimental) supports `revalidateTag`. |
| `v13.4.0` | `incrementalCacheHandlerPath` (experimental) supports standalone output. |
| `v12.2.0` | `incrementalCacheHandlerPath` (experimental) is added. |