[Music]
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 a
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
questions 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 as 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 the 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 added permission to all
firebase resources including user
management permissions and billing
being an editor means that you have
added permission to offer a base
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 at 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 the 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 between 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 the 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 this 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 leave in the same place
you can configure the access level of
each person on the team in the firebase
project settings and this permission
will 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 these
you will need to register the platform
variants in different firebase projects
but by doing that you lose the advantage
you 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 meeting 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 these apps
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 quarter limits
that firebase projects have thus
avoiding have 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 stereo 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
once you 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 generals 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 general's no cost
limits from the spark plan meaning that
you will 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 add
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
outlet in the firebase console open in
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]
you