I'm building a web app using React with a Firebase backend.
I want to be able to deploy my app on different environments (staging, prod). To do this, I have added my app to 2 different Firebase projects, one for each environment.
What I want to be able to do is to deploy slightly different cloud functions depending on which environment I am deploying to. I want to automate all this for CI/CD.
Is there a way to specify different functions/ folders for each Firebase project, or is my only option to have a script that moves the correct cloud functions code to the functions/ folder on deploy? Similarly, how can I have different Firestore rules for each environment?
Thanks for the help.
Your option, as clarified in the official documentation here, is to add the following lines into your firebase.json file to specify different paths.
"functions": {
"source": "another-folder"
}
Since the firebase.json is individual for each project, with this lines, you should be able to set a different folder for each one of them, so they reference different files for your functions.
Regarding Firestore rules, due to the fact that they are in separate projects, you can access the Firestore Console and configure the security rules there. Each project will have their only set of rules for you to configure. You can get more information on how to structure them in this article here.
Let me know if the information helped you!
Related
I'm trying to get a React app running in Azure App Services and having difficulties getting environmental variables to work.
Locally
When running locally I'm using a .env.local file to load environmental variables (which isn't checked into git).
REACT_APP_SERVER_URL=http://localhost:5000
I can then use it in my application by referencing it using process.env.REACT_APP_SERVER_URL. Everything is working as expected.
On Azure
Now I'm trying to get the same thing working in Azure. I've setup configuration using Application Settings (described in their documentation here and here).
I can use kudu to get to the debug console and see that the environmental variable is being set.
But using process.env.REACT_APP_SERVER_URL is not pulling in that value. If I console.log(process.env) my url isn't doesn't show up.
My React app was created using the create-react-app cli a couple days of ago. My React App is deployed via github actions with the following startup command: (pm2 serve /home/site/wwwroot/build --no-daemon --spa)
From what I've read online it "should" just work, so I'm not sure what the breakdown is. My thought is something with pm2 might be blocking environmental variables, but not sure.
This guy seems to be having a similar problem to me, but no answer is elaborated on that question. And I don't want to store config in package.json, since that's what Azure Config is suppose to help me do.
A react single page app is, from an infrastructure perspective, just a bunch of static files - HTML,JS,CSS, whatever. It cannot reach into the server to read those variables because there is no server side code running.
You're going to have to bundle your environment variables, whether inside .env or package.json or wherever.
This is the first time i'm working with firebase. My goal is to have a bounch of client apps (more and more over time), all of them managed by an admin app (One app to rule them all).
The thing is that the client apps have a certain content that needs to be updated from the admin app. My best approach is to create a firebase project, put the admin app there and adding client apps over time. I'have read that is possible to have an unlimited number of apps inside one Firebase project. On addition, someone told me to create one project for each client app and connect them to the same database somehow. I simply don't know what to do.
Which would be the best solution for my problem? thank you
firebaser here
A Firebase project can currently contain up to 30 app definitions. This is meant to support variations of the same logical application. For example, having an Admin app in addition to the app for regular users, and/or having an iOS, Android, and Web version of the same app, and for example having a free and a pro version of the app (if that is allowed by the stores where you deliver them).
Adding multiple apps to a project is expressly not meant to be used for white labeling apps, where you ship essentially the same app with different branding to different user segments, as you'd be sharing the backend services between them. For some backend services (such as database and storage) this is not necessarily a problem, as you can isolate the customers with security rules. But for other services (such as authentication and analytics) this is not possible, which is why this use-case is not supported.
If you need to define a separate app in the project for each customer, the only supported approach is to create a separate project for each customer.
I'have read that is possible to have an unlimited number of apps inside one Firebase project.
In that case please provide a link, so we can either fix it, or (if it's not in the Firebase documentation) leave a comment to clarify.
I deploy my Docker image to default GAE by gcloud app deploy --image-url=us.gcr.io
I have successfully mapped my custom domain to this application with custom runtime and flex env.
My dispatch.yaml sends requests to its sub-domain:
dispatch:
- url: "dev.domain.com/*"
service: default
Now I want to use different images from Container Registry for test.domain.com and domain.com
While having all these images sharing same Cloud Storage and Firebase credentials.
Being new to GCP I wanted to learn any simple approach to organize such basic structure without going into services and versions (just by assigning proper images to serve relevant domains).
Is it even possible to do within one GAE project or I should create separate projects for it?
Mapping custom domains can only be done at the service level, so if you don't want to go into services separate projects is your only choice.
Actually using separate projects instead of services (or service versions) for implementing different environments has some advantages, I'd choose separate projects, too. See Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
I'm not sure if sharing the storage and credentials between production and other environments is a good idea (what if something goes wrong?). I'd keep them separate, too (maybe with some jobs to populate non-production projects with production data, if you need to). But if you do want to share them across projects you'll probably need to make some extra steps.
I've been looking at how to create multiple Firestore instances in Firebase, I need different Db's for prod, staging and development. I read the documentation and seems that I only need to modify the "Google-services.json" file in the applications. what I don't get is what should I modify and how that would look in the console.
Am I going to see different instances in the same project?
I need to create different projects for every environment and modify those values in the file?
If I need to test something that requires testing in all environments and all of them require Blaze to run that test do I have
to pay Triple?
Thanks in advance
Firebase doesn't support the use of multiple Firestore instances in a single project.
The Firebase team strongly recommends creating different projects for each of your environments to keep them separate. This probably means you will have to build different apps that each point to different instances, or you will have to somehow configure your app at runtime to select which project you want to work with.
There is no obligation to add billing to any of the projects you don't want to pay for, as long as you accept the limitations of the Spark plan.
Yes Firebase doesn't support multiple instance in a single project. However my case, i created 3 different document in Firestore root and setup each environment to refer these documents accordingly. Each document will have the same collections, sub collections and documents.
For example,
dev -> users -> details
-> others_collection -> details
stag -> users
-> others_collection -> details
prod -> users
-> others_collection -> details
On the client side, each environment will get the collection like this :
db.collection(`${env}/users`)
I am doing this on small project and seem pretty happy with what Firestore provided. In single project. i can create many ios/android apps according to the environment and each environment have it own document and collections in Firestore.
The safest way is to create a new google cloud project. You can export your current firestore database to your new project if needed.
Step by step:
Backup your current database by exporting all your documents into a
bucket:
https://firebase.google.com/docs/firestore/manage-data/export-import
gcloud beta firestore export gs://[BUCKET_NAME]
Create a new project -> https://cloud.google.com/resource-manager/docs/creating-managing-projects
In the dashboard, select Firestore into your new project and create an empty database
In the dashboard, go to your BACKUP_BUCKET and add your new project service account in the permission tab
Switch project to your new project
gcloud config set project 'new-project'
Then export your data
gcloud beta firestore import gs://[BUCKET_NAME]/[EXPORT_PREFIX]/ The EXPORT_PREFIX being the name of the folder created in your bucket.
I use this method to have clearly separated 'preprod' and 'production' environments (the team can access and synchronize with production without having access to the production environment codebase and configuration).
I'm new to web application and Google app engine. I don't understand the relationship between projects and the application. I know that there is one unique application ID, but under the application, there can be a lot of projects.
Now I want to run those projects individually under one application using different folders in URL, like this: http://udacity-cs253.appspot.com/unit2/rot13. It's using different URLs for projects but I don't know how to do that.
I read google's help pages but they didn't help. So can anyone help me with this?
Thank you~
An application consists of all of the code deployed to App Engine under a single application ID (appid). For a single appid you have shared:
datastore contents
cron jobs
task queues
logs
project administrators and permissions
billing settings and quotas
If you'd like to arrange the code within a single application into logical projects, and are comfortable with sharing the above amongst the projects contained in the same appid, you can feel free to do so.
However, if you'd like to segregate the projects (for instance, if you don't want developers of project A to be able to configure project B), you should create individual appids for each project and manage them separately.
As far as routing of requests to individual projects, aschmid00's answer provides a useful suggestion on how to do this.
lets suppose your app is written in python.
you do that in your app.yaml file
if you have 2 applications (unit1 and unit2) in your app folder both do have a main.py and in there you define your WSGI application
in your app.yaml you do like this:
- url: /unit1/.*
script: unit1.main.application
- url: /unit2/.*
script: unit2.main.application
all requests with path /unit1/.* will be served by unit1, the /unit2/.* by unit2.
the datastore will be shared