Client Side Cache

[jaschaio]

I have now rewritten two rather large SaaS Platforms in Remix (> 100,000 LOC) and still have a lot of confidence in it.

But one thing I am painfully missing from being a heavy and quite happy React Query user before is the client side cache.

Navigating back and forth through the app just felt a lot faster as data that was fetched once remained in cache.

The only build in cache mechanism in Remix is native HTTP cache control. But that one is not a good fit for routes that sit behind a login, as they will send outdated data after an action is submitted. Nor can I use a CDN for caching purposes because I don't want users to see other users data.

This kind of only leaves me with a Server Side Cache, but that one is more complex to do and still requires the round trip to the server. It just feels subpar to the client side cache react query comes with by default.

@sergiodxa wrote a good primer on this topic and we had some previous discussions about that.

Are there any plans for a client side caching mechanism beside the native HTTP one in Remix?

[sergiodxa]

There's a proposal to add a server-side cache interface right now, with some default caches already implemented using that interface so adding server-side cache could be simpler.

I think the simplest way to add a client-side cache right now is to use a Service Worker, so maybe Remix could provide the code to run there?

Service Workers are great for this because the app can keep working as usual, but the Service Worker can cache the responses from the server and use a cache-first or network-first approach.

But I think a server-side cache gives you not just more control, but more power, for example, a single route could read public data shared across all users and private data specific of a usar (e.g. a ̦public blog post and if the current user liked it or not).

With a server-side cache you could cache the public data in a shared cache key and the private data in a cache key per user.

For example, if the user access the route without being authenticated it fills the public data in cache, then it authenticate and visit again the route it will read the public data from cache and only have to get from the DB/API the private data and then fill it on the API.

Meanwhile, a client-side only cache will only benefit one user. It may avoid the request to the server yes, but if you deploy to the edge the response with all the data cached server-side should be fast enough to don't be an issue, like most users will not realize there's a network request happening if the response come in 50ms or less.

[cliffordfajardo]

Currently the remix team is working two new function's clientLoader and clientAction which would allow easier integration with browser cache's (ex: indexDB, localStorage etc)

References

• original discussion: Optional Client Side Memory Caching Support #4950
• Remix proposal: RFC: Static Pages / Browser Only Fetching #2853
• Initial implementation work: React Router Roadmap (view)