I'm new to Sails.js and are now working through some tutorials.
I have now created my Sails application and added a User model and controller. The application runs when executing sails lift. I am able the view the users and create more.
I cannot find the below referenced file that is supposed to contain basic application settings such as application name, port, environment and log level.
config/application.js
Am I missing something or did I create the application wrong?
port and loglevel should be set in config/env/[production|development]
I think the name of the application is taken from the package.json if I'm not mistaken.
Sails have improved this setup. Now you should have an env folder under config with an environment config file. For example development.js
module.exports = {
port: 1337
};
This will set the port for that environment. This environment is either set as the environment variable 'NODE_ENV' or you can specify this in your local.js file. Like so.
environment: development'
Note any variables set here can be accessed by using
sails.config.variable
So you can set up your own appname variable and access it like that.
Related
According to the nextjs documentation, if I want to expose my environment variables to the browser I can just prefix them with NEXT_PUBLIC in my .env.local file, like so:
NEXT_PUBLIC_VAR=7
However, it looks like I can also expose my environment variables to the browser by using next.config.js, like so:
module.exports = {
env: {
PUBLIC_VAR: process.env.PUBLIC_VAR,
},
}
And this will add to the javascript bundle
What is the difference between these two strategies?
NEXT_PUBLIC is a new feature added. Before, in order to set up environment variables, we had to set up both server and client, separately.
Environment variables that are placed in the .env file would be available only on the server-side, if you want to make your env variables available on the client-side you had to use next.config.js. We follow the separation of concerns principle here.
But setting env variables for the browser in the next.config was too much unnecessary typing. This was an example in next.config.js for the client side env:
module.exports = {
env: {
AUTH0_NAMESPACE: process.env.AUTH0_NAMESPACE,
BASE_URL: process.env.BASE_URL
}
}
With NEXT_PUBLIC, env variables will be available both client-side and server-side. env variables that are set with NEXT_PUBLIC will be exposed to the browser. So make sure that you do not expose sensitive data to the browser.
So in summary, adding the prefix NEXT_PUBLIC to your environment variables will have the same effect of exposing to the browser your environment variables as exposing them through next.config.js.
try this:
place this to .env or env.development file. NOT to next.config.js
MY_VAR=10
then run this:
console.log("MY var",process.env.MY_VAR);
both inside client component and getServerSideProps function.
if you check the browser console, you will get undefined, but on terminal, you will see
MY var 10
The difference between to the two is the one of them uses a .env file whereas the other uses the next.config file. Since Next.js 9.4, loading environment variables with .env files are now supported.
However, to clarify one thing in your question, all environment variables within the .env file don't have to be prefixed with NEXT_PUBLIC, only the ones you want exposed to the browser, any without that prefix will only be accessible on the server.
Im building a custom logger using Winston in Sails. I would like to set a log level variable in all of my various environment configs and reference that variable in the log.js file. This seems to work in my controllers with a reference of sails.config.variableName but the same reference in log.js throws: Details:ReferenceError: sails is not defined Can someone tell me how to reference this variable from the config? Is there some sort of require statement that I can add?
I would rather not set the level with some sort of switch/conditional that references the env variable used to start up the application in the log.js (ie. process.env.myEnvironment)
The best way to handle this, even though you may not like it, would be to pass it in as an ENVIRONMENT VARIABLE to Sails at startup instead of using the env/{name}.js files. log.js loads before the full Sails object and you can't reference it. I recommend using:
process.env.{your variable name}
ex: process.env.LOG_LEVEL
Where logLevel is passed to the sails.js app at startup using:
>> LOG_LEVEL=info NODE_ENV=dev node app.js
In this scenario both LOG_LEVEL and NODE_ENV are available to you in the log.js file.
But it's not a "switch" as much as it's an environment specific setting. Externalizing environment specific entities is actually a common practice and recommended for cloud environments where you can alter the values without having to redeploy code.
When running in containers you can easily change the log level from DEBUG to INFO and cycle your containers without redeploying your code. You then switch it back the same way without any downtime.
I start to use dotenv for defining my env vars. I can easily specify my common vars for dev and prod environment in one .env file. But how to specify different vars for development and production environment.
For example I want to use DB_NAME = dev_db for development and DB_NAME = prod_db for production. How can I achieve this with dotenv?
I'm working with node.js.
Thank you in advance!
The .env file is supposed to be different on different environments, and hence should not be committed to your source control repo (for Git this would mean .gitignore).
For example, you'd have a config.env on production with this:
DB_NAME=prod_db
And on development, like this:
DB_NAME=dev_db
On both environments, the files would be named config.env and would reside in the same location so that the code will read the correct file.
In my project, the committed file is called config.env.sample that contains all the necessary values so that developers know what they need to add to the config.env in their environment:
# config.env.sample
# Sample configuration file for Project XYZ
# Name of the database
DB_NAME=dev_db
Here is more information from the FAQ:
Should I commit my .env file?
No. We strongly recommend against committing your .env file to version control. It should only include environment-specific values such as database passwords or API keys. Your production database should have a different password than your development database.
Should I have multiple .env files?
No. We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test. Your config should vary between deploys, and you should not be sharing values between environments.
var express = require('express');
var app = express();
var db_url;
if(app.get('env') == "development"){
db_url = 'mongodb://127.0.0.1:27017/localhost';
}else{
db_url = 'something else';
}
console.log(app.get('env'));
What does app.get('env') in express means? I'm seeing it still print development when I deploy my code to live server.
You need to tell it you're in production mode; see part of the Express docs.
In development, you typically set environment variables in your interactive shell, for example by using export or your .bash_profile file. But in general you shouldn’t do that on a production server; instead, use your OS’s init system (systemd or Upstart). The next section provides more details about using your init system in general, but setting NODE_ENV is so important for performance (and easy to do), that it’s highlighted here.
With Upstart, use the env keyword in your job file. For example:
# /etc/init/env.conf
env NODE_ENV=production
For more information, see the Upstart Intro, Cookbook and Best Practices.
With systemd, use the Environment directive in your unit file. For example:
# /etc/systemd/system/myservice.service
Environment=NODE_ENV=production
For more information, see Using Environment Variables In systemd Units.
If you are using StrongLoop Process Manager, you can also set the environment variable when you install StrongLoop PM as a service.
You can also set process.env.NODE_ENV in a JavaScript file if necessary.
I'm working on an app that connects to third-party APIs which require the use of an APP ID and SECRET KEY.
I am storing these values as environment variables in heroku, so that I don't need to expose them in my code.
If I deploy to heroku, it will use heroku's environment variables to resolve these API credentials.
If I'm working on it locally, I want to use my config.js module, and lookup the API credentials there. NOTE: This config.js file is included in my .gitignore so that these credentials never end up in the cloud.
The problematic code is this:
var api_secret = process.env.API_SECRET || require('../../config.js').secret;
When I run this locally, I've got no issues. Meaning, it is unable to resolve the environment variable, so instead it uses the secret from within config.js.
When I run it on heroku, it DOES throw an error telling me that module 'config.js' could not be found. This makes sense, because it was never pushed up with the rest of the repo, by virtue that it is in my .gitignore.
Because heroku is parsing through my code before it ever runs, the require('../../config.js') is problematic. It is trying to lookup a file that doesn't exist.
How can I solve the issue of using environment variables when deployed, and the config.js module when running locally?
On the Heroku dashboard for your application, you can set config variables. If you have the Heroku Toolbelt set up on your machine, you can also use:
heroku config:set API_SECRET=secret
See this article for more.
Edit: Think I may have misunderstood the question. I would suggest, if possible, using the dotenv npm package to set your config variables locally.
If not, another thing to check would be that the config.js package is in your package.json file, because Heroku will use this to build your dependencies.
If you do not want to push your config.js to heroky at all, you can just follow the following to determine whether the config file exists or not with a try catch and the file system module:
Check synchronously if file/directory exists in Node.js
In your case:
var fs = require('fs'),
api_secret,
config;
try {
// Check whether config.js exists
config = fs.lstatSync('../../config.js');
// If we reach this line then config.js exists, yay!
api_secret = process.env.API_SECRET || require('../../config.js').secret;
// or alternatively api_secret = require('../../config.js').secret;
// depending on your logic
}
catch (e) {
// else config.js does not exist
api_secret = process.env.API_SECRET
}
To run Heroku commands programmatically, you can set up a free Ruby app and make it do what you want through API calls. Use Heroku-api. See https://github.com/heroku/heroku.rb
If you want to set Heroku commands manually, you can set env variables on Heroku either with the command heroku config:set MYVAR=MYVALUE or through the Heroku dashboard (Click on your app > settings > reveal config vars > edit).