For those of you working with html/javascript/css "thick clients", specifically those that work against some client-independent server API, how do you manage your deployment environment configuration?

Do you manage the configuration at build time with per-environment release builds (e.g. QA, STAGE, etc) or do you build a general release and rely on some server-side configuration? What's worked best in your experience?


My company has several different thick browser clients. All clients share some common attributes.

  • They operate against a common api server which is unaware of client-specific concerns
  • They are completely static at deployment and delivered via apache with no server-side processing. This means that each environment requires it's own release build (QA, STAGE, UAT, PROD).

We are looking at refactoring our clients to have general release builds and relying on server side processing to support the necessary client-specific configuration. This seems like the obvious choice, but I'd like to see how other people in same situation have handled it.

  • Are you saying that every environment (QA, staging, production, etc.) all operate against the same API server? Or do you at least have different API servers per environment?
    – Aaronaught
    Sep 19, 2013 at 0:42
  • Sorry for not including that detail, we have different API servers per environment.
    – Terence
    Sep 19, 2013 at 0:48

1 Answer 1


There are any number of different options, and the best one would depend on your specific (much more specific than we have so far) circumstances:

  1. Create separate per-environment configuration files as part of your build script. Then have your deployment script replace the default (usually empty) files with the correct environment.

  2. Have only one configuration, but use replacement tokens, and use a configuration management tool like ESCAPE or a release automation tool like Nolio to substitute them during deployment.

  3. Implement a Configuration API as part of the application server. The client could request the current settings during the initial load.

  4. Don't have any configuration dependencies in the client at all. Let the server handle it within the behaviour of its APIs, and make the only "setting" for the client be the base URL for the various APIs.

There might be more options but those are the obvious ones. And, like I said, which one is most appropriate for you depends on your exact situation. You haven't yet told us enough to recommend a specific one.

  • The heart of my question is wether it's best to handle client env. config at build time or afterwards. All of 4 the solutions you've included put the responsibility for managing env. configs after the release is built, so that's a pretty strong vote.
    – Terence
    Sep 19, 2013 at 15:32
  • 1
    I also want to clarify something on #4. It seems to me that setting the base URL for the API server(s) is a configuration dependency. That's actually pretty much the situation we have with some of our web clients today.
    – Terence
    Sep 19, 2013 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.