Why Environment Variables

[00:00 - 00:27] If you write your bank password down on a piece of paper and fold it up, you're exercising security by obscurity, which can be effective, but it's not recommended. This is the justification I used the last time I committed sensitive information to my code repository. In just two minutes of my code accidentally being public , in less than eight hours when I went to sleep, is all it took for hackers to abuse my AWS keys.

[00:28 - 01:34] What could I have done to prevent the AWS keys from being exposed? Even if I removed the keys from my code, I'd have had to wipe the entire code history to make sure it wasn't in any of the commits. But exposure can come in different forms. Even if your project is private, when you share the repo with a new contributor, such as a contractor who should not have production keys, you're exposed. Okay, let's back it up a second. What are we talking about when we say keys? How does this relate to environment variables? When building production grade projects that communicate with servers over the internet, you have to have secure ways to authorize access to these servers. This course uses environment variables to solve the problem of securely configuring instances of a running node JS server. There could be other solutions, but we're going to focus on why the industry standard is to use environment variables.

[01:35 - 02:23] Let's call them EVs for now, because environment variables is a mouthful. EVs and .n files are also used in many other programming languages, such as Python, Java, Ruby, and more. So it's not just about some small JavaScript library, but rather a pattern used by many types of professional developers. Okay, so we know we need to configure server keys. What are some other reasons to use EVs? Sometimes the URLs need to be configured. Do you have a database URL? Which back end are you pointing to? Do you have an internal server for testing or what folks call UAT?

[02:24 - 03:30] Are there specific user databases you're using for development? You need to be able to change these securely as needed. How about less secure things like turning features on and off? Should your feature only be available on beta instances? Are you turning on and off diagnostic tools for development that would otherwise hinder the user experience? EVs make it easy to manage configurations for different types of environments, whether it's a test, prod, proof of concept, or local. They're called environment variables, because they're read from the command line environment, and not from code. They can be injected into the environment at runtime, so lots of tools that build support them, especially tools for automatic deployment, also known as continuous integration tools. The support from these tools make EVs an essential skill to have for building production ready projects.

[03:31 - 03:54] Before we go into code, let's clarify what configurations are not relevant to EVs. I like to use the jargon instance-specific, but I know this is going to confuse a lot of people, so let me explain. Every time a server is run, it creates an individual instance with its own configuration.

[03:55 - 05:08] If you're using a managed server cloud like Lambda or Netlify, you probably have one configuration set that will be the same for all servers. This would be a service instance. If you start a server on your own computer for local testing, you'll use a different configuration than when you go to deploy your code onto your server in production. EV configuration is not user-specific configuration. It's not saving user preferences, it's not admin versus regular users. It's stuff that applies to all users that connect to that instance. It's until that server is shut down and the configuration changed or a new server is spun up, user data comes from data APIs and different data coming back does not change the EVs. It's not for changing an interface based on the data, like how some YouTube videos have up to 1080p and some have 10 8k. That is information that comes from the server network calls and the interface code doesn't change, although the interface does adapt to the data.

[05:09 - 06:16] It's also not for device-specific stuff, like responsive design, where if you open an app from your phone, you'll have a different experience as from your laptop because the code stays the same and the interface is as adaptive to the device. EVs are also not for changing the package.json, so they cannot affect the version of JavaScript or Node.js the project is using . Lastly, when EVs work, when are EVs not helpful? EVs probably would not be as helpful to single- person teams if you're not using Git or if you're manually deploying through file transfer protocol. If you're coding JavaScript without Node, such as for static HTML websites, when you're not using a bundler, you're not going to be even able to use EVs. Now that we've gone extensively into why EVs are useful, what types of things can be configured, and when they're not useful, let's try code example.