Optional Client Side Memory Caching Support

[hoffnung8493]

Background

With Remix, we cannot really make good use of client side memory caching such as RQ, Apollo Client, SWR, etc.
Even if we did cache using these libraries, the loaders in the server will always be executed on revisits.
If we want make use of cache, we would have to rely on purely client side data fetching, which is definitely not what I want when using Remix.

There are other encouraged caching strategies such as server side caching with something like Redis (make it even better with edge servers) and http cache with control header(in CDN and/or browser). All of these options are viable caching strategies.

But except for browser http cache, the rest will have some latency and CDN caching is limited to public data. Then why not browser http cache? it has no delay, and it is also private to the client.

The biggest downside compared to client side memory cache is that developer does not have fine "control" over the browser cache. Sure, you can put a short max-age, and even use different max-age based on the resource created time(one of Ryan's video on controlling cache headers, which I really liked) but what if the age of the data depends on certain random client interactions? where sometimes it can be very short, sometimes long. If it was client side memory caching, we could invalidate this specific cache at the right instant, which will keep the data fresh and only make necessary network requests.

Another way to control http browser cache is to use the Vary header, by updating its value. But this will invalidate ALL http browser cache. Again we have control issue.

Most of the time it could be fine with these caching strategies and using browser in memory cache could be an over kill. But we can clearly see that client side memory cache does have its value, especially later when we want to optimize the product.

Proposal

An option to add clientLoader in each route component, where this only executes in the client, similar to the loader from React Router v6.4+. The main difference to RR loader would be that clientLoader, receives another argument, next (just like in express). If the clientLoader can find valid cached data, it will return the data with json, (so far, exactly how it works in RR loader).

export function async loader({request}) {
  const id = request.params.id
  const data = await db.fetch({ id })
  if(!data) return json({},{ status: 404 })
  return json({ data })
}

export function clientLoader({ request, next }) {  // proposed feature with `next`
  const id = request.params.id
  const data = some_client_cache.find({ id }) 
  if(data) return json({ data })
  return next(request) 
}

The main difference to RR's loader is this: If there is no valid cached data, instead of making a fetch request to an API endpoint, you could simply pass on the request to the server side loader using the next function. Then the server side loader will receive the request, and this loader can do its normal job!(fetch data from db). There will be no changes to the existing APIs basically. The only difference is that now we have an option to put a client side memory layer. Same loader, same hooks, no component changes(still use Forms to navigate and mutate)

For data mutation, the order would have to be different.

1. submit form data
2. run action in server
3. if clientAction is configured, run that in browser. Here is where you would either invalidate or even update client side memory cache.
4. run all configured clientLoaders. From here it would be the same as explained above: For each clientLoader, it would check if cache is available or not and either return the cache or trigger server side loader with next

I was blown away when I tried Remix APIs with RR v6.4 with client side in memory caching. As the docs says:
(React Router is about timing, where React Query is about caching.)
Its not Remix's job to do client side caching, but the framework should give the developers the option to use client side caching

This would provide me with all the levers I need, at least for data fetching and mutation!

[cliffordfajardo]

A few weeks ago someone made a guide for using remix SSR with react-query, does that help?
https://tanstack.com/query/v4/docs/react/guides/ssr#using-remix

With Remix, we cannot really make good use of client side memory caching such as RQ, Apollo Client, SWR, etc. Even if we did cache using these libraries, the loaders in the server will always be executed on revisits.

My solution to this problem has been using a in-process cache like the the lru-cache npm package; you can use something like redis if you lru-cache isn't enough

Even if we did cache using these libraries, the loaders in the server will always be executed on revisits.

If you're responses are cached, then you could avoid going to your database or API. One pro of having the cached data on the server is that if other user's of your app are requesting the same data, they will get the response, even if they switch browser or clear their browser cache

but what if the age of the data depends on certain random client interactions? where sometimes it can be very short, sometimes long.

You could write a custom hook in your remix app using useRevalidator, call the hook in one of your components that would call the server to invalidate/update the cache and return a new response

React Query

One thing I do miss about react-query is saving massive amounts of data to localStorage or IndexDB (5mb+). We have internal apps and dashboards at work where people are making very custom queries to our backend; I'd prefer to have those stored in the browser to avoid increasing the memory on our server since everyone is writing different queries to our backend and the shared cache on the server doesn't help us much in this particular scenario

Browser caches like localStorage/Indexdb are valuable still;

I haven't tried the remix solution described in the react-query docs yet; actually stopped using react-query nearly everywhere after using remix and lru-cache package
https://tanstack.com/query/v4/docs/react/guides/ssr#using-remix

[hoffnung8493]

A few weeks ago someone made a guide for using remix SSR with react-query, does that help?

Thanks for sharing the link. Do you know if the loaders are executed again or revisits? I tried something similar before with Apollo Client and Next.js (getServerSideProps) and the hydration part was being executed again even though the data is already in the apollo cache, which makes the client side memory cache pretty much not valuable.

My solution to this problem has been using a in-process cache like the the lru-cache npm package; you can use something like redis if you lru-cache isn't enough

Yea, lru-cache is a good solution as well. But this is still server side cache, so there will still be some delay on the client.

You could write a custom hook in your remix app using useRevalidator, call the hook in one of your components that would call the server to invalidate/update the cache and return a new response

As far as I know, this is to re-execute loaders. You cannot invalidate browser http cache. Unless you update the Vary header, which would invalidate "all" browser cache.

[hoffnung8493]

I haven't tried the remix solution described in the react-query docs yet; actually stopped using react-query nearly everywhere after using remix and lru-cache package

Yea same with me actually. I just had a chance to use React Router recently, which worked super well with client side memory cache. I thought it would be a great lever to have with Remix. By introducing, clientLoader and clientAction you wouldnt even need any special hydration functions. You could simply use any existing client side caching libraries, right away and only if you want to. Also it wouldnt change any existing Remix related code

[brophdawg11]

Related proposal that has some discussion of a clientLoader concept: #2853

[tchak]

For data mutation, the order would have to be different.

1. submit form data
2. run action in server
3. if clientAction is configured, run that in browser. Here is where you would either invalidate or even update client side memory cache.
4. run all configured clientLoaders. From here it would be the same as explained above: For each clientLoader, it would check if cache is available or not and either return the cache or trigger server side loader with next

What happens if the app is offline ? Will mutation always fail ? In the case of clientLoader I can check if the app is offline and not call next

[hoffnung8493]

clientAction runs in the client, so u could check the connectivity and handle the request accordingly. For example if your app is offline, your app could prevent from forwarding the request to serverAction, instead cache the request in the client until connection is back or simply return an error message about connection issue.

[iamkd]

It would be great to have the ability to both return the data from the clientLoader and invoke next() so that we can implement stale-while-revalidate or basically any other caching strategy if needed.

[csquillen]

Calling a loader function client-side AND a loader function server-side as part of a single request as the OP suggests makes sense to me. As the OP described above in the code snippet, it's a stale-while-revalidate (SWR) caching strategy for data.

On route change:

1. Run clientLoader to fetch data from local store (localStorage, IndexedDB, SQLite.wasm, etc.)
2. Render (with possibly stale data)
3. Run loader to fetch the data again (same query) from the server
4. Render (with fresh data)
5. Update local store with fresh data

I see a few potential benefits to this approach:

1. Instant route transitions
2. Fine-grained cache control (potentially a persistent, normalized cache of database data even)
3. Offline-first (cache-first) mobile apps and PWAs
4. Simpler, more robust optimistic UI by writing to local store first

Implementation-wise, I've been envisioning a "universal" loader that works both client-side and server-side via an ORM/repository data-source layer. See below. But the separate loaders with next() argument would work too IMO.

export function async universalLoader({request}) {
  var data = await Project.includes('tasks').where({ status: 'open' }); // Sample "universal" ORM method; hits local store or DB
  return json({ projects: data });
}

Thoughts?