this.cache(...) in preload

[Rich-Harris]

At present there's no way to set a cache header for a page. It might be useful to be able to do this:

export default {
  async preload({ params }) {
    this.cache('max-age', 30 * 60 * 1000); // cache for 30 minutes
    await this.fetch(...).then(...);
  }
};

(An interesting question that arises is whether that should change behaviour on the client as well. Should the browser cache the preloaded data for the specified duration and reuse it if the same URL is visited later? This would make some navigations faster but would increase memory usage and introduce a danger of mutation bugs, so perhaps it's better to rely on the service worker.)

Or would it be better to have a more generic this.headers({...}) function?

[nsivertsen]

I'm in favour of having something like this in Sapper. I feel that your suggestion, especially in the general form of this.headers({...}), is related to #362, especially to my comment about route-specific middleware for things like caching API responses server-side, but which could also be used for setting headers. Another solution to both problems would be to add a middleware function to routes that has access to req and res:

export default {
  async middleware({ req, res }) {
    res.set('Cache-Control', `max-age=${30 * 60 * 1000}`); // cache for 30 minutes
    // do other stuff with `req` and `res`
  }
};

The advantage of this approach is that you can do anything that Express or Polka allow you to do, and are not limited to the functions that Sapper exposes on the context object.

The disadvantage is that you forfeit the ability of also doing something like caching things client-side as you propose above with this.cache(...).

[mrkishi]

I would prefer a server-specific solution like @nsivertsen's myself.

I'd instinctively associate a this.cache() inside preload with the preloaded data only -- meaning no matter what crazy thing I did inside preload, the returned data would be cached locally, where local means either the client or server.

[dogada]

Or would it be better to have a more generic this.headers({...}) function?

This is IMO a better solution because if I will set a cache header on server, browser will cache the page also (in addition to the intermediate caching proxies). I will probably also need to set a Vary header. I think Sapper should provide access to the request object also like Next.js do in getInitialProps. It may look like:

preload({req, res}) {
  if (req) this.headers(...)
}

[antony]

Just ran into this issue. Unfortunately the caching is breaking my authenticated only pages. It would be great to have a way to control the caching for a page, or more importantly, to turn it off for specific pages.

[antony]

After playing with this a bit more, I think this caching breaks apps with authentication entirely.

Any attempt to redirect the user if not authenticated, from server-side (preload) is broken by the 10 minute page cache, so if you log in, you still get redirected, likewise if you were logged in, you can still see those pages for 10 minutes after you log out.

...and any attempt to check auth clientside (oncreate) means that you see the secured content first, before the javascript renders, but not only that, if you try to load some authorised content in your preload, that will make any page redirect to the sapper error page first (when the API sends a 401), before your redirect has had time to send the user to login.

This is what I've ascertained so far anyway, please correct my thinking if I'm wrong.

[alexkornitzer]

Hey, any update on this, as noted by @antony this is quite a big blocker on any app that requires authentication (or am I just doing it wrong?), as any movement to cached html pages persist the state of either being authed or un-authed until cache refreshed. For now I have had to fork and copy @nsivertsen's 'fix' #389 (comment)

Could we maybe add a build flag for now that disables html caching?

[imCorfitz]

I second this as a feature. In our case, we are constantly releasing new articles, and due to the page cache, it takes 10 minutes before new articles are loaded as part of the front page, when users arrive. Currently workaround from my side is to delete the production replicaset in Kubernetes every time a new article is released. It means though, that the site is down every time for approx. 5 seconds, but at least the cache is gone. (ps. I couldn't make the 'fix' referred to work properly. Would have been a lot easier.)

[alexkornitzer]

@Rich-Harris are you able to shed any further light on this?