I have 2 different Play Console accounts and each have a Stories app in them. Currently both of them are linked to same Firebase account (i.e. same database). I want to ask if this is ok or should I make a separate Firebase project for each app?
The short answer is, it depends.
If the two apps are identical or closely related (eg. an admin-only app that controls the flow of the client app), then yes, you'll want to configure both apps to use the same Firebase project so that they both have access to the same data.
Using the same Firebase project in multiple apps is pretty common, especially in the scenario outlined above as well as deploying to multiple platforms. Take, for example, an app that you have deployed on the web, iOS, as well as Android. These apps run on different platforms, but they are essentially the exact same app, with the exact same functionality. You don't want to be maintaining multiple projects containing duplicate data, so it's a good idea to connect different versions of the same app to the same Firebase project.
On the other hand, if these apps are not related at all (eg a quiz game and a social media app), then it doesn't make sense for them to be using the same Firebase project as the two apps are completely separate from one another. In this scenario, using the same project would lead to disorganized data, as well as making it potentially more difficult to secure and query as the apps have separate functions, and thus separate logic to control the flow of data.
It sounds like your use case falls into the first category. You have the same app on multiple Play Console accounts. You probably want the data to remain consistent between them, so you'd want to use a single Firebase project.
Related
I have a Flutter white labeled project, i want to use only the Firebase Auth on login module of all differents apps i'll generate, can i make it with only one Firebase Project and work with the UID response on the backend after the login completes? What's the best practice?
firebaser here
The recommended practice is to use a project only for single family of apps, with a single set of users. So an example of this would be to have the iOS, Android, and web versions of your app, and maybe an administrative back-end you have for that same app, and then maybe pro versions for all platforms too.
White labeling the same app for many customers should be done with a separate project for each of those customers. Otherwise you'll quickly run into limitations, such as the number of API keys you can create in a single project.
I've looked around for answers to my question, but most are actively trying to do what I don't want which is why I'm asking.
An app I'm developing for the company I work for has gone live, and so to further develop I need to use Firebase preview channels.
I've looked over the documentation and it states that channels use the same resources, which I find a little unclear.
Does this mean that preview channels are UI only and using an app on a preview channel will still write to the live database (Firestore) that customers are currently using?
If you're talking about Firebase Hosting preview channels, the only difference between each channel is the web content (html, css, js, images) that you deploy to it. The configurations for the other Firebase products (database, analytics, etc) don't change at all. You can see this for yourself by printing the active Firebase configuration in JavaScript - you should see the all the same values.
If you want to build against a different database before you push updates to production, you should instead use completely different Firebase projects to keep them separate. It's common for developers to keep multiple projects for multiple environments, such as development, staging, and production. This is the formal recommendation.
Bottom line: A Firebase Hosting preview channel just lets you try out different web assets against the same backend services. If you want different working environments to avoid disturbing customers in production, you should use different projects entirely.
There are multiple companies using one application. So I want to have, or know if this is the best way, to create a project for each company, all this with the Firebase API, to create everything programmatically. But I think this is too difficult to do and get that structure. The truth is that the documentation about the Rest API to create projects is not very clear and I am getting lost. One of the things that I want to structure projects like this is to know how much use is made of each project, calculate requests and use of storage. But I don't know if there are other ways to do this.
It's not possible to create a new project for Firebase using the Firebase API, what is possible is to list projects, and create/list apps within an existing project using the Firebase Management API.
For monitoring usage, you can use Cloud Monitoring to assess the usage of each individual app, per service.
I am creating a firebase project. It contains two React webapps: a client facing app and a backoffice app.
I either:
create two apps in Firebase with separate configurations, and two hosting sites
or keep a single app in Firebase and use its config in both React apps, and two hosting sites
In my understanding, the apps can access the same resources either way.
What should I do?
More precisely: what is the benefit of separating Web apps in Firebase ?
If you don't intend to configure the Firebase products within each app differently, then there is not much practical difference. You would need to visit specific use cases, then ask if separate apps help or hurt that case. The use cases where separate apps would be more helpful are likely to revolve around Analytics rather than development. Analytics and its related products use the concept of an application to generate meaningful data about that app, and also create and target audiences within those specific apps.
What is the benefit of separating Web apps in Firebase?
In your case, i.e. "a client facing app and a back-office app", you probably have different user roles:
Clients who use the client facing app (maybe with different sub-roles, e.g. authors and editors or team leader and team members, depending on the business scope of your app)
Admins or Super-users, or "back-office clerks", etc... who use the back-office app.
The classical way to handle this role-based access control strategy with Firebase is to use Custom Claims.
In addition to implementing a way to grant (or not) access rights based on roles, Custom Claims also allow you to adapt your app UI depending on the user's role or access level.
This is interesting but if your app is complex and have several screens (or menus) that have different behaviors depending on the user role it can rapidly become a nightmare to hide/show parts of the UI depending on a variable. In this case it may be better to have two separate apps (in two separate Firebase projects) that point to the same (master) Firebase project.
Having two separate apps is also very interesting if different developers/development teams works on the
two apps.
Does firebase limit the amount of firebase apps that a google account can have? I'm making an app for 2 different customers and have decided to use firebase for the db functionality.
I'm slightly concerned about the above if I were to grow my business. In the event that I manage to increase my client base, , I would hate to have multiple logins to access each client project.
When it comes to billing. Can I set up my firebase to charge my account and not be project specific? An alternative to this would be if I was to create a singular project and then have multiple different apps connect to the database. However I don't think this would be possible as there would be no way for me to know who my clients customers would be. Is there anything I'm missing when it comes to this?
There is a fixed limit to how many apps you can have in a single Firebase project. Last I checked it was around 30 or so, but that may have changed.
The important thing to realize is that Firebase projects are meant to cover variants on a single "logical" app, all with a single user-base that all access the same resources.
So if you have an iOS, Android, Unity, Flutter, and Web version of the same app, you'll want to have those in the same project so that they share the same resources. If you have a specific variant of the app for admins, you'll also want to add that to the same project; again, so that it's accessing the same backend resources.
But if you have two different apps with two different user-bases, you should create a separate project for each app.