Using env vars enables you to separate your source code from your application configuration (or config, for short). This is good practice because config varies substantially across your app deploys, but your code generally does not.
Some benefits you reap by employing env vars are:
- You can dynamically assign env vars, depending on the different types of environments your app resides in. The needs across your environments(development, staging, production e.t.c.) greatly differ. Hence, they require unique configs. For example, your development environment may use localhost for its api, while your production uses a live api hosted on a remote server.
- Switching between one environment and another is hassle-free, by just changing the name of your environment. For instance, on your continuous integration service, your
testing, while on you hosting provider, it changes to
- Sharing your code publicly or making it open source is easily achieved, without compromising your application’s security. Sensitive credentials and resource details are safely stored away in your env vars, while your code is on a public repository.
- Scaling and configuring your application can be done automagically. Having a static config greatly limits how much your application can scale. If your config is separate from your code, changes can be made to the config, to scale the number of resources your application consumes, depending on its load.
What can you put into an environment variable?
Contents of your config/env vars may include things like:
- External API URLs that your app queries e.g. Google Maps API
- Credentials e.g. Amazon S3 secret keys and access ids
- Resources e.g. build pack url
- Deploy specific values e.g. whether to enable deletion or debug logging, the environment type
Now that we have got the basics of environment variables, we’ll learn about how to setup environment variable in AngularJS in next blog!