feat: ssg support through seeding the incremental cache #65
Conversation
james-elicx
changed the title
james-elicx
changed the title
commit: |
james-elicx
force-pushed
the
james/seed-incremental-cache
branch
6 times, most recently
from
8892ccd to
f60dbc3
Compare
james-elicx
force-pushed
the
james/seed-incremental-cache
branch
from
f60dbc3 to
ba6e5f0
Compare
We can generate an index at build time but at some point we should populate the KV when building the app |
packages/cloudflare/src/cli/build/utils/copy-prerendered-routes.ts
Outdated
Show resolved
Hide resolved
|
My question is around asset bindings exposing a way instead of us generating an index. I recall a year or so a go, Greg posed the question of would it be useful if the Pages asset binding had a way to check if assets existed / get a list. I don't think anything ever came from that though. |
|
Thanks! |
|
|
||
| const seedKey = `http://assets.local/${SEED_DATA_DIR}/${key}`.replace(/\/\//g, "/"); | ||
|
|
||
| if (ctx?.kind === "APP" || ctx?.kind === "APP_ROUTE") { |
There was a problem hiding this comment.
Shouldn't this be ctx?.kind === "ROUTE" instead of APP ?
There was a problem hiding this comment.
in app directory in older versions of next 14, it uses APP for requests that should be able to match .body (e.g. sitemaps)
There was a problem hiding this comment.
(not checked pages directory, so that might apply there, but we list pages dir as unsupported at the moment)
There was a problem hiding this comment.
You're right, i missed the parseCtx function.
The .body is only for cached app route anyway, so that's fine
| return null; | ||
| } | ||
|
|
||
| async set(...args: Parameters<CacheHandler["set"]>) { |
There was a problem hiding this comment.
ISR revalidation runs in the background, it doesn't look like there is anything awaiting for the revalidation to finish
There was a problem hiding this comment.
i haven't changed this part - this pr was only implementing seed data. we dont support isr yet from my testing
Note
This PR depends on #64 being merged, and then rebased with main, to be utilised properly.
Context
At the moment, static routes are being SSR'd, despite getting pre-rendered at build-time in the app directory. This means we have a series of static assets that the Next.js server wants to be able to serve during rendering. At the moment, there is no way for the incremental cache to retrieve these static assets. This is because we have a cache handler that doesn't interact with the file-system for the seed data.
Changes
getmethod when a KV miss happens.Future thought: Can asset fetchers expose a way to list the assets that they have within them, or to check the existence of an asset instantly?