[RFC] Modern.js SSR Cache

[GiveMe-A-Name]

1. Background

Improve SSR render time and reduce CPU overload by using SSR cache.

Current Modern.js have a SPR Cache HOC, but it seems users don't like using it.
So we need improve it and optimize UX by using it.

2. Detailed Design

a. Rule Configuration

Use HOC

Current Modern.js has a PreRender HOC that receives cache strategy config.

• interval：Set the cache freshness retention period (unit: second). During this time, the cache will be used directly and without asynchronous rendering.
• staleLimit: Set the time for the cache to fully expire (unit: second). During this time, the cache can be returned and a step rendering will be done, otherwise the result of re-rendering must be used.
• level: Sets the level of computation rules for cache identifiers, usually used with includes and matches. The default value is 0.

0：context.cacheId + pathname
1：context.cacheId + pathname + url query
2：context.cacheId + pathname + request header
3：context.cacheId + pathname + url query + request header

• includes: Sets the content to be included in the cache identity, used when the level is not 0. The default value is null.
• matches: Set the value of query or header in the cache identification of the override rule, usually used in the cache classification, support for regular expressions. The default value is null.

👍 Good: Caching policies can be easily configured depending on the route.

👎 Bad: This is invasive to the code

Use modern.config.ts

import { defineConfig } from '@modern-js/app-tools'

interface SSRCacheStrategy {
    // ...
}

const strategy1: SSRCacheStrategy = { ... };

const strategy2: SSRCacheStrategy = { ... };


export default defineConfig({
    server: {
        ssr: {
            cache: {
                strategy: 'weak' | 'medium' | 'strong' | {
                       // /user would match cache strategy1.
                      '/user': strategy1,
                      // /user/detail/13 would priority match cache strategy2.
                      '/user/detail/$id': strategy2,
                },
                cacheOptions: {
                    name: 'redis' | 'memory' //....,
                    max: 256 * 1024 * 1024, // Byte
                    // ...
                }

            }
        }
    }
})

👍 Good: This is't invasive to the code
👎 Bad: We need use RegExp to match the strategy.

✅ Using custom server (server/index.ts or server/cache.ts)

We appoints user should export a serverCache object.

Examples:

// always include - "url"
type CacheControlRange = "header" | "query";

type CacheControl = {
  validate: number;
  staleWhileRevalidate: number;
  controlRanges?: CacheControlRange[];


  /**
    Users can specify CacheID in server hook or custom server middleware.
    Then CacheID would be as a part of cache symbol to cache SSR render result.
 */
  customKey?: string;
};
type CacheOptionProvider = (req: NodeReq) => CacheControl;
type CacheOption = false | CacheOptionProvider | CacheControl |  Record<string, CacheControl | CacheOptionProvider>;

class RedisContainer implements Container {
  get(k: string): string | undefined {
    throw new Error("Method not implemented.");
  }
  set(k: string, v: string): void {
    throw new Error("Method not implemented.");
  }
  has(k: string): boolean {
    throw new Error("Method not implemented.");
  }
}

export const customContainer: Container = new RedisContainer();

export const cacheOption: CacheOption = function cacheOptions(req) {
    return {
      validate: 10,
      staleWhileRevalidate: 230,
      controlRanges: ["header", "query"],
      customKey: "",
    };
  },

b. Cache Strategy

Cache Strategy would like stale-while-revalidate.

• time < 1s the cache is validate. Visit ssr server would return cache content.
• 1s < time < 3s the cache stale while revalidate. Visit ssr server would return cache content directly, while do SSR render.
• 4s < time, the cache is invalidate. Visit ssr server would SSR render then return content.

Cache in store

We would use globalStorage to store ssr cahe. More detail see: #4968

c. Apply Range

• The caching mechanism applies to relatively static pages. Reduce user waiting time and save SSR server resources.
• For pages with relatively large dynamic data, 🌟 streaming ssr is recommended. We do not recommend SSR cahe.

[yimingjfe]

This RFC is very clear, I still have a few questions about the cache store:

1. Where is the cache stored?
2. What is the maximum size limit?
3. When the cache reaches its maximum, how can we remove the cache?

[GiveMe-A-Name]

The SSR Cache don't care about cache store.
In design, we have a layer about store system, more detail see: [RFC: Store System] #4968 .

But I don't have design the maximum-size-limit. We can discuss in other RFC.

[yimingjfe]

I knew the RFC #4968, but it couldn't answer my question, because I didn't see a description of the specific relationship between the two.

If this RFC is about SPR, why not describe everything in this RFC?

[GiveMe-A-Name]

Ok, Because store system not only apply ssr cache, but also apply server file cache ... or others cache situations.

Emmm, It would be better to establish a relationship between this RFC and RFC #4968.
Perhaps I can describe it more clearly.