Add a built-in server-side cache interface to Remix code

[sergiodxa]

Proposal

Add a generic interface for server-side caches, similar to SessionStorage that works with many storage providers (file system, memory, Worker KV, custom ones with a database), to let Remix developers know how server-side cache works in every Remix app, but allowing the infrastructure behind change between them.

Background

Remix has bring to the table of many frontend developers how to cache the data fetched or queried on the server.

Being able to use HTTP cache is great and in some cases the preferred way, but it gives you less control over your cache, e.g. invalidate browser cache without depending on tricks like Vary header + random cookie value.

Server-side caches are often desired too, it's safer to cache data than the whole HTML, specially if you deploy many times to tweak the UI.

Use Case

• Standardize server-side cache interfaces
• Provide built-in server-side caches implementations
• Provide a way to create a custom one

API/Example

I was thinking on a simple interface like this

interface Cache {
  get(key: string, default?: unknown): Promise<unknown | null>;
  set(key: string, value: unknown, ttl?: number): Promise<void>;
  delete(key: string): Promise<void>;
  has(key: string): Promise<boolean>;
  clear(): Promise<void>;
}

Remix could provide a factory similar to createSessionStorage.

import { createCacheStorage } from "@remix-run/node"; // or cloudflare/deno
import LRU, { type Options } from "lru-cache";

function createMemoryLRUCacheStorage(options: Options<string, string>) {
  let lru = new LRU<string, unknown>(options);

  return createCacheStorage({
    async set(key, data, ttl) {
      return lru.set(key, data, ttl);
    },
    async get(key, default) {
      return lru.get(key) ?? default;
    },
    async delete(key) {
      lru.delete(key);
    },
    async has(key) {
      return lru.has(key);
    },
    async clear() {
      return lru.clear();
    }
  });
}

Remix could also provide some built-in cache storages

• createMemoryCacheStorage - Uses a JS object or Map or WeakMap (not sure what's better)
• createFileSystemCacheStorage - Serialize data to string and save it in a file, then read from there
• createWorkerKVCacheStorage - Only with CF adapters, uses Worker KV to cache data
• createDurableObjectCacheStorage - Same as above but with DurableObjects

[machour]

A standard cache interface would be very welcome!

It might be worth checking PHP's PSR-6: Caching Interface and PSR-16: Common Interface for Caching Libraries for a grasp of how it's usually implemented there.

Coming from there, I would revisit the interface to add the following concepts:

• ttl: When I want to cache some data for a precise amount of time
• defaultValue: The return value of get() when the key isn't found in cache

interface Cache {
  set(key: string; value: unknown; ttl?: number): Promise<void>;
  get(key: string; defaultValue?: any): Promise<unknown | null>;
  del(key: string): Promise<void>;
  has(key: string): Promise<boolean>;
}

We could also add more methods as syntactic sugar:

interface Cache {
  setMultiple(values: string[]; ttl?: number): Promise<void>;
  getMultiple(keys: string[]; defaultValue?: any): Promise<unknown[] | null>;
  deleteMultiple(keys: string[]): Promise<void>;
  // callable gets executed only if key isn't cached yet, to set its value
  getOrSet(key: string; callable: () => Promise<any>; ttl?: number): Promise<unknown | null>;
}

Some implementations also have a 4th parameter to getOrSet: dependency: () => Promise<any>.
If the return value of dependency() changes, the cache gets invalidated and callable() gets called again.

This allow to do stuff like this:

Cache all members for 1 hour or until a new member is inserted:

cache.getOrSet(
    "member-list",
    async () => await db.member.findMany(),
    3600,
    async () => await db.member.query("SELECT MAX(id)")
);

but that may be considered too much

[aniravi24]

Should this be something done by a third-party library or by Remix itself? While it could be a cool feature, there's probably a lot of other things Remix as a project needs to solve first in their core offering. Caching is already a "solved" problem by all the libraries you mentioned, and people should be writing small interfaces over these libraries when they use them in their own projects anyways. Not particularly opinionated either way, just curious what everyone's thoughts are.

[sergiodxa]

You could say the same about cookies, there are multiple libs that solve it, I still think it's useful for Remix to provide an interface that you know all Remix apps use.

I think it's the same here, being opinionated about the interface of how to cache data and provide a way to implement the interface is useful to make Remix apps more similar.

Similar to how after you learn Tailwind you can move to any project using Tailwind, if you learn Remix you could move to any project using Remix if the framework provides more opinions.

Caching things is also a lot of people ask about when using Remix, mostly because right now a large group of developers adopting Remix are frontend developers not used to write backend code, and now they realize they need to care about caching thing server-side.

If Remix provided a common interface and some implementations it could help them start adding a cache right aways and later switch to something else.

[cliffordfajardo]

The vite & unjs team is working on a similar idea of creating framework agnostic storage layer for web apps; they've been on a roll recently in trying to unify the ecosystem ❤️

https://github.com/unjs/unstorage

CC @patak-dev @pi0

[sergiodxa]

This is actually pretty good, thanks for sharing it, they even have Worker KV support!