From what I can infer from the Firebase docs, it seems that
a server is required to serve the static content (the html
and javascript), so you need to have a hosted machine and a
static content server up and running somewhere, or some service
to host a static site.
Is that correct ?
Throughout the Firebase site they repeatedly mention the
"no server needed" concept, so I was initially thinking
that Firebase did provide a mean to serve static content,
but there is no mention of it in the docs.
Did I miss something ?
UPDATE
Firebase does offer static hosting now, see link in answer below.
Firebase isn't a replacement for servers in every situation, but in some cases you can use Firebase instead of a server, or reduce server code you would otherwise have to write and maintain.
If you want to serve static HTML/CSS/JS to browsers great, but Firebase won't do it for you (you would at least need to jumpstart it). In this scenario you could serve assets on any cheap hosting site, but then make those traditionally static assets data-driven via Firebase without writing any server-side code.
The docs refer to "no server needed" scenarios because traditional web applications aren't the only use-case. You could build entire real-time mobile applications or browser extensions without hosting or serving anything yourself.
Firebase now offers hosting (in Beta) for your static asset files, so they are even more a "one stop shop".
https://www.firebase.com/docs/hosting.html
Related
I am having an issue with using Next.js API routes when deploying my website to Firebase Hosting. Here is the api call:
And here is the set up in the pages directory:
Here is the function used in email.js:
I changed the variables as to not give away my email address.
The call works when I use local host. However, when I build and deploy to firebase. I have tried to use the firebase url to make the api call, but I get a 404 page not found. I am not sure how to fix this. I would really appreciate any help.
Firebase hosting only hosts static files which is why your api routes don't work there. If you had a fully static Next site, you could host it on Firebase hosting. But if you want to use the api routes in Next, you need a server. One way to do this (albeit complicated) is to set up Firebase Functions with your api code and then rewrite requests in Firebase Hosting to that Firebase Function. It's complicated because it would require a fairly complex deploy process.
If the rest of your site is static, you can use Firebase Hosting for that and then consider ditching the api routes and instead setting up a Firebase Function to act as your api completely separate from Next.
Or if you want to keep it all in Next, consider something like Vercel for your site + api via Next.
I'm currently creating a website that is hosted on a vServer from another provider where you can upload images. I'm uploading the images to Firebase Storage. Can I change the domain when I rightclick -> view graphic that is my own domain? I already know that you can change the domain of firebase when you host the website there, but I don't want to host the website there.
There is no way for you to control the URL that is used to serve files directly from Firebase Storage. The download URLs are controlled by Firebase and always are based on your bucket/project name.
But Firebase server-side logic is a fairly thin wrapper around Google Cloud Storage, and you can set up a custom domain for Cloud Storage. You can ignore the parts that talk about this as being specific to hosting a web site there, as a web site on Google Cloud Storage is not much more than the files it consists of, you can apply the same to hosting other files. That should allow you to control the domain from which your files are served.
The final alternative would be to host the files on Firebase Hosting, which means they'll be served from a CDN with many global end points. The main difference here is that Firebase Hosting is typically better suited for files you generate, and not so much for files that your users generate.
I have a Vue.js app and use Firebase Hosting to serve the static files to users.
Does Firebase Hosting have a method for putting the app into maintenance mode remotely? Without having to do firebase deploy
Maybe something that will allow me to redirect all the traffic to some other index.html, and be able to manage it from Firebase.
P.S. I've already looked into Firebase Remote Config (and it doesn't fit my use case, and their web related tools aren't fully implemented yet). And I'd like to avoid having a realtime database just for maintenance mode.
There is no mode-switch built into Firebase Hosting for temporarily serving other content.
But given the recent updates to deploy efficiency, it should be pretty low-cost to put up a temporary index.html while making the changes. Alternatively, you could deploy rules (in firebase.json) that temporarily redirect all traffic to a wip.html (for work-in-progress).
Which of these works best, depends on your current content structure. I.e. if you already redirect "all" traffic to index.html, I'd probably go with a rewriting solution.
You can also unroll your last deploy in one command.
Deploy maintenance page
Unroll when its done
Don't forget to send a 503 error for googlebot, asking it to come back in X hours.
I have an AngularJS WebAPI application that has a Javascript front-end. The front end makes calls to the back-end WebAPI for data. In the future there may well be more than one front-end making calls to the back-end.
I would like to change this application to use HTTPs and am looking into how to best architect this. The way I see it there are two ways (maybe more).
(1) Host the WebAPI C# application, index.html, Javascript, Javascript libraries and other HTML on the one (or more) web roles.
(2) Host the index.html, Javascript, Javascript libraries and other HTML on a CDN and put the WebAPI C# application on one (or more) web roles at one location.
From a performance point of view are there likely to be any issues with the split solution (2) when I am using SSL. Is there anything that I should consider that might help improve the start-up time (my goal is for this to be as fast as possible).
One more question I have. If I were to use the Azure CDN then would I still be able to address the index of my web site as www.mywebsite.com and if using HTTPS would I need a SSL certificate?
Option 2 is more preferible.
You have to think, that your application is what sits in the backend. The front end is just a suggested set of UI controls and interactions to consume that application you have. Then, if you can host them separately you have some benefits, starting by not creating UI dependency.
The approach would be like creating a thin client.
Since the application is AngularJS based, probably all the UI are static files with HTML, CSS, and Javascript. You can host them in BLOB storage, and scale it through the CDN. You can have a custom domain name pointing to Azure Blob Storage, like `www.yourdomain.com. It has many benefits, including better price and scaling than web roles. Put aside, that you pay for web roles no matter if you are getting hits or not. The only downside is that as far as I know, it would not be possible to use HTTPS, but that should not be a problem, since you are just hosting static content and templates that contains placeholders, no actual data.
On Blob storage, you can attach your own cache control headers, allowing the browser to cache those files locally. Then a user would download those files once, and be recovered from the browser cache next times. Also, you can store the content already compressed in GZIP, and then set the content encoding property to let the browser know it is compressed, therefore enabling a faster content download. Not forget you should bundle your resources. For example, you should bundle all your JS code in one JS file, all your CSS code in one CSS file, and all your AngularJS views should be bundled in the template.js file (also bundled into the unique JS file).
You need to host your backend application in worker/web role instances though. Here you can use HTTPS, and it would be no problem to use AJAX over HTTPS, although the page loaded on HTTP as long the SSL/TLS certificate is signed by a CA recognized by the browser (ie: a valid certificate). If you use a self-signed certificate, there will be no way for the browser to prompt the user to accept it. Keep this in mind if you plan to start with a self-signed one.
So then you would have all the things that are not user/state dependant in blob storage, that is cheap, fast and highly scalable; and all your user data interaction would happen through your worker/web roles through compact data request/response probably in JSON. Therefore you need less web/worker roles for providing the same level of service.
Now, if you have a very asymmetrical amount of massive queries and data changes request, you should consider an approach like CQRS.
After I migrated my site from AzureWebsites to a Azure Cloud Service, i'm having some issues with the migration and I think are related to IIS (and my lack of expertise of it).
The issue is some times i can't display a image that works just fine. One test method to get that is to refresh many times the image's url and sometimes I'm forward to PageNotFound.
I've an url path for images /Clients/{id}/Images to get the avatar, which is the same relative path for the folders.
I already gave full permissions, ignored this route to no avail. Any suggestions?
Are you by chance letting your clients upload images directly to your IIS machines? If so, do remember that Azure Cloud Service Roles run on distributed machines... so, if one of the web servers gotten the image to its local store, the others did not.
Thus, you want to make sure you store your uploaded content on shared resource, in Azure's case the best place is Blob storage.
HTH