feat: update to latest Kit adapter API

Describe the problem

Kit Adapter API has changed significantly over the Dec/Jan holiday period, it needs to be updated.

Describe the proposed solution

• opt-in option for SSR route-splitting (default of no route-splitting is more performant in GCP Cloud Function environment)
  • https://github.com/sveltejs/kit/pull/2931
• remove custom esbuild config
• request.url
  • https://github.com/sveltejs/kit/pull/3126
  • https://github.com/sveltejs/kit/pull/3133
• use newer builder.getBuildDirectory() & builder.getServerDirectory() APIs
• immutable static assets
  • https://github.com/sveltejs/kit/pull/3222
• import @sveltejs/kit/install-fetch directly instead of more complicated shim

Alternatives considered

NA

Importance

i cannot use svelte-adapter-firebase without it

---

I will tackle this by end of the month (Jan2022) as I have been on and have further upcoming leave (computer absence) so cannot commit to a resolution or reviews sooner than this.

[jthegedus]

Hi all, apologies for the delay. Dec-Jan I was on leave and AFK the entire time, Jan-Feb I have been slammed with work, I have had absolutely zero time to work on any open source software, sad times. I am back at it though and will be going through the Kit updates, the feedback shared in this thread, and the examples shared to deliver a working solution sometime in the next 7 days.

I appreciate your patience, please bear with me a little longer.

Just to add to the set of changes, Cloud Functions v2 were announced last week so I imagine Firebase will have an update on this too. So a lot of changes merge and get right.

[jthegedus]

I am not completely across https://github.com/sveltejs/kit/pull/2931 so may be wrong, but as I understand it, route-splitting in this context is so we could have many Cloud Functions pointing to different pages of our app. Assuming this is what is meant by route splitting, Kit Adapter API would support:

1. 1:* CF to all app routes
2. *:* CFs to app routes or groups of routes
3. 1:1 CF per app route

1 is what currently happens. 3 is what everyone wants because of the popularization of “edge function” platforms. 2 might appear to be a more manageable version of 3, but I would wager not worth the effort for 99% of use cases.

So from this point discussion will be kept to points 1 and 3.

What would be the main benefit of route spitting with google’s cloud functions? I understand that in theory if you had one route that was resource heavy you would be able to run it with a function that has more resources using the runWith method.

The benefit of route splitting as stated in https://github.com/sveltejs/kit/pull/2931 is to:

• reduce size of bundled JS to support more space-restrictive runtime environments (CloudFlare Workers 1MB, AWS Lambda 50MB / 250MB, etc)

with secondary improvements being:

• faster JS runtime boot due to less JS code to parse for a particular route (only parsing code for that route as opposed to all code for all routes)
• faster route lookup in SvelteKit

So the main reason for route splitting does not improve usability of Cloud Functions like it does other environments (Firebase Cloud Function quota shows 100MB / 500MB deployment size limit).

With the current Firebase Adapter setup you can only set runWith for the single function that is produced, which means all your code will run with whatever settings you configure. Since runWith is used to INCREASE the specs of the machine, I can’t think of a situation where anyone would want the other parts of their code to run on a slower machine. I haven’t done any quantitative analysis on the perf/cost ratios of the different Cloud Function resource config, but typically use the 512MB/1GB 1vCPU config as I have observed more than 2x faster startup & processing for Node.js runtimes than with the default 256MB config.

The secondary improvements are nice-to-haves IMO, but introduce other challenges with this adapters usability (more later).

@jthegedus You mentioned in your comment that GCP is more performant without route splitting. Is there a reason why? I would assume it wouldn’t have much performance impact unless perhaps matching routes to function rewrites in the firebase.json has some overhead.

There is a performance impact in that each route is a different Cloud Function and therefore each route incurs the cold-start penalty of Cloud Functions instead of the first route being the only cold-start. It is strictly true that there would be more cold-starts. Having said that, the impact on users depends on the application and user navigation patterns.

For example, take a user that lands on the main app page and makes 10 subsequent in-app routes, with 8 being new pages and 2 being repeat page visits. With the two options we have:

• 1:1: 1 initial page visit + 8 other page visits = 9 routes = 9 Cloud Functions = 9 cold-starts
• 1:*: 1 initial page visit + 8 other page visits = 9 routes = 1 Cloud Functions = 1 cold-starts

Needlessly opting-in to more cold-starts seems like a bad idea to me, and I’d guess for 99% of apps that the secondary benefits of faster Kit route lookup and faster JS parsing would not be a valuable tradeoff for the cold-start boot times.

In addition to these considerations, the Firebase deploy API only supports 80 Cloud Function deployments per 100 seconds which may be hit should your many functions change frequently enough.

---

Now, the actual aspect of all this I have issue with is the usability of this adapter. The current design requires a firebase.json and looks up the “catch-all” rewrite rule to identify the Function name defined by the user ahead of time so the Cloud Function code can be generated and manually added to the functions dir code. The motivation here is that Firebase projects can support multiple apps and the Cloud Function code is managed in a project-specific way, so I didn’t want to be prescriptive. Effectively, the firebase.json file is an input into the adapter to cater for multiple apps and user-specific Cloud Function code organisation.

The Kit adapter API seems to be moving in a direction that treats the target platform config as an output, rather than an input, which is fine for the other platforms as they only support 1 app per “project/account” whereas Firebase is a many app per “project/account” platform. Modifying the Firebase project’s firebase.json file during the build-phase for one app in the project is a usability challenge. It’s certainly doable, but will take me some time to figure out the ergonomics I am happy with.