I have developed an app (my first app) that's currently on app- and playstore. I'm using Firebase/Firestore as a back-end/database. I'm about to start to work on the next version of the app, which will require me to modify my database for testing and such. However, I currently have about 100 regular users on the app and I wouldn't want them to experience any weird data changes on their app while I'm developing.
I'm simply not sure about the way it's done when you further develop an existing app. I was thinking of creating new collections in Firestore simply for testing and hook my app with them but I don't know if that's the best way to go.
How do I work on a new version of an app without my users seeing any changes in their data?
If your data model is (very) simple you could create some specific, temporary, collections as you describe, but this is quite an error-prone approach (risk of modifying existing data, wrong or missing security rules, etc..) and is not recommended.
One standard approach is simply to create another Firebase project which is totally isolated from the production project. You will need to change the Firebase configuration in your Flutter app. If you need existing production data in your test Firebase project you could use the export/import mechanism.
Related
I published my first app using firebase and now I want to continue developing on this app. For that I dont want to test changes in the production firebase project so I thought about creating a new Firebase project for development. Is this a good practise?
If so, what do I need to change in my code from the published app? Only the google-services.json file from firebase?
And can this project use the same package name?
You may occasionally need to use the same APIs to access numerous projects, such as multiple database instances. In most circumstances, a central Firebase application object maintains all of the Firebase APIs' setup.
As part of your standard setup, this object is created. When you need to access many projects from a single application, you'll need to create a separate Firebase application object for each one. It's up to you to get these additional instances started.
As a recommendation from the last comment, here is the link on how to configure Multiple Projects using Firebase, furthermore here is a link of how to Understand Firebase Projects, that could also help with your main goal.
I found tutorials using Firebase and Flutter that could also guide you:
Multiple Firebase Projects
Multiple Build Environment
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 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.
I'm working on a product which uses Firebase as its backend. Since firebase exposes the API keys to the user so that could be a security issue. So, after doing some research I've set the database security rules along with API keys restrictions.
But, now I'm unable to use it in local development as well. I was thinking of creating another firebase project and use that as a testing environment and use the existing one as production.
Since the existing project has a lot of data and users. I want everything similar in the new firebase project as well. But I'm unable to find an efficient way to do so. Can anyone please suggest what would be the best option here? Should I create a new testing environment or is there a way to allow me to use the keys locally without it causing a security concern?
Any help would be great. Thank you for your time.
There is no specific command to replicate one project to another, but you can build the necessary functionality yourself with each product's APIs.
For porting users between projects you can use:
The Firebase CLI, which has auth:import and auth:export commands.
The Firebase Admin SDK, which has commands to list all users and import a list of users.
For transferring data between the projects, you can use the API of the relevant database to read/write the data.
I signed up for Firebase to use the new Firestore.
After trying it out I decided that, for my use cases (mostly server tools) I don't need most of the features of Firestore, that are very much focused on building user interfaces, and I find the old Datastore SDKs nicer for what I'm doing.
I know I could simply delete the project and create a new one but I have other things in that project that I would like to keep.
Can I revert to Datastore without starting a new project?
Unfortunately just as we cannot convert a project that has used Cloud Datastore to Cloud Firestore, we cannot do the reverse either. It might be possible in the future, but definitely not this year.
As noted, the renaming 2 options are:
1) Delete the project and create a new one with Cloud Datastore
2) Create a new project and talk to that projects database. Note: This won't work if you are using GAE Standard SDKs.