My question consists two parts
What if I turn off Firebase billing and switch to spark plan will all cloud functions will be deleted?
Can I turn off billing using cloud functions and puppeteer to prevent myself from attack?
According to the documentation, your data is not getting deleted but your project loses access to paid features.
There is an example of how to stop billing using Cloud Functions described in the automated cost control responses guide.
Related
Is 125k invocations per month for Firebase cloud functions applies to admin-sdk used on custom server? How price of cloud functions is calculated if used with admin sdk on self hosted server?
The 125k invocations per month you are referring to is talking about how many times a Cloud Function is executed/triggered (the term used by Firebase here is invoked). Use of the admin SDK on your own hardware/third-party server doesn't make use of Cloud Functions and is unrelated to the invocation limits.
Let's say you set up a HTTPS Cloud Function called date. Each time a user visits https://us-central1-<project-id>.cloudfunctions.net/date, this would count as 1 invocation of that Cloud Function (ignoring response caching/use of a CDN).
Another example is listening for new data in Cloud Firestore that you can call createUser. Each time a new users/someUserID document is created, the createUser function would be invoked.
For such trivial use cases, you aren't likely to hit the 125k limit. But if you have Cloud Functions that deal with frequently modified data or rapidly triggered pub/sub topics, you can quickly approach these limits if care is not taken.
One example of this is if you set up a RTDB Cloud Function that was incorrectly listening to any data under /posts. Every time a user (or server) changed any data under /posts, the function would be invoked. If your cloud function updated /posts/count everytime it was called, the cloud function would retrigger itself leading to an infinite loop.
Is 125k invocations per month for Firebase cloud functions applies to admin-sdk used on custom server?
Cloud Functions billing is not at all related to whatever billing is incurred by the Admin SDK. If you use the Admin SDK, you will be billed according to the products it uses, in addition to whatever billing might happen for Cloud Functions.
How price of cloud functions is calculated if used with admin sdk on self hosted server?
It's not possible to self-host Cloud Functions. Cloud Functions only runs within Google Cloud infrastructure.
If you use the Admin SDK on your own host, outside of Cloud Functions or any Google Cloud hosting, it does not change the billing compared to the same usage in Cloud Functions.
If you want to know what the cost is for using the Admin SDK, you should understand which product you are accessing with that SDK, and look up its own pricing. The Admin SDK itself does not bill - it is the usage of the underlying Firebase or Cloud product that incurs billing.
My straight question is: since I am not interested in other Google Services, only Firestore, what is the difference between Firebase Cli and gcloud? Can I do all I need only with Firebase Cli or should I learn also gcloud?
I can easilly see that gcloud can handle more services than Firebase Cli. Also I can see Firebase Cli remenber me a lot the purpose of npm+ng cli when working with NodeJs/Angular (a simple analogy about scaffold/initialize/deploy). Nevertheless, our company will only use Firestore to take advantage of its Realtime Database pushing events to our mobile application.
I use Firebase Cli to type in my Windows command line and create a project in Firebase. I can see the result in Firebase Console and I also can see it in Console Cloud Plataform.
For me, who is total beginner with Google Cloud Plataform, it is a bit confused when prefer one over other. For instance, let's say I want to query data from Firebase Crashlytics from command line instead of logging from my Browser. Is it possible to use either Firebase Cli or gcloud? If both, which one is recommended for some company only interested in Firestore project?
This week I am struggling to figure out how to extract metrics regard my Firestore project and if I don't know what is the recommended tool for reach this task it make even harder to find the first steps. By extracting I don't mean see a beatifull dash in Google Console. I mean consume an endpoint providing me Firestore Metrics or, even better, subscribe my endpoint to Firestore project which will be called every time some issue happens (Other question asking exactly about getting Firestore metrics)
It is confusing and is partly the result of Google's acquisition of Firebase, the creation of what's now called Firestore (which is the unification of the original Firebase backend technology and Google Cloud Datastore), and that Google provides the Firestore service to both its Firebase and Google Cloud developer audiences.
As you've gathered, Google Cloud's CLI (Cloud SDK aka gcloud) and the Firebase CLI overlap in functionality. However, importantly:
both CLIs interact with a shared set of Google services (e.g. Firestore, identity, logging etc.).
there are some Google Cloud services not part of Firebase and vice versa
If you're focused on Firebase, you should be to able to stick with the Firebase CLI and continue to interact with Google's services through this Firebase lens.
If you include Google Cloud Platform services that aren't part of Firebase, you'll need to then consider using gcloud but importantly, you can either:
continue to use the Firebase CLI for the Firebase services;
use gcloud to interact with some (not all!) of the Firebase services (e.g. Firestore).
Over time, I assume (!) the remain discord between these 2 platforms will diminish.
If you consider both platforms as the result of (an ongoing?) unification since the acquisition, hopefully, these discrepancies will be more understandable and less frustrating.
Where you do find inconsistencies and frustrations, ensure Google knows by submitting feature requests and bugs.
Hi I am using firebase and the firebase functions.
1 day ago I received an email from Google Cloud with the following content:
Starting April 20, 2020, Cloud Functions will use Google Cloud Build, Container Registry, and Google Cloud Storage to build and store your source code, and deploy container image(s) before running them on Google Cloud. You must enable the Cloud Build API for your project(s) to ensure your Cloud Function is built and deployed correctly. Once you enable the API, you may incur charges if your Cloud Build, Container Registry, or Cloud Storage usage exceeds the free tier limits for these products. You can find a list of your projects that are using Cloud Functions and may be affected by this change at the bottom of this email.
I tend to avoid tinkering the Google Cloud (or even logging in there) as I am using the Firebase as an all inclusive solution and so far I did not have the need to login there.
Now the question:
Do I need to follow the instructions and take action, or is this something separate from the Firebase Functions?
The "affected" project that is mentioned on the email is the Firebase project
To be able to use cloud functions after April 20, 2020 you must enable the Cloud Build API because this will be a new deployment framework.
You will not be able to use cloud functions if you do not enable the Cloud Build API after this date.
These changes will apply even for Firebase cloud functions.
I believe you will need to do it only if you are going to deploy Cloud Functions in the future, Cloud Functions already deployed will not be affected.
In case you are worried about billing, Cloud Build provides a free tier where only usage above 120 build-minutes/day will be charged. When your usage is within the free tier, you will not be charged for the Cloud Build portion of Cloud Function deployments. See Cloud Build pricing for more information.
Similarly, Cloud Storage and Container Registry share a free tier where only usage above 5GB-months will be charged. ( * Note : free tier only limited to US regions - US-WEST1, US-CENTRAL1, and US-EAST1 and aggregated over all 3 regions ) For example, if you have a large deployment that uses 100GB of storage, you will only be charged an additional $2.47 for storage/month (based on these particular U.S. regional storage prices).
You can monitor your usage and see whether you are getting close to hitting the free quotas.
This is a best effort from Google to communicate information that is necessary to the user’s continued use of the product or that is considered a necessary legal update and keep customers away from having future issues
Using Cloud Build, Container Registry and Cloud Storage provides the following benefits:
Detailed function build logs will be available in the GCP Console, aiding in debugging and increasing visibility.
The ability to get build time that exceeds the current build quota of 120 build-mins/day.
The ability to view a built container image for your function in Container Registry.
Is there any way to check how many read/write on my app on Cloud Firestore?
There currently is no API to get the number of reads/writes from Cloud Firestore. Neither the client-side SDKs nor the server-side Admin SDKs expose this functionality.
The closest I can think of is something based on StackDriver monitoring that you can set up for Firestore. Based on that you can then wrap the StackDriver monitoring API in a custom end point (either in Cloud Functions or elsewhere).
I've got 2 different firestore interfaces: both using the same firestore project.
I'm finding this abit confusing - which one am I meant to operate in?
How come the 2nd doesn't have access to other settings such as Rules?
They are both meant for you to operate in. Which one you use depends on whatever your preference is. If you prefer to stay in the Firebase ecosystem, then use the Firebase console. If you prefer to stay in the Google Cloud ecosystem, then use the Cloud console.
Read more about the differences with Cloud Firestore between Firebase and Google Cloud.
Cloud Firestore is available with, or without Firebase SDKs.
For Firebase users, the Firebase interface allows you to configure Firebase specific functionality (Rules).
For GCP users, the Google Cloud interface keeps you closer to other services and admin settings you'll likely be using, such as IAM, BigQuery, etc. It also gives you quick access to a shell (Just click the Cloud Shell icon) so you can quickly run commands like gcloud firestore export.
Both interfaces will show you the same data.
Work in the first one. The second one is a simplified screen I think, because it is also for other services