Not clear how to handle environment-specific configuration about ember-app-kit

[stefanpenner]

i think we want a config/config.js or something.

this.container.lookup('service:config')

[thomasboyt]

Ooh, this is interesting.

I actually think the correct way to do this would be some sort of custom task that bakes-in values. Would be great if those values were then added to the app.js as a module - import { API_KEY } from "env"; for now, later on maybe some kind of resolver-aware version.

I imagine the configuration looking something like:

module.exports = {
  "env": {
    "envVars": ["PUBLIC_API_KEY", "DB_URL"],
    "dest": "tmp/js/env.js",
    "wrapAMD": true
  }
}

This is a pre-coffee idea (I really need to buy a coffee maker), but it seems like the only solution for doing this in a static manner, and any non-static solution is outside the scope of EAK. The major downside is having to redeploy when you change a value.

[stefanpenner]

having a relatively flexible config:service that can load from "compiled in JS file" or dynamically may be interesting.

[mikegrassotti]

Yeah a flexible config:service could be really useful. 

AFAIK it would have to be dynamic to pick up heroku env variables? Or does heroku have capability to run some kind of post-deploy hook?

—

Sent from Mailbox for iPhone

On Mon, Sep 2, 2013 at 1:24 PM, Stefan Penner [email protected]
wrote:

having a relatively flexible config:service that can load from "compiled in JS file" or dynamically may be interesting.

Reply to this email directly or view it on GitHub:
#65 (comment)

[stefanpenner]

i would opt for "config at compile time" style configs for most scenarios. Build with a specific ENV in mind.

This touches on some "deployment" ideas I would like to exercise in the future.

[joefiorini]

We don't deploy to Heroku, but we do a "config at compile time" style for our app at Virtual Hold. The config files live under config/{env}.js and compile to app/config.js based on the environment. To determine the environment we use two grunt tasks ("config:env:development" and "config:env:build") that use grunt.config.set("env", "{env}");.

Finally, we use an initializer that loads app/config.js and registers it into Ember's container as config:main.

It feels a little complicated, but it's working well for us so far. Is anyone doing this in an easier way?

[jacobevans]

tl;dr Ideally, I'd like to see ember app kit have a capacity for:

• Default configuration values
• That are overridable by environment variables that are present on the server, versus the build machine

Here is our pain caused by not having that, currently:

At Live Nation, we do deploy to heroku, and we do make heavy use of Heroku env variables. Heroku encourages this type of behavior, and we tend to agree, since it centralizes configurations while not requiring intertwining them with version control (which makes deploys necessary for config changes).

IMO, having support for Heroku env variables would be really great. Currently, with our one (so far) app using EAK, I've had to rig up an unacceptably complicated workaround, which doesn't even suit all our needs:

1. We have a deploy script to heroku that actually fetches the config values from heroku, and exports them locally. (ew)
2. A build step that picks them up and populates them into a JSON file, which
3. is combined with a committed file of default config values, which is valuable for local dev, config across environments, etc
4. This is dynamically inserted into the source and exported so that all ember objects can access it.

So, it uses heroku configs, but still requires a deploy.

[stefanpenner]

The easiest way would be to load 1 extra file for configuration.

config.json or something, this can then be loaded nicely into a pre-minified app, and plays nicely with CDN's and caching. As that single file could be the result of a dynamic API request, but invalidates differently then the rest of your static assets.

[stefanpenner]

something else that a config solution should likely solve: #219

[stefanpenner]

we now have good defaults for config: eafa9ff

[dpashkevich]

So how should I use the configuration defined in e.g. config/environment.js inside the ember application? Do I just reference a global var like window.URLCONST.login or I should inject it somehow into the application when instantiating it?

[fsmanuel]

@dpashkevich depends on your needs. i use the globals. one example:

// config/environments/development.js
ENV.api_endpoint           = 'http://localhost:3000';

// adapters/application.js
export default DS.RESTAdapter.extend({
  defaultSerializer: '_ams',
  host: ENV.api_endpoint,
  namespace: 'v1'
});

if you need the information in an initializer you can do:

// app.js
export default Em.Application.extend({
  VERSION:                  '0.0.2',
  LOG_ACTIVE_GENERATION:    true,
  LOG_MODULE_RESOLVER:      true,
  LOG_VIEW_LOOKUPS:         true,
  LOG_TRANSITIONS:          true,
  myConfigOption:           ENV.myConfigOption,

  Resolver: Resolver['default']
});

[dpashkevich]

Ok, thanks for your comment!