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.
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 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.
I have a CI/DC pipeline with google cloud build triggers that deploy my code to different sites depending on which branch I push to. The develop site is a live test - the final check before I merge to master, which triggers a deploy of master to the production site.
Currently, both sites use the same firebase Firestore db, and any document changed on the develop site will also be changed on the production site.
What I want to avoid is creating another firebase project to push the develop code to with a different database, because that means I need a separate set of credentials and would copy the same functions over to the new project every time I change them. That's not maintainable and is a lot of work.
What I would like is some way for the develop site to only have access to part of the firestore database, and the production site to have access to another part.
How do people do this? Is it even possible? Is there a better way? One alternative I can think of is using authentication and creating separate accounts for testing with different access permissions, but this seems a work-around and not the ideal solution.
What you're trying to do sounds like a lot more hassle than using multiple projects, which is the documented and strongly preferred solution. Putting everything in one project is a huge anti-pattern in Firebase and Google Cloud, and it will cause you more problems in the long run, in addition to increasing the risk of catastrophic failure if you manage to misconfigure something in that one project.
It's perfectly maintainable to have multiple projects like this, if you apply some scripting to automate the work. This is very common, and I strongly suggest thinking through how this would work for you.
You CI/CD pipeline could definitely check out your updates from source control and deploy them to whatever other project environments you have set up. It's very common to manage different credentials and configurations for use in CI/CD.
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.
This is intentionally a very broad question. Sorry about that.
I'm experimenting with firebase for the first time. I would like to build a little e-commerce webapp using firebase, React and Next. I would like to split the App in two different apps: one admin app (used to create products and do other admin stuff) and the actual shop app. The Apps should be hosted on two different domains but they should talk to the same cloud firestore.
What would be a good setup to implement this architecture? Currently I am thinking about creating separate firebase projects for the admin and the shop app so I can host them on different domains. The cloud firestore would live in the admin project together with all admin related cloud functions etc. The shop app (or client app) would have its own project for hosting and would be connected to the firestore from the admin project.
Does that sound like a reasonable architecture or am I completely on the wrong path. Any suggestions are appreciated. And again sorry for the broadness of the question.
You don't need to do anything special. Each app (mobile, web,whatever) connects to a firebase instance/project. You can just set them all up to use the same firebase project (.plist file etc) and it will all work. The advantage of this design is that both admin and client access the same data, which presumably you need. (If you haven't found it, on the Firebase Console -> Settings -> Project Settings; add applications which will generate the appropriate credential files for each device type.)
Since you will have a shared/common authentication space, you may find that you want to add a flag/limitation to login so that only specified users can access the admin side. There's a few ways this can be accomplished.