#Firebase hosting does support SSR with
1 messages Β· Page 1 of 1 (latest)
@raw summit what is the difference between firebase hosting vs. firebase app hosting?
essentially
pretty much everything is recapped here
but in short
Firebase App Hosting is the brand new thing made for Frameworks
And so in the end
Firebase hosting will be more for server redirections, files and static websites
whereas Firebase App hosting will be for web apps (PWA) and SSR websites
BUT
it's very very new
and so it means that currently there isn't much documentation about firebase app hosting
and also that it only supports Angular and Next.js
So based on the framework you wanna use
it might be a better solution for you to use the classical Firebase hosting with cloud functions as SSR
(they have an automatic tool that does everything for you)
then wait for them to release official support for your framework :)
(or just more documentation lol)
got it, do you have any experience with universal apps deployments like nuxt?
i am trying to understand how firebase splits/handles the front-end vs. server routes part of things.
my current deploy is on heroku where there is a single nitro server running handling everything (front-end / server routes) but it seems with firebase this gets split and the server routes run on cloud functions? so not sure how that works with SSR
haven't used nuxt in particular but i've been doing a lot of web stuff the past few years x)
yup exactly
essentially the cloud functions do all the server side stuff
(cloud functions is just a fancy name for a containerized Node server solution xD)
so in the end it really just runs your server
so for each page route there is a cloud function rendering on the server before returning the payload? and if your page component is calling a server route it knows how to get to the cloud function where that function is hosted?
oh
and the output of the SSR goes to firebase hosting kinda
usually it works with a single cloud functions for all pages
oh so in the end its just a containerized instance of the nitro server?
kinda like a normal node server
(not sure about nitro but i guess so)
but essentially it's a container for a JS script
(so it can run anything really)
ah yeah sorry you mentioned you arent familiar with nuxt (nuxt uses nitro [ a wrapper around h3 from unjs] as the web server for universal apps)
ah gotcha
got it, i thought maybe they were somehow creating a unique cloud function for each server route
so it's kinda an express server with additionnal stuff?
exactly!
ah yeah then it should run fine π
h3 basically says that express sucks so they made a cool hipster new one
i think they're going with a single cloud function for every route that way they don't have to dynamically handle cloud functions when you edit your code
but also so it stays on when users change routes
otherwise if there was a brand new user accessing the website, it would cold start a new server for your first page (cloud function)
then when they change pages it would start another instance somewhere else x)
(would be kinda inefficient i guess)
yeah makes sense
so instead it keeps the instance running until it goes idle
its funny they call it cloud functions vs. just a container for your backend
yeah x)
probably more people would be comfortable with that
i think it's mainly due to it's original nature
serverless functions always make people freak out caus they are hard to manage in complex situations
although the original promise sounded amazing
when it was first released it was kinda sold as a way to run your code functions directly on the cloud instead of locally
like straight from your code
so i gueeess the name comes from there? xD
Oh found the documentation i was looking for btw:
you might wanna look into that
what's a bit annoying though is that they don't show all the frameworks supported because it was kind of a test
heroku has a really easy way to boot up a redis for your backend
but I know svelte is supported for instance, yet it's not mentionned on the documentation .-.
and if it has a cron server?
but essentially just try to do a "firebase deploy" in the terminal and if it works it's supported, if it throws an error you gotta do what they say in the "express" part of the documentation pretty much xD
k
on google cloud very probably
oh yeah on cloud run you can set it up
and since Firebase is essentially just a cool interface with easy pre-made stuff for google cloud...
but i wondered if there was something more convenient
I don't think because they're heavily invested on their Firestore thing
on heroku you can add it as a 'add-on' for a given project so it just gives you a redis server running in the same server as your backend app, so you can use all the default connection information and not have to manage any netowrking
same with a cron server
(which kinda serves the same purpose in many cases?)
Firestore is document based
so you essentially have "collections" of a lot of JSON documents
that can themselves have sub collections
and so on and so on
But
if you want you can have a single document
with all your key: value pairs
in short it's a document based NoSQL server
gotcha
(with very practical SDKs)
ok wont work for my use case, im using bull for my queue https://www.npmjs.com/package/bull
which i think only works with redis
imo if you already have something built atm
it might not be worth to spend time transitionning to firebase
If I were you I would probably look into keeping it like this but just hosting it on Google Cloud
working with GCP itself IMO is super annoying
everything there is so 'enterprise' obonoxius
to be fair unless you're doing very-large scale stuff, it's essentially free ;)
I never paid a single cent to Firebase yet π€£
yeah i was hoping not to as well haha
GCP is tough yeah, and it has a steep learning curve at the start as well
like the fact that you go to 'demo' a feature and then it says, oh you need to enable this api for your account is like, .... i just said i wanted to demo it
it's like they're purposefully doing it hard to understand sometimes lol
that means i want it active
this.
x)
also they have 0 architecture diagrams
and write documentation assuming you already understand the lifecycle of their services
and you're like dude i dont even understand what you're talking about!
yeah totally get ya on that lmao
but in your usecase it might be still worth it to go straight to GCP if your project is large enough
because it's not "complicated"
as in like
yeah in the case ill just use cloud run
it's just hosting a web server + front end essentially if i got that right
so there must be a ton of videos on how to do that in a way that's optimized
even that, like why call it cloud run
just call it hosting
it doesnt need a cool confusing name
xD
I think it's to explicitely say it is constantly running kinda
like it's different than hosting on GCP
oh fair
(for instance Firebase hosting)
or maybe spot servers
(using cloud run)
but so stupid in real life
wait what's GCP Gemini?
its gemini ai 'trained' on GCP documentation so you can ask it questions inside of GCP
and its supposed to help you troubleshoot stuff
or debug error messages
well.. could π€£

