Support for Cloud Functions and SSR

[babichjacob]

Right now, your site has to be fully static to use this setup.

What is needed for SSR support? A SvelteKit adapter for Firebase?

[jthegedus]

I'll try and publish my Firebase Adapter soon, but since the Adapter API is in flux until beta release of sveltejs/kit I will try to only support the latest @sveltejs/kit@1.0.0-next.(latest # here)

[mankins]

@jthegedus If you could share anything ahead of that it could fill in some missing pieces that I've been working through.

What's needed for SSR support?

Is this something like https://github.com/firebase/functions-samples/blob/master/nextjs-with-firebase-hosting/src/functions/index.js#L25 ?

[babichjacob]

Is this something like https://github.com/firebase/functions-samples/blob/master/nextjs-with-firebase-hosting/src/functions/index.js#L25 ?

Sure. You can do it just like that in Sapper now.

I'm realizing now this is probably wrong, but I was originally anticipating adapters would be able to split each page into its own Cloud Function, which should (hypothetically) reduce each one's cold start times, but it doesn't seem like even the Vercel adapter does that, so that's probably not the case.

[jthegedus]

Yes, this adapter works like the Next.js Firebase ones (of which I was the original author) whereby there is a single function for the whole ssr application.

Cold start times would actually be increased with a function per route as the likeliness a function for a route would be warm is lower than if all pages shared the same function.

Nonetheless, my stance on cold starts is this:

• I have never witnessed the coldstarts being more than 1-2 seconds for an SSR app. If it is there are ways to improve the code to reduce this.
• If you have no restrcitions on tools you can use, Cloud Run is better suited to SSR apps and can be used with Firebase Hosting (and the Node adapter, though a Docker one may be useful). Cloud Run can mitigate cold starts much with Minimum Instances and (Concurrency](https://cloud.google.com/run/docs/configuring/concurrency). However, I am confident Cloud Functions is good enough for most people.

Vercel may in-fact split each route to it's own Lambda, but that would be internal to their platform.

[mankins]

@babichjacob @jthegedus Thanks for the pointers. I'll give both approaches a try. Cloud Run does seem to offer some advantages.

[jthegedus]

I've decided to add support, and actually recommend, Cloud Run for the adapter because the Functions deployment flow is very hacky (as it was with Next.js) and Cloud Run is much easier with some recently added features.

[mankins]

That makes sense. I got Cloud Run up and running without much fuss...vs the not quite working Functions route.

[babichjacob]

Is there still going to be an opening for people to make Cloud Functions for non-SSR purposes (e.x. with Firestore triggers)?

[jthegedus]

@babichjacob Yes there is. The example(s) I am testing with at the moment are have both the SSR function (either Cloud Run or Cloud Function) with the regular functions folder and deployment process. I will be going back and updating my Next.js SSR examples after this to support this too. With Cloud Functions it is more 'hacky' than with Cloud Run, which I am preferring for my own sites and will recommend in the adapter.

Integrating the Cloud Function SSR with other Cloud Functions that are written in TypeScript introduces some annoying deployment process dependencies, whereas Cloud Run's deployment is entirely separate and thus easier to manage and less error prone.

[babichjacob]

What are things like now?

[jthegedus]

This is what I have been using/working on - https://github.com/jthegedus/svelte-adapter-firebase

Again, not stable until SvelteKit is. I only check for new SvelteKit versions and test compatibility every few days, so it can potentially end in a bad state.

Working with latest version (at time of writing) which is @sveltejs/kit@1.0.0-next.20

[jthegedus]

@babichjacob My adapter is somewhat stable now, with the config not having changed now in ~3 major underlying rewrites. I think it is in a position to introduce here. I am happy to tackle this should you not have the time

[babichjacob]

@babichjacob My adapter is somewhat stable now, with the config not having changed now in ~3 major underlying rewrites. I think it is in a position to introduce here. I am happy to tackle this should you not have the time

I was already willing to tackle this during the "unstable" stage! It was only a matter of prioritization / finite time available that prevented me from ever doing so.

I think there are more things for me to clean up in this adder to make it match the capabilities (like build agnosticism) of the other ones. Continue--like over the past few months--being patient with me about that.

In the meantime, you can open a draft PR and just keep pushing commits in there or write a quick rundown of what the #1 static site solution and what the #\1 SSR (+ endpoints) site solution are so it'll be easier when I start.

Whatever you can justify spending time / resources doing, thank you!!

[jthegedus]

I will leave this for you then if there's other changes in flux. I'm time constrained by asdf atm. Thanks for your work on this project @babichjacob 🙏, make the setup of tailwind so much better for non-experts haha