How to Cache and Selectively Refetch Data in a Remix Application?

[osowskimateusz97]

Hello there!

I have multiple forms and charts on the home page (/ route). (I use react router v7 with a node server.)

The loader for this route fetches data from the backend for various tables, charts, and other components. Each table/chart requires a separate API request.

I also have table-specific filters. When I apply a filter to a specific table (e.g., filtering by a certain value), I update the URL search parameters using useSearchParams. In my loader, I read these search parameters to determine if a specific key exists and adjust the request accordingly.

This works fine, but the issue is that I don’t want to reload the entire loader when I change a filter for just one table. Reloading everything leads to unnecessary API calls for unrelated data. How can I split these executions so that only the relevant table’s data is re-fetched? Or, within the loader, how can I determine when to refetch specific data from the backend?

Additionally, what is the best approach for caching data on the client? I’m looking for something similar to React Query, where I can define cache keys. The data should be refreshed every 24 hours, so making a backend request for every interaction doesn’t seem ideal. A CDN is likely not an option since the data is sensitive and available only after user authentication.

[sergiodxa]

A few options:

1. Don't use the route loader and fetch data from the component (client-side) this means you won't have SSR for those components, and it may feel slower, but you will be able to revalidate only part of the data
2. Cache the data server-side, that way you can let the loader run again but instead of fetching the data it will read it from the cache, unless a search param affecting the data changed
3. Cache the data client-side using a clientLoader, you can move the data fetching to a clientLoader, you will be able to use a client-side cache, so while the clientLoader may run again ideally you only fetch part of the data, and return the cached for the rest

I think 2 is the best solution, as you will have more control over your cache, you could invalidate it from any action, you could invalidate the cache from another request made by another user, or in a background job or scheduled task

The next best one is the 3, while you won't have that much control over the client-cache (unless you add more other things to let the server tell clients to invalidate the cache) it will still gives you the option to fetch on a single loader (client loader in this case) instead of fetching on every component, you won't have SSR but you can control how you load data in parallel.

The worst one (it's not bad just not as good as the other ones) is the 1, in that case you will probably need to drop Remix loaders/actions and use React Query, so you won't get any of the benefits of using Remix loaders/action.

[osowskimateusz97]

My loader will call an API Gateway, which will, under the hood, execute a Lambda function that interacts with Elasticache.
I will receive from redis raw data which will be parsed, aggregated, and processed on my server (Node side). These data on elasticache will change after 24 hours (they are static, I will not modify them- just read). That's why I would like to store (cache) my parsed data somewhere.
First of all, this data will change after 24 hours. Secondly, my calculations (parsing, aggregation) will take some time, so I don’t want to recalculate the same data again for the same request.
As a cache key, I could use the parameters that are relevant to a specific table or graph.

I checked your article, it makes sense. https://sergiodxa.com/articles/http-vs-server-side-cache-in-remix)

Do you think that having 2 instance of Redis is a good idea? First from which I will retrieve the data and second for caching?

The cache key can include the user token or anything that helps you identify the user. This will allow you to have a unique cache key per user on your server, so other users will not receive the same cache. If you use the userId, it will even cache the data after the user logouts or switch to another device because the cache is on the server.

Additionally, considering that there may be over 30K users, would server-side caching be a good idea? I'm worried about the amount of cached data. Or would it be better to move the cached data to the client to avoid overloading the server?

If I load the data on the client side, I don’t want to expose the backend URL or secret tokens required for authentication.

[osowskimateusz97]

Seriously, is it not possible to split backend calls for a single route?

Or can I create an /api folder where I store separate loaders and then call those loaders from the home(index) loader? That way, on the client side, I could cache the data and, whenever a query parameter changes, execute only the relevant loader from the /api folder.

I could create fetch methods and maybe use React Query to call specific loaders. Would that be too complicated?

app/
  routes/
    index.tsx       // Main page
  api/
    latest-sales.ts       // Loader for latest sales
    latest-orders.ts       // Loader for latest orders
    latest-returns.ts  // Loader for latest returns

[osowskimateusz97]

What do you think to use react query?
https://tanstack.com/query/latest/docs/framework/react/guides/ssr#full-remix-example

[sergiodxa]

Do you think that having 2 instance of Redis is a good idea? First from which I will retrieve the data and second for caching?

There's no issue, but if your data is already cached in your API I see no reason to avoid hitting it, you could hit your API a million times and in that 24 hours windows where data is cache it will be a fast response.

Additionally, considering that there may be over 30K users, would server-side caching be a good idea? I'm worried about the amount of cached data. Or would it be better to move the cached data to the client to avoid overloading the server?

Are those users daily? That's not a lot of MAU to be a problem for a server-side cache. If you want to avoid hitting your server and your server is behind a CDN, you could use a HTTP cache, set the s-maxage to 24hs and your server won't receive. a single request in that time.

Seriously, is it not possible to split backend calls for a single route?

You can call many APIs from a loader, but a route can't have multiple loaders, you could also have multiple routes each one with a loader.

Or can I create an /api folder where I store separate loaders and then call those loaders from the home(index) loader?

You could, but you will cause an extra HTTP request from your Remix app to your Remix app that will also do an HTTP request to your API, you're adding extra overhead for something that should be a cached function call, specially if that other Remix API endpoint is going to add that cache anyway.

I could create fetch methods and maybe use React Query to call specific loaders. Would that be too complicated?

That's what I mentioned in the point 1, just not use Remix loaders to get the data and use RQ to get from an API, that API could be a separate API in Remix or you could directly hit your API, using Remix in the middle could be useful to get the user API token from a cookie and attach it as the Authorization header so you don't need to expose the token to the client.

But you need to understand that you're losing automatic revalidation after actions, SSR (unless you also fetch data in the loader to hydrate RQ cache) and basically most features of Remix.

[osowskimateusz97]

There's no issue, but if your data is already cached in your API I see no reason to avoid hitting it, you could hit your API a million times and in that 24 hours windows where data is cache it will be a fast response.

The static data are stored in Redis, but in my loader, I perform some operations on it.
I receive raw data from Redis, then process it on my node server, and then I would like to cache the processed data. These operations depend on query parameters (filters) from the table and other factors. I'm thinking now how & where to store these processed data.

Are those users daily? That's not a lot of MAU to be a problem for a server-side cache. If you want to avoid hitting your server and your server is behind a CDN, you could use a HTTP cache, set the s-maxage to 24hs and your server won't receive. a single request in that time.

Yes, 30k users could visit my app daily, and this data will be massive because it will be analytics-related data. Currently, my Node server is not behind a CDN. Is it secure to cache private user data in a CDN? If so, then I could just setup cdn and return max-age & s-maxage from the loader and it will cache my processed data and that's it, right? I'm carious if cdn will handle to cache big amount of data.

[sergiodxa]

Is it secure to cache private user data in a CDN?

It's hard, you need to ensure data is not shared.

I would cache data in Redis after it's processed, so get the raw data (also from Redis), process it and cache it, then if on subsequent requests check if it's already cached in Redis.

If the raw data is only updated once per day, you could also cache the processed data for the same amount of time.

[osowskimateusz97]

All right, thanks for your advice man!

Cheers!

[osowskimateusz97]

@sergiodxa I'm thinking if I could just return private max-age in Cache-Control headers and set time to 30 minutes or something like that.

[sergiodxa]

That will only work if you have something respecting the cache headers

That usually means you fetch from a browser or pass through a proxy like a CDN

If you set that header in your API, and fetch it from Remix you will need a proxy like a CDN that can cache the response, the proxy doesn't have to be a CDN and could be an in-memory thing or even just a wrapper of fetch that respects the header.

[osowskimateusz97]

I mean remix app could return max-age (private cache) along with data. Without s-maxage. Would that work ?