Firebase & Google Cloud: What’s different with Cloud Storage?

Doug Stevenson

·

Follow

Published in

Google Developers

·

5 min read

·

Mar 16, 2019

--

7

Listen

Share

In my previous posts about the relationship between Firebase and Google Cloud Platform (GCP), I talked about what’s different between the two for both Cloud Functions and Cloud Firestore . In this post, the topic will be Google Cloud Storage ( Firebase , GCP ), a massively scalable and durable object storage system. In this context, an “object” is typically a file ? a sequence of bytes with a name and some metadata.

It’s tempting to think of Cloud Storage like a filesystem. In many ways it’s similar, except for one important fact: there are actually no directories or folders! Here’s how it really works. The top level of organization is called a bucket , which is a container for objects. Each bucket is effectively a big namespace full of objects, each with unique names within that space. Object names can look and feel like they have a directory structure to them (for example, /users/lisa/photo.jpg), but there are no directories or folders behind the scenes. These path-like names are helpful for organization and browsing in both the Cloud and Firebase consoles. Sometimes, we just use the word “folder” to make it easy to describe these paths.

Here’s what the Cloud console looks like when you’re browsing the contents of a storage bucket:

And here’s what the Firebase console looks like for the same bucket:

You’ll notice that the Cloud console puts a lot more data and functionality on the screen than the Firebase console. The Cloud console exposes the full power of Cloud Storage, while the Firebase console exposes only those features that are likely to be important to Firebase developers. That’s because the use cases for Cloud Storage tend to be a little different, depending on your perspective.

For Cloud developers

Cloud developers are often also enterprise developers. And, as you might guess, enterprise developers have broad requirements for object storage. They’re using Cloud Storage for backups and archives, regional storage, hosting static content, controlling access to objects, versioning, loading and saving data in BigQuery, and even querying data directly. Cloud Storage is very flexible! A majority of the access to an object comes from backend systems, often other Cloud products and APIs, and the SDKs . But for Firebase developers, the use cases are typically more narrow.

For Firebase developers

The most common use case for using Cloud Storage in a mobile or web app is handling user-generated content. A developer might want to enable users to store images and videos captured on their devices, then let the users view the files on other devices or share them with friends. Firebase provides SDKs (Android, iOS, web, Unity, C++) for uploading and downloading objects in storage, directly from the app, bypassing the need for any other backend components. To help with privacy and prevent abuse, Firebase also provides security rules , paired with Firebase Authentication , to make sure authenticated users can only read and write the data to which they’ve been given permission. Collectively, these SDKs and security rules are referred to as “Cloud Storage for Firebase”.

When you create a Firebase project, or add Firebase to an existing GCP project, a new storage bucket is automatically created for that project. This helps reduce the amount of configuration required to get started with Cloud Storage in a mobile app. Since all Cloud Storage bucket names across the entire system must be unique, this new bucket is named “[YOUR-PROJECT-ID].appspot.com”, where YOUR-PROJECT-ID is the globally unique ID of your project. You normally don’t even need to know this bucket name, as it’s baked into your Firebase app configuration file. When Firebase gets initialized, it’ll automatically know which bucket to use by default. In fact, this bucket is usually referred to as the “default storage bucket” for Firebase.

For everyone

All that said, Firebase developers are not limited to using only Firebase SDKs, and Cloud developers can opt into using Firebase to read and write existing buckets. If you started out with Firebase, you can use any of the Cloud-provided tools, SDKs, and configurations at any time. And if you have existing data in Cloud Storage to use in a mobile app, you can certainly add Firebase to your project to make that happen.

Everyone who wants to access a Cloud Storage bucket from the command line can use gsutil , provided their Google account is authorized to do so. gsutil provides commands to upload and download files locally, and to configure a storage bucket. It’s often more convenient to use this tool rather than either of the web consoles, especially for bulk operations.

Access control: which is used?

There’s one interesting difference between Firebase and Cloud. As you’ve just read, they both provide access control to objects in storage buckets, but those rules are mutually exclusive from each other. You use Cloud IAM to control access to an object only from backend systems and SDKs, but you use Firebase security rules to control access only from mobile applications using the Firebase client SDKs. These access control mechanisms don’t overlap or interfere with each other in any way. Note that the Firebase Admin SDK is actually a server-side SDK, which can also be used to access Cloud Storage. In fact, the API it provides is actually just a wrapper around the Cloud SDKs , which are controlled by IAM.

How are you using Cloud Storage? I’ve used it in a couple experimental projects. There’s a connected video doorbell that stores images of guests who ring the doorbell and a “ universal translator ” that translates speech recorded on a mobile device. Check those out, and let me know what you’ve built as well!