There’s one super-important thing to know about these project containers. Since the underlying project is the same for both Firebase and GCP,
if you delete the project using either Firebase or the Cloud console, you will delete everything in that container, no matter where it was configured or created.
So, if you created a project with the Cloud console, then add Firebase to it, then delete the project in the Firebase console, all your Cloud data will also be deleted.
An existing GCP project can be configured to add Firebase services
Now let’s imagine, instead, that you’ve created a project in the Cloud console. At the outset, your project won’t have anything directly related to Firebase configured in it. After all, the Cloud console doesn’t know if you intend to build a mobile app, so why set that up? But if you have an existing Cloud project, you can very easily add Firebase to it.
To add Firebase services to an existing project, go to the Firebase console, click the “add” button. When it asks for your project name, you have the opportunity to choose an existing project from the dropdown that shows your existing projects that don’t have Firebase added.
When you select a project and proceed from this point, all the APIs and services that power Firebase products will be automatically enabled in your project, and you’ll be able to use the Firebase console to work with those products.
If you’re wondering what exactly I mean by “
APIs and services
”, this is a GCP concept that’s only visible in the Cloud console. Here’s a screenshot of the APIs and services dashboard from the Cloud console after Firebase has been added to a project:
Here, you can see a number of APIs (enabled by default), along with some Firebase product APIs highlighted in the red box. This detail of enabled APIs is hidden from developers in the Firebase console, because it’s not really necessary to know. However, knowledge of GCP APIs and services gains importance as an app’s backend becomes more sophisticated. For example, an app developer might want to make use of the
Cloud Vision API
to extract text from images captured by the device camera. And then, go further and translate the text discovered in that image using the
Cloud Translation API
. To use these APIs (and get billed for them), you have to enable them in the Cloud console. Once enabled, you can call them from your backend code (deployed to Cloud Functions, for example).
As you dig around in each console, one thing you might notice is that the set of products you can manage in the Firebase console has three items in common with the set of products in the Cloud console. These products are Cloud Storage, Cloud Firestore, and Cloud Functions. While each product is the same at its core, regardless of where you’re viewing it, they are each organized and managed in very different ways between the Firebase console and the Cloud console. This leads me to my next point.
Firebase adds SDKs, tools, and configurations to some Google Cloud products
As you might guess from their names, Cloud Storage, Cloud Firestore, and Cloud Functions are Google Cloud products. Technically, they are
not
Firebase products, even though you can work with them in the Firebase console and manipulate them in your app using Firebase SDKs and tools. First, some quick definitions:
- Cloud Storage (
Firebase
,
GCP
) is a massively scalable file storage system.
- Cloud Firestore (
Firebase
,
GCP
) is a massively scalable realtime NoSQL database.
- Cloud Functions (
Firebase
,
GCP
) provides serverless compute infrastructure for event driven programming
Without Firebase in the picture
, these Cloud products are typically used in enterprise environments, where data and processes are mostly controlled within Google Cloud, or some other backend. To work with these products programmatically,
Google Cloud provides client APIs
meant for backend code, along with the command line tools
gcloud
and
gsutil
.
With Firebase in the picture
, these three products are enabled to work seamlessly with mobile apps by providing
additional SDKs
for mobile clients,
additional tooling
with the Firebase CLI, and a way to configure
security rules
to control access to data through the provided SDKs. I’ll talk about some of the specifics of these Firebase additions in future posts.
(Since I mentioned Cloud IAM earlier, I should also mention that Firebase offers
additional IAM roles for some Firebase products
that give other members of your team granular access to those products, without the risk of them making a dangerous change elsewhere in your project.)
Note that the names of these three Cloud products don’t change from a Firebase perspective. I know it’s tempting (and natural!) to say things like “Firebase Storage” and “Firebase Functions”, but these names aren’t accurate. Am I being pedantic about this? Perhaps, but you won’t find these names anywhere in formal documentation! However, you
will
see names like “Cloud Storage for Firebase” and “Cloud Functions for Firebase” when dealing with the Firebase add-ons for these Cloud products.
OK, what’s the upshot of all this?
If you’re a Firebase app developer, you probably created your project in the Firebase console. But, at some point, you might need to jump over to the Cloud console for some administrative tasks, to expand your cloud infrastructure, or make use of Cloud APIs. The Firebase console is
just the beginning
to build out the infrastructure of your mobile app.
If you’re a Cloud infrastructure developer, and you want to build mobile or web apps against the data you’ve already stored, you’ll need to jump into the Firebase console to deal with configurations and tasks that are unique to the Firebase additions to some Cloud products.
In fact,
Actions on Google projects are also GCP projects
(if you’re working with DialogFlow). These projects
have Firebase enabled by default
, so that’s another way you could end up with a new perspective on a GCP project. In any case, no matter how your project came into existence, the console you started with might not end up being the only console you use. Thinking of a project primarily as a container for services and APIs makes this transition easier. Each console is just giving you a view of those services and APIs in a different way.
Read more about the differences between Firebase and Google Cloud with respect to these products:
