Caching and documentation

[Anchakor]

I'm bit confused about caching and documentation. The Jokes App tutorial says:

Another thing you'll notice is that when we were redirected to the joke's new page, it was there! But we didn't have to think about updating the cache at all. Remix handles invalidating the cache for us automatically. You don't have to think about it. That is cool 😎

Does Remix have some default caching on the server side (browser-server communication path)?
Does Remix have some default caching on the server side for the backend APIs?
Does Remix have some default caching on the client side?

I assume there is no default cashing, but he Jokes App tutorial (which is official docs) suggests otherwise.

I imagine someone might think some default caching based on route conventions could be neat, like /article/123/edit action invalidating /article/123, but it raises obvious questions about invalidation of other routes based on the mutated data (say /top-10-articles) and other issues.

I think the documentation could be clearer about caching and maybe even suggest best practices - like HAProxy, Redis for API caching, considerations for edge app deployment, client-side service worker caching (PWA) using Workbox etc.

[sergiodxa]

Does Remix have some default caching on the server side (browser-server communication path)?

It doesn't have any cache built-in, but you can either setup a server-side cache or an HTTP cache.

Does Remix have some default caching on the server side for the backend APIs?

No, it doesn't, if you want to cache server-side request to another API you need to do it yourself, some ways could include using an in-memory LRU cache if you have a long running server, or something like Redis on serverless of if you want to ensure it's cached even after a restart of the server.

Does Remix have some default caching on the client side?

They kind of have one, the browser can cache request if using HTTP cache, but also they keep the data of every loader in a state in memory, if you navigate client-side to another child route any parent route will not be refetched again and instead it will use the already fetched value, so you could say this is a cache, but if an action happens Remix will revalidate all loaders data and use fetch it again.

Also if you were on /parent/child1 and went to /parent/child2 and back to /parent/child1 Remix will fetch the child1 data again, it will not re-use the previously fetched data, here is where an HTTP cache could tell the browser (or CDN) to cache the data of child1 and then when Remix fetches it again it will receive the cached response instead of making the server run the loader to send a response.

[sergiodxa]

@jaschaio yes, using s-maxage will let you control the CDN cache, you can then use that API for Cloudflare or similar ones for other CDNs to purge the cache. You could combine max-age and s-maxage like this max-age=0, s-maxage=60 to tell the browser to don't cache and the CDN to cache.

[jaschaio]

@sergiodxa thanks for the reply, this is a bit of uncharted territory for me. But what if I want to cache private data? e.G. any request that is behind authentication. I think those should not be cached at a CDN level, unless the CDN supports a vary header? Cloudflare doesn't support vary for example, so the only option here is using max-age, but if it's cached in the browser I can't make an API request to clear the cache. Does this means that authenticated requests can simply not be cached?

[sergiodxa]

For private data I would use a server side cache instead of an http cache

[richardscarrott]

It'd be interesting to know if Remix intends to offer up a built-in API for server side caching (redis etc.) as it seems more practical in many cases as you can cache the static parts of the page, but keep other parts dynamic.

Would be cool if you could cache the generated HTML so you could additionally avoid executing the React render for certain components; although not sure whether React hydration would play nicely with this.

[ReDev1L]

@sergiodxa
Article doenst render, unexpected error: https://sergiodxa.com/articles/http-vs-server-side-cache-in-remix#server-side-cache

[dangayle]

The headers documentation has some good points on setting up http cache headers for client side caching:

https://remix.run/docs/en/v1/api/conventions#headers

You can also add cache control headers to data routes using handleDataRequest:

https://remix.run/docs/en/v1/api/conventions#entryservertsx

[martinmckenna]

quick question on HTTP caching: Is adding this the solution to solve the issue on mobile where you hit the back button and see either an empty page or the page flash old content -> new content?

When I hit back on mobile browsers, the loader gets re-run and then either shows a blank page or incorrect content before flashing the correct content, and I was never sure how to solve this issue.

[dani-sanomads]

Same here, @sergiodxa . Do we have any update or fix for it in Remix app. @martinmckenna

[dani-sanomads]

Added this configuration in the entry.client.tsx file and it worked.

backend: {
loadPath: "/locales/{{lng}}/{{ns}}.json",
requestOptions: {
cache: "no-store",
}
},