svelte-add / firebase-hosting

⚠️ MOVED: https://github.com/svelte-add/svelte-add/ ⚠️ A command to add hosting on Firebase to your Svelte project
MIT License
7 stars 1 forks source link

Support for Cloud Functions and SSR #1

Open babichjacob opened 3 years ago

babichjacob commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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:

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

mankins commented 3 years ago

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

jthegedus commented 3 years ago

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 commented 3 years ago

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

babichjacob commented 3 years ago

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

jthegedus commented 3 years ago

@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 commented 3 years ago

What are things like now?

jthegedus commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 :pray:, make the setup of tailwind so much better for non-experts haha