Flexible API to replace the default Next.js cache, accommodating custom cache solutions for multi-instance deployments.
Next.js, by default, utilizes an in-memory cache and the file system for storing .html (entire pages), .json, and .rsc (page props or React Server Components). Suppose you're self-hosting and running multiple instances of Next.js apps. In that case, the Next.js team recommends turning off in-memory caching and using a shared network mount within your Kubernetes pods or a similar configuration. This approach allows different containers to access the same file-system cache. Check out this guide. While effective, this method does demand a persistent shared network mount, which might not always be feasible, and it can add a layer of infrastructure complexity. Also, opting out of in-memory caching can hurt performance.
@neshca/cache-handler provides an API for custom cache handlers that can seamlessly replace the default Next.js Cache. The API is designed to be flexible and allow you to use any cache-store.
This project is currently in the field test phase. Any changes made to the API will result in a minor version increase of the package until it reaches a stable version. You are welcome to try it out and provide feedback.
- Support for App routes;
- Support for Pages routes;
- Happy path tests;
- Examples;
- Full test coverage;
- Documentation;
Next.js 13.5.0 and above.