I created and initialized a Firebase the project on my machine and Firebase console. However during the CLI initialization process on my machine I did not tick/include Firebase-Functions feature during the feature selection process.
Halfway through the project I realized there where some features on my website that needed cloud functions and now I'm stuck trying to add firebase functions to the project.
Enabling Firebase functions on Firebase console is easy enough but it's making neccessary changes in the source code to enable it that are frustrating (e.g Creating a 'functions' folder in the code, creating a package.json etc). Is there a command to automatically generate this?
You should just be able to run firebase init in the same project again to add Cloud Functions. It will add extra information to your firebase.json for the new products you choose, but will not overwrite what you've already done for Hosting. If you don't trust that process, simply back up your files, run the comment, and revert the changes if you don't like them.
Related
I'm building a simple website using Node.js and Express.js with a typical root-level package.json to handle my dependencies.
Now, I'm learning to use Google Firebase for web hosting and functions to deploy the website. Upon executing the Firebase CLI command firebase init functions, I now have a functions directory that also has a package.json file. I transferred my initial /app.js file into the functions/index.js and it's working fine when I firebase serve for testing.
Here is my project directory structure:
functions
└─views
└─index.js
└─package.json <- contains firebase-admin and firebase-functions dependencies
public
└─images
├─styles
└─scripts
firebase.json
package.json <- contains express, handlebars, etc. dependencies I had originally created.
Is it good practice to now have 2 package.json files for this project? One for Firebase functions, and the other for my app? Should I consolidate them into one, and if so, which one?
I'm still new to back end development, so any advice would be deeply appreciated!
You have to see your functions as your backend server. In the end if you host your web app and call your functions via http requests your functions act as independent "components" even then they are in the same place in your local project. That's why they need their own package.json.
To help rookies like me, yes you should have two package.json files.
One for your front end. One for your Firebase Functions 'backend'
To install packages on the functions package.json, in the terminal navigate to the functions folder.
I am trying to find an easy way to roll back to a/the previous version of my firebase function(google cloud function), in case the new release of this firebase function creates a problem to the deployed system.
The way I deploy the functions is via firebase cli (firebase deploy --only functions) and not gcloud cli.
Is there an easy way to roll back to the previous version of the function?
There is currently no rollback feature. You will have to deploy the function again using the source code that you want to have in its place. To make this easier on themselves, developers typically tag their code in source control after a deploy, so that it's easy to check out a specific version of the code to roll back later.
I am struggling to find the way to have 2 Azure functions in different language(C# and node.js) in Azure functions Project vs 2017.
Is there a way to do that?
Thanks!
Update
This method is invalid for v2 function(runtime ~2) because now it's required to use single language in one function app. See announcement.
So, the 2 project doesn't replace the functions created by first project?
Do you mean that you found some functions are replaced after new project being deployed to Azure?
Normally they won't be replaced unless functions in new project has same function names as ones already deployed.
create Azure Functions in 2 different language(C#, node.js) under one VS project
#Mikhail is right, VS doesn't provide ways for using js Azure function. No template and debug support for now.
But if you just want to run and deploy them together using VS, with no need to debug nodejs function, there's a workaround.
Generally speaking, you have to manually add nodejs function folder structure to VS project as below.
A folder named after your js function includes function.json and xxx.js file. If you have some packages installed by npm, also add package.json and node_modules folder.
function.json, xxx.js and package.json should be set as Copy if newer, so that they can be included in output dir like c# complied dll.
Not need to include node_modules locally, function host will locate them automatically. While after deploying to azure, you need to visit kudu(https://{functionappname}.scm.azurewebsites.net/DebugConsole). Execute npm install in console under wwwroot folder to install packages in package.json.
And some function templates if needed.
I have an Angular4 web app, deployed on Azure. Now I want to deploy this app to other environments on Azure: one for testing, one for acceptance and one for production. Every environment has different API endpoints and may have other variables, like Application Insights. All those environments run Angular in production mode.
The way Angular advises you to do this, is by the Enviroment files (environment.test.ts, enviroment.acc.ts, environment.prod.ts). I could configure all the different API endpoints in those files, and run my build with --prod for production for example.
But that is not the way I want to do this. I want to use the exact same application package deployed to test for my acceptance environment, without rebuilding the project. In Visual Studio Online, this is also really simple to configure.
The point is: how can I make my API endpoints differ per environment in that way?
The way I want to do this, is by the App Settings in Azure. But Angular can't get to those environment variables because it's running on the client side. Node.js is running on serverside and could get those App Settings - but if that's the way I need to do it, how do I make Node.js (used in Angular4 CLI) to send those server variables to the client side? And what about performance impact for this solution?
How did you fix this problem for your Angular4 apps on Azure? Is it just impossible to fix this problem with the Azure App Settings?
For everyone with the same question: I didn't fix this problem the way I described above.
At the end, I did it the way Angular wants you to do it: so rebuild for dev, rebuild for acc and rebuild for prod.
In Visual Studio Online, at build time, it builds and tests our code and it saves the uncompiled/unminified code. At release time, it builds en tests it again and releases it to the right environment with the right environment variables (--prod for example).
I don't think there is another way to fix this.
The solution is pretty old school but it works! Although you can use branching or tag for this purpose instead of cloning the code to the package.
The best solution as you said is Azure app settings will be saved as environment variable so you should implement an API with node.js and share the variables you want.
Of course there is an impact because of additional http call, but it's just one time at application start which is about max 5ms and depends on each program policy whether is impact or not.
Another option could be move the variables to the JSON file in the asset folder, and change it at deploy runtime with release pipeline. that's easier implementation but the disadvantage is you will have to use release variables instead of app settings and if you have config changes you will have to update the variable value first and redeploy it, although that works most of the times but sometimes you want to change just like a connection string and you will have to redeploy.
I'm still new to web development and I'm using Firebase to handle all my data right now.
I have everything up and running, but how do I make it so my Firebase website updates whenever I make a change to my files? Do I have to manually call firebase deploy after each change in order to see the updated site?
To deploy your changes to the Firebase Hosting server, you will indeed have to run firebase deploy.
But normally when I develop an application, I run a local web server for the most part. I then only push the changes to Firebase Hosting when I have finished the feature/bugfix that I'm working on.
For local execution, I either use http-server or a gulp script that also packs the files. The latter have the advantage that they can watch your local files for changes and execute the correct steps based on that.
I'm working on a Angular 4 app with Firebase as a backend, so the steps are
$ ng build --prod
$ firebase deploy
It really depends on what you are doing and what you're trying to deploy.
There's three different areas to deploy to:
Hosting - this is just a simple web server in which to house your HTML, JavaScript and any other static files
Database - your Firebase access rules are placed in here
Storage - access rules to the file store, typically user submitted files
Typically you'll be developing your HTML and JavaScript files locally and testing them there. When you're ready to deploy to the hosting environment you'll typically deploy via firebase deploy, this will deploy all of the local files and rules to the Firebase servers.
If your question relates to just the database rules then there is no local version or instance of this, you need to deploy changes as you make them in order to make them active.
You can perform a rules update by issuing the command firebase deploy --only database. Just make sure you have a firebase.json file with "database": { "rules": "firebase.rules.json" }, or similar defined in it.
Bonus: Use BOLT to build the rules, it transpiles into a Firebase JSON rules file but makes development so much easier especially when your rules inevitably become more complicated.