Outline
What are Environment Variables?
In the process of developing web applications, we often end up with multiple environments of our application with different configurations. For example, while developing a project locally there's usually a development environment that's configured differently from the production environment, and before code hits production there may be a build or staging environment where code can get compiled or evaluated and tested which is also configured differently (so that the process of testing your application is isolated from your production data). While these configurations could be hard coded and swapped out before deployment, the use of environment variables can make it a lot easier to manage different configurations of your application (both in your codebases and in Postman). They also allow you keep sensitive information out of your codebase, so that in case someone gets unauthorized access to your codebase, they don't also get all the credentials to your application.
Here's a non-exhaustive list of example variables that can be extracted to environment variables in most applications:
- Database configuration (so your development database operations don't interfere with your production data).
- URLs referring to your own application (so you can use localhost or staging.example.com in development vs example.com in production throughout your app consistently).
- Any API keys, shared secrets, or credentials (it's also a good idea to keep these variables out of your codebase. Ideally you should have separate credentials for each environment).
- Any environment-specific configuration settings (such as enabling code minification in production, or disabling email sending on staging, etc.).
Environments in Postman are simply key-value stores, where both the key and value must be strings. Like collections in Postman, environments can also be exported and shared.
After creating an environment and setting some variables, they can be later accessed in Postman's request constructor by wrapping the key in a pair of curly braces, so {{url}} will try and read retrieve the value stored under url in your environment variables (make sure there's no spaces between your key and the curly braces).
Importing an Environment into Postman
create a json file on your local hard drive with the following contents.
{
"id": "410edddc-dbbf-5d80-9c82-759f9d13096b",
"name": "Conduit",
"values": [
{
"enabled": true,
"key": "apiUrl",
"value": "https://conduit.productionready.io/api",
"type": "text"
},
{
"enabled": true,
"key": "token",
"value": "",
"type": "text"
}
],
"timestamp": 1489786196110,
"_postman_variable_scope": "environment",
"_postman_exported_at": "2017-03-17T21:30:01.555Z",
"_postman_exported_using": "Postman/4.10.3"
}
Click on the settings icon in the top-right corner of the Postman interface next to the Environment dropdown and select Manage Environments.
Next, click on the Import button at the bottom of the Manage Environments menu, and choose the Conduit Postman environment file created in the previous step.
Once the environment is imported, the variables for that environment won't be used unless we activate it. Only one environment can be active at a time. To activate the environment, click on the dropdown in the top-right of the Postman interface, and select the Conduit environment.
With the environment imported and activated, we can now start making requests to the Conduit server!
Creating a New Environment for Development
Besides being highly portable, another feature of Postman environments is that they can be duplicated, making it easy to take an existing set of environment variables and reconfigure them for a different environment. Let's create an environment for testing Conduit locally.
Click on the Settings icon in the top right corner of Postman and select Manage Environments.
Click on the copy icon for Conduit between the Share and download buttons. This will create a copy of the existing Conduit environment.
Next, we'll need to update and reconfigure our new environment for develpment.
Rename the "Conduit copy" environment to something like "Conduit Development"
Change the apiUrl variable to http://localhost:3000/api (or wherever your local copy of Conduit is hosted) and clear out the token if it exists since the production tokens won't work locally.
We now have an environment ready for testing Conduit locally! Once the new environment is ready and activated in the dropdown, we can start making requests to a version of Conduit running locally
If you want to see how the Conduit backend was built and how to build your own, check out the Rails tutorial on how to build Conduit.