Simply, how should I implement switching between dev and prod on a lp4 app.
I have my datasource added and everything works fine, but it's a .json file. How can I switch to another configuration saved in a .env file that could be read through dotenv package.
I have tried creating the datasource object manually, but I get errors so most likely my approach is wrong. Any suggestion would be appreciated.
Hello from the LoopBack team 👋
LoopBack does not support dotenv out of the box.
If you want to keep your environment-specific configuration in files, then you should place your production configuration to server/datasources.production.json and then set the environment variable NODE_ENV to production. LoopBack is reading server/datasources.${NODE_ENV}.json at startup and applying any overrides from that file on top of the default configuration specified in server/datasources.json.
Having said that, we think it's better to use https://12factor.net and provide production configuration via environment variables. I guess that's what you are trying to achieve too?
Maybe you are looking for a way how to configure datasources from environment variables? LoopBack supports variable substitution in certain configuration files, datasources.json is amongst the supported ones. For example:
{
"db": {
"connector": "mysql",
"database": "${MYSQL_DB}",
"username": "${MYSQL_USER},
"password": "${MYSQL_PASSWORD}"
}
When it comes to datasources in particular, we are recommending a slightly different approach:
Connection settings used by local development are specified in server/datasources.json file using datasource configuration options like host, database, username, etc.
When running in production (staging, etc.), the connection settings should be configured via a single connection string/url. The datasource file should contain an entry to set url property to the value provided by the environment.
Under the hood, LoopBack and all connectors provide specific behavior to support this feature: the url property overrides all other settings, but is silently ignored when it's not present.
An example datasource configuration:
{
"db": {
"connector": "mysql",
"database": "demo",
"username": "demo",
"password": "L00pBack"
"url": "${MYSQL_URL}"
}
When running in production, you can set the connection string as follows:
export MYSQL_URL=mysql://prod:strong-password#localhost/realdb
Please refer to our older blog post https://strongloop.com/strongblog/managing-loopback-configurations-the-twelve-factor-way/ to learn more details.
Related
i am new to Web-Development and so it is the first time, that I try to work with different environments.
So in my WebApp which is deployed on Azure I want to use a connectionString for my local database, when I am working locally in development environment, and when I deploy it, it should use a different database with another connectionString.
I have seen that there are two files in my Asp.Net Core project. "appsettings.json" and "appsettings.Development.json". If I understand correctly, app.dev.json should override the settings in app.json if I work in Development Environment. But it doesn`t. When I am debugging the app, to realy make sure that environment is set to development, it still uses appsettings.json.
You might be correct in term of Multiple Configuration Files. appsettings.json is a default configuration file that you can declare anything which includes both Development and Production. The merging pattern will be appsettings.{Environment}.json, then all matching keys will replace all keys in appsettings.json. Remembered the name Environment should be matched with ASPNETCORE_ENVIRONMENT to be used. In you case, app.dev.json so your environment should be dev (case-sensitive) instead of Development.
For example: We have a default `appsettings.json
{
"ConfigurationString": "mongodb://localhost:27017",
"MongoOptions": {
"AllowWireUp": true,
"AutoConnect": true
}
}
Then you want to work in Development, you create appsettings.Development.json with content
{
"ConfigurationString": "mongodb://192.168.1.1:27017",
"MongoOptions": {
"AllowWireUp": false
}
}
Later when you run with Development, you will get combined file
{
"ConfigurationString": "mongodb://192.168.1.1:27017",
"MongoOptions": {
"AllowWireUp": false
}
}
Important: You will see MongoOptions.AutoConnect is false in Development because .NET Core merges two files based on first level key instead of merging nested. That means MongoOptions in appsettings.Development.json will replace entire your appsettings.json
There is a way to do that. I guess you are using Azure app service?. if so follow thease steps
Create multiple app-settings files inside your project. (dev/ staging / uat / prod)
These file names shoud be appsettings.Development.json appsettings.uat.json and appsettings.Production.json
Each file should contain its own configurations.
Then Go to your App service in azure > configuration > Application settings , add required prifix of your appsettings json file in Value filed in ASPNETCORE_ENVIRONMENT
Restart app service. it should work now
I want to test the behavior of my app by pushing it to the staging app on Heroku. There's a part that saves information to s3 that I want the app to execute when in production, but to skip over while testing it in staging. Is there a way to do this? I've been manually commenting it in and out but it'd be nice if it could automatically do it.
I'm using node and express if that helps.
You can feature base your code. Just add an environment variable and check the value of that variable on your code. If the value is true execute the code, if not, then don't. We do those things all the time on different environments when we release new features to reduce the possible impact.
Modify your .env locally to have this new variable.
Add your variable to your app.json (best practice). This will force application to have this variable before launching, hence, nobody would forget to add it.
{
"name": "my app",
"description": "My super app",
"scripts": {},
"env": {
"MY_ENV_VAR": {
"required": true
}
}
3.Check the value of the variable on your code:
if (process.env.MY_ENV_VAR === 'true') { //keep in mind these will be strings
//do your logic
}
Ensure the env var exist in your heroku dashboard application settings.
Regards
i have a simple question.
When you use node + webpack you can easily configure whatever you want.
For example i can write in config default path for my app modules.
Haw can i do it in Meteor 1.3? do they have some config file such Webpack?
Meteor applications can store configuration options like API keys or global settings. An easy way to provide this configuration is with a settings.json file in the root of your Meteor application. The key/value pairs are available only on the server, but you can provide public access to settings by using public:
settings.json
{
"privateKey": "privateValue",
"public": {
"publicKey": "publicValue"
}
}
These values are available in your app using Meteor.settings.
From the Full Meteor Docs:
Meteor.settings contains deployment-specific configuration options. You can initialize settings by passing the --settings option (which takes the name of a file containing JSON data) to meteor run or meteor deploy. When running your server directly (e.g. from a bundle), you instead specify settings by putting the JSON directly into the METEOR_SETTINGS environment variable. If the settings object contains a key named public, then Meteor.settings.public will be available on the client as well as the server. All other properties of Meteor.settings are only defined on the server. You can rely on Meteor.settings and Meteor.settings.public being defined objects (not undefined) on both client and server even if there are no settings specified. Changes to Meteor.settings.public at runtime will be picked up by new client connections.
A good write-up can also be found on TheMeteorChef's Blog
What is the difference between config.json and config.js? Do I have to utilize both? When do I need to use one or the other? (https://docs.strongloop.com/display/public/LB/Environment-specific+configuration#Environment-specificconfiguration-Example)
What is global-config.js? It is present in Loopback example app (https://github.com/strongloop/loopback-example-offline-sync/blob/master/global-config.js) but there is no any info about it in docs (https://docs.strongloop.com/dosearchsite.action?queryString=%22global-config.js%22). Why do they invent some third layer for app configuration?
How to see full config in runtime? Does it have some code like this?
console.log(app.getFullConfig())
Answering one-by-one:
The difference between config.json and config.js is config.json is used to specify server configuration like host, port etc. Whereas config.js is used to override these configuration, if required. For eg.
If you want to change port number based on country, then you can override this in config.js where you can see from which country loopback app is being access and change port number based on that.
global-config.js recides outside server/ folder. i.e it can be used by many loopback app's server/ folder. Therefore, the name - global-config.js.
LoopBack is made on top of Express. Therefore, you can use this option while starting your application.
DEBUG=express:application node .
It's useful to know that loopback can use multiple config files for
different environments. So you might have config.json for
development, and config.production.json for production, perhaps
with the production.json config turning off the API explorer.
Loopback is clever enough to look at your environment variable to
work out which one to use.
As well as this, you can use .js config files as a further override, which as you would expect allows for some actual code to be run. For
instance I have a datasources.json with my local database
connection information and a datasources.production.js file which
looks like a bit like this:
var dbhost = process.env.DB_HOST,
dbname = process.env.DB_NAME,
dbusername = dbname,
dbpassword = process.env.DB_PASSWORD;
module.exports = {
"db": {
"host": dbhost,
"port": 5432,
"database": dbname,
"username": dbusername,
"password": dbpassword,
"name": "db",
"connector": "postgresql"
}
}
As you can see I'm able to use environment variables to store db
connection details, which I wouldn't want stored in a file (because
I'm using a public github repo).
global-config.js is specific to the project which you have linked
to. It is a Universal Javascript app, so the
author is using this file to share configuration between the server
and client code. You can see how he uses it by searching the repo
for 'global-config' - it's another good example of why you might
use a .js config file though, as his config.local.js uses code to access configuration in global-config.js to override config.json, when the app is running locally.
As you can see, configuration can be dealt with in a multitude of ways depending on your requirements, so I don't think there is a way of writing out every single config value in use, without writing a custom bit of code.
I have built a small extension where I had to hard-code URLs in many places(like manifest.json, etc). But I want the domain of the URLs differ between dev & production environment. Wondering what is the right practice.
If you can know your production extension url then you can see the extension id. Suppose the extension url is https://chrome.google.com/webstore/detail/eme-call-and-event-logger/cniohcjecdcdhgmlofniddfoeokbpbpb so the var chromeruntimeid='cniohcjecdcdhgmlofniddfoeokbpbpb';
if(chrome.runtime.id==chromeruntimeid){
console.log('production');
}else{
console.log('development');
}
You can try creating a JSON file and have different key, value pairs in it in the following manner:
"development": {
"oauth-code": "xyz"
}
"production": {
"oauth-code": "xyz"
}
and then load settings.json into your main script and access the setting dynamically depending upon the environment that you've chosen in the following manner:
var settings = [code to load JSON file, depending upon the language that you choose]
console.log(settings['production'].oauth-code);
console.log(settings['development'].oauth-code);
It will help you to get custom settings depending upon the environment more easily, you can though also try using an application object in your JS file with the same properties, its almost the same manner, though it is advisable to seperate settings and main logic from each other.