[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]
