-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upcoming change to Cloudflare Pages projects #6441
Comments
Thank you for the heads up and the forthcoming contribution!
Just to clarify, hooks only apply to routes, not to static assets, so it's safe to bypass the worker for everything that matches the contents of |
Ah that makes things much easier. Thank you. ❤️
Indeed. We'll do that sort of statically via the
For now, we're going to be fairly conservative with this, matching only static assets that look like a favicon. The reason being that there may be content in that directory that the user does intend to run through functions (e.g. for gating access to a sensitive document). We may walk back on this in the future, but I think it's better to be conservative and not potentially break a deployment. I'll have a PR ready soon. |
When a SvelteKit project is deployed to Cloudflare Pages, the server-side code is supported through Pages Functions (currently in beta). Unfortunately, by using Functions, each request must go through the server-side Functions code even if it doesn't need to. For instance, an immutable asset request to https://kit.svelte.dev/_app/immutable/assets/_layout-ab34ca4f.css would first have to route through Functions. This is problematic since the request would "count" as a request to Functions even though only a static asset was served. Further, there is a slight amount of added latency. This change exposes a set of includes and excludes based on static files generated.
When a SvelteKit project is deployed to Cloudflare Pages, the server-side code is supported through Pages Functions (currently in beta). Unfortunately, by using Functions, each request must go through the server-side Functions code even if it doesn't need to. For instance, an immutable asset request to https://kit.svelte.dev/_app/immutable/assets/_layout-ab34ca4f.css would first have to route through Functions. This is problematic since the request would "count" as a request to Functions even though only a static asset was served. Further, there is a slight amount of added latency. This change exposes a set of includes and excludes based on static files generated.
When a SvelteKit project is deployed to Cloudflare Pages, the server-side code is supported through Pages Functions (currently in beta). Unfortunately, by using Functions, each request must go through the server-side Functions code even if it doesn't need to. For instance, an immutable asset request to https://kit.svelte.dev/_app/immutable/assets/_layout-ab34ca4f.css would first have to route through Functions. This is problematic since the request would "count" as a request to Functions even though only a static asset was served. Further, there is a slight amount of added latency. This change exposes a set of includes and excludes based on static files generated.
When a SvelteKit project is deployed to Cloudflare Pages, the server-side code is supported through Pages Functions (currently in beta). Unfortunately, by using Functions, each request must go through the server-side Functions code even if it doesn't need to. For instance, an immutable asset request to https://kit.svelte.dev/_app/immutable/assets/_layout-ab34ca4f.css would first have to route through Functions. This is problematic since the request would "count" as a request to Functions even though only a static asset was served. Further, there is a slight amount of added latency. This change exposes a set of includes and excludes based on static files generated.
When a SvelteKit project is deployed to Cloudflare Pages, the server-side code is supported through Pages Functions (currently in beta). Unfortunately, by using Functions, each request must go through the server-side Functions code even if it doesn't need to. For instance, an immutable asset request to https://kit.svelte.dev/_app/immutable/assets/_layout-ab34ca4f.css would first have to route through Functions. This is problematic since the request would "count" as a request to Functions even though only a static asset was served. Further, there is a slight amount of added latency. This change exposes a set of includes and excludes based on static files generated.
When a SvelteKit project is deployed to Cloudflare Pages, the server-side code is supported through Pages Functions (currently in beta). Unfortunately, by using Functions, each request must go through the server-side Functions code even if it doesn't need to. For instance, an immutable asset request to https://kit.svelte.dev/_app/immutable/assets/_layout-ab34ca4f.css would first have to route through Functions. This is problematic since the request would "count" as a request to Functions even though only a static asset was served. Further, there is a slight amount of added latency. This change exposes a set of includes and excludes based on static files generated.
* feat: Cloudflare Pages _routes.json specification (#6441) When a SvelteKit project is deployed to Cloudflare Pages, the server-side code is supported through Pages Functions (currently in beta). Unfortunately, by using Functions, each request must go through the server-side Functions code even if it doesn't need to. For instance, an immutable asset request to https://kit.svelte.dev/_app/immutable/assets/_layout-ab34ca4f.css would first have to route through Functions. This is problematic since the request would "count" as a request to Functions even though only a static asset was served. Further, there is a slight amount of added latency. This change exposes a set of includes and excludes based on static files generated. * use writeFileSync over writeFile, for consistency with rest of codebase * code style stuff * tweak changeset Co-authored-by: Rich Harris <[email protected]>
Describe the problem
👋
Hi there. John here from the Cloudflare Pages team.
When a SvelteKit project is deployed to Cloudflare Pages, the server-side code is supported through Pages Functions (currently in beta). Unfortunately, by using Functions, each request must go through the server-side Functions code even if it doesn't need to. For instance, an immutable asset request to
https://kit.svelte.dev/_app/immutable/assets/_layout-ab34ca4f.css
would first have to route through Functions.This is problematic since the request would "count" as a request to Functions even though only a static asset was served. Further, there is a slight amount of added latency.
Describe the proposed solution
The Cloudflare Pages team has been rolling out support to customize how project Functions are mounted and thus can save money and latency by providing this metadata on build. The
@sveltejs/adapter-cloudflare
package should expose a set of includes and excludes based on static files generated. For the time being, I suggest we be conservative and include the Functions worker on all routes but exclude on/_app/immutable/
.If the SvelteKit user uses the hooks functionality, they may need to tune these patterns manually on a case-by-case basis.
Alternatives considered
No response
Importance
nice to have
Additional Information
We (the Cloudflare Pages team) will be contributing the relevant changes.
The text was updated successfully, but these errors were encountered: