Knowledge of this relationship is important in two circumstances:

1. You’re a Firebase app developer, and you need to expand your backend infrastructure beyond what Firebase provides by default.
2. You’re a Google Cloud developer, and you want to build a mobile (or web) app on top of your existing infrastructure in GCP.

• Even if these situations don’t (yet!) apply to you, understanding how the tools and services are related should help reduce the friction you might encounter with some tasks, especially regarding your Firebase app.

A Firebase project is also a GCP project

When you create a Firebase project, you are actually creating a Google Cloud project behind the scenes.

This means that you can view and manage many aspects of your Firebase project in the Cloud console.

don't forget !

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

But if you have an existing Cloud project, you can very easily add Firebase to it.

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

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.

conclusion

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.

What’s the relationship between Firebase and Google Cloud?