I have a small firebase project site that I've been working on and is now public and gaining more traction than I thought. I doubt I'll hit Firebase's 10GB hosting transfer cap, but this got me thinking as to whether or not I'd be better served storing my site assets in Firebase Storage, and if that would help at all. I'm a bit new to these cloud service pricing models, so any help would be greatly appreciated. Boiling it down, here are my questions:
I have 20mb of assets currently stored in a /rsc/ directory on my hosted site. Would it lessen my Hosting "Data Transferred" to move these assets to Firebase Storage (Would the data transferred be logged under my Storage quota)?
Yes, if you put the files in Cloud Storage instead those will not be counted against the Firebase Hosting bandwidth limits. However, you will lose out on the global CDN edge-caching and atomic rollout/rollback provided by Firebase Hosting.
Related
I want to know How many times can freely deploy project using firebase hosting spark plan?
I search google this problem after i found this answer. any one can explain?
" Firebase imposes hard limits on the number of simultaneous connections to your app's database. These limits are in place to protect both Firebase and our users from abuse. The Spark plan limit is 100 and cannot be raised. "
There is no limit on the number of times you can deploy a web site to Firebase Hosting, neither on the paid plan nor on the free plan. The only limits are documented on Firebase's pricing page and are (on the free plan) around the storage size (10GB) and bandwidth (360MB/day).
Each deploy adds to your storage size though, so if each deploy of your site is 100MB, you will run out of space after 100 deploys and further deploys will start failing. See firebase free hosting limits
At this point you can clean up your older deploys through the Firebase CLI or console, to make space for new ones. For more on that, see How to clean old deployed versions in Firebase hosting?
I have deployed my site with Firebase using my customed domain.
I checked my db usage and it seems fine (couple of megas) but then I go the hosting section and then the usage tab and see almost 1GB downloads, do you know what do the downloads in the hostage section mean?
It means that almost 1GB of data was downloaded from Firebase Hosting in your project.
If this is higher than you expected, you might want to check for the size of your files. Do you have any images? How big are those? How much data will each client read from Firebase Hosting? How many clients do you have? If you have a few large files that everyone loads, it adds up quickly.
I just setup a Firebase Hosting and deployed it.
My question is, can I use this hosting as a cdn to load content on my other already published site?
Is this a good practice?
Also, is there a limit on firebase hosting requests?
If for e.g. there are too many requests to a particular file type, does it still work or will it throw any error?
Firebase hosting is advertised by Google as edge optimized SSD storage in their CDN infrastructure. Google's documentation suggests that this is a supported use case.
If you are already using firebase, that should work for you. Implement, measure. Keep measuring as traffic volume and patterns change.
If it isn't meeting your needs, move to a different CDN solution.
I want to host my static webapp created with Next.js' export function on firebase. The app rebuilds itself to static html when changes in the underlying database are made. Since I can't directly deploy this static pages automatically to firebase hosting, I tend to serve the static files from with.
So, are there any downsides of serving static html content with Express.js inside firebase function compared to using firebase hosting?
Especially with regard to: Pricing, Security and Performance/Speed.
We hosted our site (https://mfy.im) under Firebase hosting, it's generated using nuxt, similar to your next.js. We've compared many other static hosting sites including Netlify, S3, etc. Firebase hosting was the best in performance
Even though Express can serve your static files, it's not recommended. Firebase internally uses Nginx. Nginx is super fast in serving static files and it's multithreaded. In Nginx, its easy to confiture http2, gzip etc. (full http2 support is recently released in Node 10, gzipping files in node js is also not that performant since the node is single threaded)
Other advantages of Firebase hosting is its edge servers, built-in CDN, SSL etc. A copy of your site is deployed on multiple servers all around the world which results in low latency. I've tested Firebase CDN vs CloudFlare, again Firebase was the best
Regarding Pricing, Firebase hosting comes with a free plan of 10GB bandwidth. It should be efficient for small-medium websites. If your bandwidth usage is higher than that you can go for 'Pay as you go'. However, if you're worried about pricing you can combine Firebase hosting with CloudFlare CDN so that CloudFlare will cover most of the bandwidth
I would like to run multiple WordPress instances using Azure Application Service and have a dedicated VM running their MySQL databases.
Let's say each Wordpress site was a gig in size (uploaded files not database) and my App Service plan comes with 50gig storage. This means I could theoretically run a max of 50 WordPress sites on that
plan.
Is it possible to link a blob storage plan to my paas plan and have all WordPress sites stored on the additional storage plan?
I know there is an outdated WordPress plugin that supposedly stores uploaded media on Azure storage plans. I'm not interested in that. I want all WordPress files stored and served from a separate storage plan.
If I was to spin up a VM running IIS I imagine I could do this by simply pointing each IIS site to each WordPress install on a storage plan data disk. Just wondering if I can do the same using Paas?
Technically App Service is already doing this. Your 50GB of space is in Blob Storage. But as you suspect, you have no control over this yourself. If you want/need that level of control, then you need to switch to a VM as you suggested.
This is exactly why the storage plugins were built, to move the uploaded media files into Blob Storage to maximize available space and improve performance.
Another way to save "local" space would be to run as a multisite if possible. Then you would only need one copy of WP and any plugins in common for the various sites.