JavaScript
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax and Types
-
Section 3: Strings and Numbers in Depth
-
Section 4: Control Flow
-
Section 5: Functions
-
Section 6: Objects and Arrays
-
Section 7: Maps, Sets, and Symbols
-
Section 8: Asynchronous JavaScript
-
Section 9: Object-Oriented and Prototypes
-
Section 10: The DOM
-
Section 11: Browser APIs
-
Section 12: Modern JavaScript (ES2015-ES2025)
-
Section 13: Functional Programming Patterns
-
Section 14: Error Handling and Debugging
-
Section 15: Testing
-
Section 16: Accessibility for JavaScript Developers
-
Section 17: Internationalization and Localization
-
Section 18: Performance
-
Section 19: Node.js Fundamentals
-
Section 20: Regular Expressions
-
Section 21: Design Patterns in JavaScript
-
Section 22: Security Basics
-
Section 23: Data Structures and Algorithms in JavaScript
-
Section 24: Practical Projects
-
Section 25: More Advanced Async Patterns
-
Section 26: More Object and Class Practice
-
Section 27: Working with Dates and Internationalization
-
Section 28: Web Components
-
Section 29: More DOM and Browser Practice
-
Section 30: Build Tooling for Vanilla JavaScript
-
Section 31: More Practice Projects
-
Section 32: Interview and Algorithm Practice
-
Section 33: Error Objects (MDN Reference)
-
Section 34: TypedArrays and Binary Data
-
Section 35: Reflection and Metaprogramming (MDN Reference)
-
Section 36: More Global Functions (MDN Reference)
148: Environment Variables in Node
Imagine you're renting out a vacation home on Airbnb. You create a "Welcome Guide" for your guests that tells them how to use the coffee machine, where the extra towels are, and how to lock the front door. Now, imagine you have two different properties—one in the mountains and one at the beach. You don't want to write two completely different guidebooks; that's a maintenance nightmare. Instead, you leave a few blank spaces in the guide, like "The WiFi password is: ___________."
When you leave the guide at the mountain house, you scribble in the mountain WiFi password. When you leave it at the beach house, you scribble in the beach password. The guide (your code) stays exactly the same, but the specific details (your environment variables) change depending on where the guide is physically located.
In Node.js, this is exactly how we handle things like database passwords, API keys, or port numbers. You don't want to hardcode your production database password into your script, because then anyone with access to your GitHub repo has the keys to your kingdom. Instead, you tell Node: "Look at the environment you're running in and find the value for this specific key."
Tapping into process.env
Node provides a global object called process, and inside that is an object called env. This is where Node stores all the environment variables available to the current process. I've seen plenty of developers try to create their own "config.js" file, but process.env is the industry standard because it keeps secrets out of your version control.
Here is how you actually access a variable in your code:
const dbPassword = process.env.DB_PASSWORD;
const port = process.env.PORT || 3000; // A common trick: use the env var, or default to 3000
Notice that second line. I almost always provide a fallback value for things like ports. If you're running the app locally and forgot to set the variable, the app won't just crash—it'll just use 3000.
The .env Workflow and the Danger Zone
Typing variables into your terminal every time you start the app is tedious. That's why we use a package called dotenv. It allows you to create a file named .env in your project root where you can list your variables in a simple KEY=VALUE format.
Your .env file would look like this:
STRIPE_API_KEY=sk_test_4eC39HqLyjWDarjtT1zdp7dc
DB_CONNECTION_STRING=mongodb+srv://user:pass@cluster.mongodb.net/myApp
To make Node recognize these, you just add require('dotenv').config() at the very top of your entry file. From that point on, process.env.STRIPE_API_KEY will magically contain that string.
Now, here is the part where I need you to pay close attention: You must add .env to your .gitignore file. If you commit your .env file to GitHub, you have just leaked your secrets to the world. I've seen professional engineers get fired for this, and I've seen companies lose thousands of dollars to bots that scrape GitHub for AWS keys. Never, ever commit your actual environment files.
Handling Different Stages
You'll typically encounter three environments: development, staging, and production. In development, your DB_CONNECTION_STRING might point to localhost:27017. In production, it will point to a secure, managed cluster in the cloud.
The beauty of this setup is that you don't change a single line of JavaScript when you deploy. You simply change the environment variables on your hosting platform (like Heroku, Vercel, or AWS), and your code adapts automatically.
📋 Practical Task
Exercise: Securing a Stripe API Key for a Payment Simulator
You are building a payment processing simulation. You have a sensitive API key that must not be hardcoded into the source code.
- Create a file named
.envand add a variable calledSTRIPE_SECRET_KEYwith a fake value (e.g.,sk_test_12345). - Create a file named
app.js. - Install and initialize
dotenvat the top ofapp.js. - Write a function called
processPayment(amount)that logs a message to the console:"Processing payment of $[amount] using key: [your secret key]". - The function must retrieve the key using
process.env. - Add a check: if
STRIPE_SECRET_KEYis missing from the environment, the function should log"Error: API Key not configured!"instead of attempting the payment.
There are no comments for now.