Namespace Basics

Just Getting Started?

When you see the word "namespaces", and assuming you've never used Chamber before, you may be a little confused.

Let's say you're storing your settings for your Stripe account. Doing that with Chamber is easy.

# settings/stripe.yml

stripe:
  api_key: 'my_key'

Looks great right? However Stripe has two types of keys: test keys, which allow you to use fake credit cards and live keys, which actually execute a transaction.

Inline Namespaces

If you wanted to store both of those in your settings/stripe.yml file, how would you do that? Well, you'd use namespaces. Since, in development and test mode you generally want the test key and in production you want the live key, it might look like this:

development:
  stripe:
    api_key: 'test_key'

test:
  stripe:
    api_key: 'test_key'

production:
  stripe:
    api_key: 'live_key'

Note: Namespaces in Chamber are arbitrary. So if, for example, you had a Rails app which had a staging environment, you could add a staging key with another stripe definition under it.

Why Namespaces?

Then why not just call it "environments" instead of "namespaces"? Why make it more confusing for people who are just trying to get started and learn. None of the other configuration libraries use such a term.

The reason is because, for Chamber, we don't limit you to only environments. For example, the Rails plugin, in addition to loading the namespace for the current Rails environment, will also look at the hostname of the computer it's being run on.

If there's a namespace that matches that hostname, it will load settings for that as well.

Host-Based Settings Example

Let's say for some reason, there's a QA person (their hostname is qalaptop) who always wants to hit the live Stripe API even if they're running in development. In other configuration libraries, you'd have to keep a local settings file which contains that information, and although you could do that in Chamber, you're also able to add it right alongside the rest of the Stripe settings like so:

development:
  stripe:
    api_key: 'test_key'

test:
  stripe:
    api_key: 'test_key'

production:
  stripe:
    api_key: 'live_key'

qalaptop:
  stripe:
    api_key: 'live_key'

What are the advantages of this? Well, if you stored your settings in a local file (as you would with the other configuration libraries), which no one else ever saw (since it can't be checked in), then if someone changes the live key, they would have no way of knowing that someone else on the team was also using the live key.

Using the Chamber approach, the person who changes the live key can easily scan down through the file and also replace the live key for qalaptop. Yay teamwork! ❤️

Note: Host-based namespaces in the official plugins are always applied after environment-based namespaces. So Chamber would first set stripe.api_key to test_key and then override it with the host-based value of live_key.

---

Next Step: Encryption Basics

Learn More:

• Specifying Multiple Namespaces