[MUSIC PLAYING]
MARINA: Hi, everyone.
I'm Marina from the Firebase Team,
and today we are going to talk about how Firebase projects
and Firebase apps work.
See, we've got a lot of videos out there explaining how to get
started with the Firebase project,
but not very many explaining the structure of a Firebase
project, what it represents, or what a Firebase app means
in the context of a Firebase project.
That being said, this video will not
cover how to configure Firebase for your applications,
as we already have many videos that cover just that.
You can watch these videos right here
to get your first application configured
for your platform of choice.
The links are available in the description.
But if you want to understand the relationship
between a Firebase project and your applications
and the best practices recommended by the Firebase
Team, you've come to the right place.
So let's start by understanding what
a Firebase project represents.
If you're not super familiar, Firebase
is Google's app development platform,
and it consists on a suite of products that do everything
from storing your app and user data,
to sending notifications to your users,
to collecting data about crashes,
and many more things needed when developing, publishing,
and monitoring your application.
So let's dive into all that a Firebase project means.
First, it's the place where you can add and configure
different Firebase products and services for all
the variants of your app.
It's also where you can control which teammates
will have access to the services you are configuring
and what their roles are.
So you can say that a user is an owner, an editor,
or a viewer in your project.
Being an owner means that you have full access and edit
permission to all Firebase resources,
including user management, permissions, and billing.
Being an editor means that you have edit permission
to all Firebase resources.
And as a viewer, you can only view the Settings,
but you cannot edit any of the Firebase resources.
If your team needs more granular access control,
you can assign roles to specific teammates that
give them access to only groups of products,
but not all resources.
For example, you can give your data
management team access to your databases
and storage via the Develop Roles.
Or you can give your marketing team access to FCM
and in-app messaging via the Grow Roles.
You can even go more granular than groups of products,
and you can learn about those possibilities
by checking out the IAM doc links below.
Costs for running your app are usually a top concern.
And it's at the project level that you manage settings
for your billing information.
And you can also set up integrations
with other services to get alerts
about what's happening with your app and your Firebase project.
We'll talk more about project configuration and billing later
in this video.
And last, it's important to say that a Firebase project is
actually a Google Cloud project, but with all the Firebase
services enabled for it.
So you can view your Firebase projects in the Google Cloud
Console, and make any existing Cloud projects a Firebase
project as well.
Now that we understand what a Firebase project is,
let's check what an app inside a project is
and how these concepts connect.
When you open a project on your Firebase Console,
you can register each of your app's platform variants
with your Firebase project.
And if you've already followed one of the Getting Started
videos that we mentioned earlier,
you will see that app listed right here.
This page may look a little different for you
now, because we're always working
to improve the Firebase Console, but the general concepts
won't change.
At the moment, you can register apps for Android, Apple,
and web platforms, including your apps built
with Unity or Flutter.
The apps registered to the same Firebase project
should ideally have the same business use
case, where each app represents the same application, just
on a different platform.
This means that these apps will share the same resources
and services configured for that particular Firebase project.
For example, all apps splitting a project will
share the same database, the same user
base, the same analytics data, and so on.
So if you're developing two entirely different apps
with different use cases and different users in mind,
you should probably instead create two separate Firebase
projects, one for each app.
In addition to using the same resources,
the apps also share the same integrations with other tools.
For example, let's say you want to integrate your project
with Slack to send important alerts to your team,
or that you want to create an issue in Jira
as soon as a new crash is reported
within the Crashlytics.
Once these integrations are configured,
they start to take effect for all applications registered
in the Firebase project.
Now that we know what a Firebase project is,
what an application within a project is,
and how they connect, let's check out
the best practices recommended by the Firebase Team.
We have already let you in on the first best practice--
all apps registered to the same Firebase project
should have the same business use case.
However, there are times where you
will want to create separate projects for your apps.
Also, because of the way some Firebase products work,
there can be some significant implications
to consider for how usage and behavior can change,
depending on if you're using different projects
for your apps or the same project.
Let's walk through the motivations
behind each one of these approaches,
starting with using the same project for all your apps.
If you register all the platform variants
of your app in one project, that will allow your users
to sign into your application from any device
and not lose any data if they move
from iOS to Android or to web.
This is possible because these platform variants
share the same data and users from a single Firebase project.
Essentially, your users are viewing the same application,
just on different platforms.
But you can also register two apps
from the same platform in a Firebase project.
This happens when you have a paid and a free version
of the same app.
In this case, despite being divided
into paid and free versions, it's
still the same application, with the same Firebase services
and products configured.
Now, let's talk about some cases where
you may want to put your apps in different Firebase projects.
One implication of registering all your platform variants
in one Firebase project is that the analytics for all the apps
will live in the same place.
You can configure the access level of each person
on the team in the Firebase project settings,
and this permission would take effect
for all apps registered in that project.
So if a developer has permission to look at the Analytics data
for iOS, they will also have permission
to look at the Analytics data for the Android platform,
and so on.
If you require more isolation than this,
you will need to register the platform variants
in different Firebase projects.
But by doing that, you lose the advantage
we mentioned earlier of sharing the same user
base, analytics data, storage, extensions, and so on.
That's why the Firebase team highly
discourages registering your platform variants
in different Firebase projects.
But if you really need to isolate your platform variants
and still need users to be able to sign into all your apps,
even when they live in different projects,
you need to implement custom authentication, which
requires you to start minting your own tokens
and exchanging them with Firebase.
If you would like to understand how custom authentication
works, you can find the link to the documentation
in the description.
Another case where you want to put your apps
in different projects is if you are
developing the same app for different companies,
allowing them to customize the app's branding,
a concept known as private labeling, or white label.
In these cases, despite this app sharing most of a common code
base, you should create a different Firebase
project for each company.
For example, say you have an app for bakeries
to sell their donuts.
When a new bakery comes to you, they
want a version of the app all to themselves,
with their own brand and possibly custom configurations.
Because the users' data and analytics
will be different between all the different bakeries,
you should create different Firebase projects
for each bakery.
A good rule of thumb is one project per logo.
If the app has a different logo, you probably
want a different Firebase project.
These are the points you should consider
when deciding between placing apps in the same project
or in different projects.
However, if your apps are entirely
different from each other, you should definitely
put them in separate projects.
This way, you isolate your data and users
for each app, which is very important for privacy.
For example, let's say you're making a chat app that
stores users' private chat data in a Firestore document,
but you also decide to make a game which has nothing
to do with the chat app.
If you register this game as an app within the same Firebase
project as the chat app, you run the risk
of making a mistake in your security rules
and exposing private chat messages
to someone playing the game.
If I were a user, I wouldn't feel great about that.
Besides all that we have discussed so far,
it's important to know when to put apps in separate projects
so that you don't risk reaching the quota limits that Firebase
projects have, thus avoiding having to think about
a migration to a one-project-per-app structure
later.
Now, you may be wondering, but what are the benefits
that I will get by following these guidelines?
First of all, since all the apps in your Firebase project
use the same resources, you can configure most of the Firebase
products that you want to use in your applications
just once, which can save you a lot of time.
A great example of these are security rules configurations.
Security rules allow you to control who
can access your stored data.
So when you publish new security rules,
they will apply to all requests from all the apps registered
in the project at the same time, as opposed
to having to update the security rules for each different app
individually.
It's also easier and faster to monitor
what happens in your app's development cycle,
as you have access to all products in one place.
This makes it more convenient to visualize
analytics data between different app platforms
and create and compare different user segments.
In addition to all these benefits for developers,
you can see advantages for end users as well.
By using the same project for apps on different platforms,
it becomes easier to provide a great and seamless app
experience for your users.
For example, let's imagine that users
want to use your app on more than one platform-- let's
say on the web and on a mobile phone.
It's important that they can access the same resources
that they had access to before, regardless of the platform.
If the user signs into your application via Firebase
authentication and your app stores their data
into Firestore documents, you want the user
to be able to sign in using the same user account
and to view their data on any platform and any device.
Using the same Firebase project for both your mobile app
and web app makes enabling this experience easy.
Another example of benefits for users
is when you have a paid version and a free version
of the same app.
If users who are using the free version
want to upgrade to the paid version,
they can still access all their data,
because both versions of the app are in the same Firebase
project.
Now that we understand the project and apps concepts,
and know that some products will have limitations,
let's talk about billing.
At the moment, Firebase has two different billing plans.
From the moment you create your Firebase project,
you can start using the majority of our products
right away using the Spark plan, which provides access
to most products at no cost, including
generous no-cost limits for certain products
that have them.
But once you reach a product usage limit,
your project's usage of that specific product
will be shut off for the remainder of the month.
You need to wait until the next billing cycle
to use that product again or upgrade to the Blaze pricing
plan.
But again, for many products, such as analytics, A/B testing,
Crashlytics, and Cloud Messaging,
you get access to all of the features
in those products at no cost, even if your app
has several million users.
Our recommendation is to use the Spark plan
for early development and prototyping phases,
and adopt Blaze as soon as you know the project will
go to production.
On the Blaze plan, you only pay for what your project actually
uses.
And the plan still includes the generous no-cost limits
from the Spark plan, meaning that you only pay for any usage
beyond those limits.
To change plans, just click on the gear icon
next to your project name and open the Usage and Billing
section.
There, you will be able to check all the details of each
of the plans and your payment method,
and change the plans as necessary.
Also, since Firebase projects are also Google Cloud projects,
they can be attached to any Cloud Billing accounts
you've already set up in the Google Cloud Console.
Oh, and don't forget--
when your Firebase project is on the Blaze plan,
don't forget to set up budget alerts.
You can set up a budget alert in the Firebase Console
opening the same Usage and Billing section.
And you can learn even more about avoiding surprise bills
in the links in the description below.
So let's recap the best practices.
First, register your apps in the same Firebase project
if they represent the same application
but just for different platforms,
or if they need to share data, users, and analytics.
Doing so has the added benefit of making
any other integrations you've configured
in your Firebase project available to each of your apps
at once, as well as making it easy to create
seamless experiences for your users across platforms.
Second, we highly discourage putting your apps
into different projects when they are from the same business
use case.
But if you really need to, you should be careful,
because you may need to start using custom authentication.
And last but not least, always remember the one Firebase
project per logo rule when building
apps for different companies.
In the next videos of this series,
we will talk about how to use Firebase
for different environments, such as development, testing,
staging, and production.
We will also cover how you can use emulators
in some of these environments.
So if you're interested in these topics
and in learning more about Firebase
and the products available, subscribe
to our channel and check out the many amazing videos
that we have.
[MUSIC PLAYING]