I have a project with 2 schemes, one for development and other for production. I am also using firebase, hence I created 2 projects and injected two google plists under different names in the project. I also need to access google cloud platform. I cannot change/modify cloud functions without affecting my production application. Is there a way where I can have two Firestore for single project so that editing/ changing functions in on won't affect other?
It's not possible to have multiple Firestore instances per project.
It's not entirely clear to me what the problem is with your use of Cloud Functions, but the functions running in each projects should automatically use the Firestore instance for the project that they've been deployed to. If you need to access a different Firestore instance, then you will need to deploy some configuration for your functions so they can initialize an instance of the Cloud SDK that you're using to read and write Firestore
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
For example, if I wanted to use the functions.auth.user().onUserCreate() trigger, is there any way to make it trigger different functions for different apps that are all in the same Firebase project? Is the only way to fix this to create separate Firebase projects for each app? The issue with that is that I need them to access the same database.
It's not possible to know in a Cloud Functions trigger which app a user used when they created their account. Firebase Auth accounts don't have a sense of "ownership" with respect to multiple apps per project. All apps in a project share the same users with the same permissions.
What you can do instead is have each app write something unique in your database after the account was created, then use that to determine what that user should do later on. Either that, or use different projects if your apps don't actually need to share the same set of users.
The only possibility that I think that might help you is organizing your Cloud Functions in different files, which will be then loaded per project. So, for example, in your Project Alpha, it will run the Cloud Functions from the foo.js file, while in the Project Beta, it will run the functions from the bar.js and the same logic for other projects and Cloud Functions.
This way, even though all users are sharing the same database, it will trigger the function based in the file that you requiring in your application. You can check for tips in organizing your Cloud Functions in multiple files and calling them individually, in this official documentation here:
Organize Functions
I believe this way might work for you, so, I would recommend you to check the documentation and give it a try splitting the functions in multiple files and calling each specific files, on their specific applications only.
Let me know if the information helped you!
We are having different environments for one of our solution (test, preprod, prod). We've created different Firebase databases as part of single project on Firebase console. We want to have access control implemented to these databases depending on users or groups e.g. prod Firebase database will be accessible to only few users where as other environment's (test and preprod) Firebase database will be accessible to most of the users.
Are we implementing it correctly? If yes, would it be possible to configure Firebase project to have this kind of setup.
This is not the recommended way to implement different development environments. The only recommended way to separate environments is to create different Firebase projects for each one. This ensures that they each have completely isolated data, users, security rules, and so on. Adding multiple databases to the same project isn't true isolation, and could lead to problems later on.
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.
This is in relation to the question here: Google Cloud / Firebase Functions, handling dependencies per function
So, to manage dependencies better, is it allowed to divide the functions to as many projects as we see fit?
This would create one "master" project, that contains the data in database and storage + the projects that are otherwise empty, but contain only certain functions.
Thins of the following projects: My Awesome App, My Awesome App Stats Api, My Awesome App Admin Api etc.
It depends on what kinds of functions you're writing.
If you want to write database triggers, they have to be in the same project as the database that's receiving the writes. You can't have a second project respond to writes from the database in the first project.
If you want to write HTTP triggers, you can init the admin SDK to point to different projects for querying and such.
I don't particularly see any need to "shard" your functions like this in a production environment. Cloud Functions will scale your functions as needed to handle the load, and having different functions in different projects shouldn't make a difference in that respect.