A result-driven software engineer with expertise in community building :) // I teach cloud technology concepts - especially cloud solutions aroud Azure and the Azure Stack.
1- There's no db credentials included in the deployed app, as this Node.js app doesn't store data. Only uses Express (from the app.js code) for rendering the files. It gets data inputs from the home.ejs file, and directly sends the data to its respective prop (overrides the prop value) in the welcome.ejs file. Hence, no data is stored in the actual sense.
Moreso, Azure App Service renders web pages using the :3000 port number, by default. And as can be seen in the package.json file, there's a process.env.PORT||5000 argument - which is an environment configuration, where PORT is the env variable for the port number (was never hardcoded). The || operator in JavaScript means OR in Layman's terms; which makes the package.json file suitable for both local and remote deployments. The 5000 port number value would only always get accessed by the 127.0.0.1 address (your localhost), UNLESS you go ahead and change the value for PORT in your App Service settings. Which brings me to the next point.
It is important to note, that, environment variables can always be set from the Configuration section (Application Settings option) of your app service Settings. You would only need to replace the values that you wish to have hidden in your code with the variable names (that hold these specific values) in your configuration settings on App Service. I destroyed the created resource group already, I could have showed a walkthrough via screenshots.
Finally,
2- Kudu doesn't issue the npm start command from the package.json* file to run the app (and there's obviously no npm start command in the **package.json file). The Kudu service uses the line below to run the Node.js app. It basically runs your issued command (value) passed to the "scripts" key in your package.json file.
{..."scripts":{"start":"node app.js",...},...}
The Kudu service has also been built to automatically look for an app.js or server.js file in your project, set it as the entry file, and use this file to run your Node.js project - if it doesn't find the script
So, npm run build is useful whenever packages require a build process. You can rebuild packages before deploying by simply running the command, locally - before pushing to production (yeah, the Kudu service, by default, deploys your app to production)
You can also find a MEAN stack sample here, which includes a deploy.sh bash file for deployments. github.com/Azure-Samples/meanjs
I'd also be happy to write a more comprehensive tutorial on this in the future, if need be. Cheers :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the kind feedback, Raedbenz.
To begin with;
1- There's no db credentials included in the deployed app, as this Node.js app doesn't store data. Only uses Express (from the app.js code) for rendering the files. It gets data inputs from the home.ejs file, and directly sends the data to its respective prop (overrides the prop value) in the welcome.ejs file. Hence, no data is stored in the actual sense.
Moreso, Azure App Service renders web pages using the :3000 port number, by default. And as can be seen in the package.json file, there's a process.env.PORT||5000 argument - which is an environment configuration, where PORT is the env variable for the port number (was never hardcoded). The || operator in JavaScript means OR in Layman's terms; which makes the package.json file suitable for both local and remote deployments. The 5000 port number value would only always get accessed by the 127.0.0.1 address (your localhost), UNLESS you go ahead and change the value for PORT in your App Service settings. Which brings me to the next point.
It is important to note, that, environment variables can always be set from the Configuration section (Application Settings option) of your app service Settings. You would only need to replace the values that you wish to have hidden in your code with the variable names (that hold these specific values) in your configuration settings on App Service. I destroyed the created resource group already, I could have showed a walkthrough via screenshots.
Finally,
2- Kudu doesn't issue the npm start command from the package.json* file to run the app (and there's obviously no npm start command in the **package.json file). The Kudu service uses the line below to run the Node.js app. It basically runs your issued command (value) passed to the "scripts" key in your package.json file.
The Kudu service has also been built to automatically look for an app.js or server.js file in your project, set it as the entry file, and use this file to run your Node.js project - if it doesn't find the script
"scripts": {"start": "<command>"}in your project. You can read more about this process here: blog.lifeishao.com/2017/03/24/cust...
A MERN/MEAN project would be built using the npm run build command, and it basically does nothing unles
`
"scripts": { ... "build": "<command>" ... }is specified in your package.json file. See here: docs.npmjs.com/misc/scripts
So, npm run build is useful whenever packages require a build process. You can rebuild packages before deploying by simply running the command, locally - before pushing to production (yeah, the Kudu service, by default, deploys your app to production)
You can also find a MEAN stack sample here, which includes a deploy.sh bash file for deployments. github.com/Azure-Samples/meanjs
I'd also be happy to write a more comprehensive tutorial on this in the future, if need be. Cheers :)