Introducing next-boost. A drop-in caching layer for SSR next.js servers

[rjyo]

This is an introduction of a micro-caching layer I build called next-boost. It can be considered as an implementation of Incremental Static Regeneration which works with getServerSideProps.

Background

I'm working on several relatively large-scale SSR websites (100K+ pages at most) with AMP. With With next.js, I can build these full-AMP websites with all the modern toolchains and it feels great. Due to their scale and the designs and functions are evolving quite fast, SSG is not an option. (Yep, I came from Gatsby after tried all kinds of optimizations)

As React's VDOM rendering is a CPU-bound task, use next.js as an SSR server alone will be relatively slow. By saying "slow", it's like that your data was fetched in 100ms while the whole page rendered in 1500ms. next-boost is drop-in middleware for next.js. And it helps me to run the sites fast even on entry-level VPSs.

Here are the main features:

• uses the stale-while-revalidate micro-caching strategy (serves the cached version while updating it in the background)
• puts CPU-bound VDOM rendering into worker_threads and the cache is always served instantly on the main thread
• built on a disk-database hybrid caching layer which is lightweight and portable
• provides API to configure different caching strategies for different routes, by using just a simple config file
• provides API for revalidating a URL, or a bunch of URLs

And, you can also get these benefits comparing to SSG

• fast to deploy (just next build then sync the .next directory). It used to take us 15 mins for SSG and uploading all the generated files. With full SSR, it takes less than 1 min.
• no need to add a cache layer with extra configs. e.g. varnish, squid, nginx Cache, etc.

So how was it comparing to next.js's support for getStaticProps and fallback: true? As the fallback mode utilizes the client-side rendering when the page's not ready, it doesn't work for a pure SSR + AMP stack.

There are more discussions about SSG and fallback in this thread:

#11552 (reply in thread)

Implementation

The repo is here: https://github.com/rjyo/next-boost, with detailed API usages.

The easiest way to integrate it with next.js is,

1. npm i next-boost
2. change the npm start script from next start to next-boost
3. add the config .next-boost.js at the project root as below. Now all the pages will be served from cache and revalidated after 60 seconds.

module.exports = {
  rules: [
    { regex: '.*', ttl: 60 },
  ],
}

More API and explanation can be found in the README.

At the end

Many thanks to the superb team and community for building this great product!

This is the first time for me to write such a long post at Github. I hope it helps someone. And you are welcomed for any questions or advice.

[Vadorequest]

Very interesting for SSR-focused Next.js apps!

I'm building something "similar" (Next.js boilerplate "Next Right Now"), but it's very different regarding the goal and implementation, as it rather focuses on SSG 😉

I've added Next Boost as a NRN alternative, and I hope I can take a deeper look at some point to learn how you've implemented some of the features that would benefit NRN!

UnlyEd/next-right-now#87

[rjyo]

@Epicteto Thanks!

I used it in several of my sites and it works great. We do use CloudFlare but only let it cache static resources like the images.

Keeping the page at your own server, not the edge or user's browser, gives you the max flexibility when there were something you need to change, IMHO.

[j3ll3nl]

This works great. Just implemented it on a big commerce site that lacked SSG. It runs on a docker swarm with multiple containers using a shared volume with sqlite db to have shared invalidation

[rjyo]

@j3ll3nl Great! I had thought that might be possible but never tried!

I'm actually quite curious on how the latency on the network filesystem impacts the whole performance. ;)

[frmwrk-development]

In our high traffic site it seems to still deliver requests in 1-2 ms

[rjyo]

Good to hear that!