Authentication and stale-while-revalidate

[Adam-Collier]

Hello everyone! So I added authentication to my app following the Jokes example, and it works great with no cache-control headers being set. However, on pages that I want to cache (due to some slow requests) I've opted to use a stale-while-revalidate cache-control header, but this means that the authenticated UI is also getting cached. Is there a way to add authentication but also cache any pages that I need to?

[ryanflorence]

In general you don't cache responses that the user has the ability to change. In practice that's pretty much any data tied to a user. So the answer is, don't use HTTP caching for those.

HTTP caching is for public facing data that the user can't change.

General best practice is to use a server side cache (redis, memcached, etc.) and then expire those caches on mutations, or use a persistence layer that's fast already: AWS DynamoDB, Cloudflare KV/Durable Objects, Fly.io's postgres read replicas, FaunaDB, and CMS's that already built something like this into them.

To speed up authenticated UI, you can check the request.headers.get("Purpose") === "pefetch" and add a short (3 seconds?) max-age cache header so that it'll be used when they click the link, but the browser will expire it very quickly if they don't (and avoid caching the page if they change the data later).

In fact, the direction we're headed with Remix is to push your apps, and your data to the edge, which means everything is fast without ever needing to reach for HTTP caching.

[mbrowne]

What about the case where pages are public except for a Login or My Account link in the upper-right corner (for example)? The site should still reflect the current login status even though everything else on the page is cached. Many apps that cache the full HTML accomplish this by having a bit of client-side JS to check/validate the current login status via an AJAX call. That would still be possible with Remix of course, but I wonder if it's the best approach? Or to keep the code that talks to the backend API on the server, maybe this would be a good use case for useFetcher()?

In fact, the direction we're headed with Remix is to push your apps, and your data to the edge, which means everything is fast without ever needing to reach for HTTP caching.

I suppose in that case, what I wrote above would no longer be relevant. But if the data can't be cached easily or for very long for some reason, I don't envision this covering all cases.

[sergiodxa]

You can do the SSG approach and cache the HTML without private data and fetch private data client-side.

Another options, if your CDN supports the Vary header, you can send a cache for non authenticated responses and no cache for authenticated responses, and set the Vary header to include Cookie, this way the cache will vary based on the cookie header value.

Another option, is to cache server-side, using something like Redis or Cloudflare Worker KV, this allow you to have a cache key for non authenticated users and another for each user, so you even cache there the data of each user.

[mbrowne]

@sergiodxa Thanks for those options, very interesting! By "SSG" I assume you mean just using cache headers so that the static pages are cached in the CDN, since Remix doesn't do static generation (by design).

I like the idea of having all API communication logic exist only on the server (in our case we would need a separate GraphQL client on the client otherwise), so I think I will use useFetcher for this. That would be consistent with how useFetcher is intended to be used, right?