Flexible API to replace the default Next.js cache, accommodating custom cache solutions for multi-instance deployments.
🎉 Version 0.5.3 is out, introducing async onCreation hook, async Handlers and fixed types. This patch significantly enhances the library while ensuring compatibility with older synchronous Handlers.
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 demands a persistent shared network mount, which might only sometimes be feasible and 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 on its way to a stable release but will remain in beta until Next.js stabilizes cacheHandler API. 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;
- Documentation; in progress
- Full test coverage;
Please use 14.0.2 or newer Next.js version until I resolve this issue.