perf(core): server-side response caching using the Web Cache API#2895
perf(core): server-side response caching using the Web Cache API#2895iuioiua wants to merge 5 commits into
Conversation
marvinhagemeister
left a comment
There was a problem hiding this comment.
Caching responses this way only works for a very small subset of demo apps. A GET request in itself says nothing about the caching behaviour. The assumption that it always returns the same result is wrong. The only characteristic that's often associated with the GET method is that it promises to not modify data on the server side. There is no guarantee for that either though.
Example: You have a website with users where they can view their profiles.
- User goes to
/profile, request is cached. - User updates their profile name on a different page
- User navigates again to
/profile, but because the earlier request was cached we'll get a stale user name
|
This is probably better implemented as a middleware? It should be possible to use the const app = new App({ root: import.meta.url });
app.use(cacheMiddleware({
webCache: await caches.open('fresh'),
// Determine whether a page can be cached
include: (ctx) => {
if (ctx.state.isStaticPage) return true;
if (ctx.state.userId === undefined) return true;
return false;
});Does the Deno Cache API respect the const app = new App({ root: import.meta.url });
app.use(cacheMiddleware({
webCache: await caches.open('fresh'),
// A list of `Vary` headers, `true` or `false`
cacheable: (ctx) => {
if (ctx.state.isStaticPage) return true;
if (ctx.state.userId === undefined) return ['Cookies'];
return false;
}); |
|
+1 Agree, yeah it should be a middleware and it should respect the relevant caching headers. |
|
Superseded by #2989 |
This PR adds the ability for apps to cache responses based on
GETrequests using the Cache API. In the following benchmark, this has resulted in a ~14x speed increase in responses. This server-side caching has been enabled on the www server as a test bench.I've taken a fairly blasé approach to this functionality in that it doesn't fully consider edge cases, etc. Rather, its just able to be enabled or disabled. Finer control can be gained in proceeding PRs based on real use.
We would also want to document this functionality in the documentation, once merged.
Closes #8