Process & Environment

[00:00:00]
>> Now that we got the history and the intro out of the way, let's actually get started building our app. And like I said, it's gonna be a CLI note-taking app. So if you don't know what a CLI is, turns out you've been using one this whole time.

[00:00:12]
Any command you use in this terminal is technically a CLI. So let's actually dive into that. In order to understand what a CLI is, we need to talk about a few things, the process and the environment. I've been talking about something called a runtime, which Node.js is. And I've been talking about the different things you get, JavaScript and Node.js has access to different globals and things than the JavaScript and the browser.

[00:00:42]
And some of those things, it's because of the environment in which it's running in. So Node.js is running in your operating system environment, whereas JavaScript is running in a browser environment. So your operating system environment provides all different types of things. One of the most powerful ones is something called process.

[00:01:01]
So you get access to this process global, which if you just go log it, I mean, you could just look at it. I'll let it speak, actually, do I wanna log this? Okay, I'm not gonna log my cuz I got some sensitive stuff in there, so I'm not gonna log it.

[00:01:14]
But if you wrote a log process, you would see a bunch of different methods, information and data related to the operating system that your code is running on. It might know the name of your computer. It might show different other programs that are running. It'll show you all different types of information.

[00:01:35]
This is how you can access and make your Node.js program dynamic, depending on which environment it's running on, because Node.js applications are meant to be deployed to another computer somewhere. So you need to find some way to make sure your application can work on different types of computers and take advantage of different types of resources and keeping it dynamic.

[00:01:55]
Whereas when you make a web app that's meant for the browser, you don't really have to think about that other than different versions of a browser, which I don't think we think about today anyway. That's so 2015. We don't think about browser versions anymore. So yeah, process is a big one.

[00:02:12]
We'll be using that today. One of the biggest properties on the process object is something called argv. And this basically allows you to get pretty much everything that comes after node. So the best way I can describe it is like this. So I'm going to log(process.argv), like that.

[00:02:38]
It's gonna be an array. And then what I'm gonna do is I'm gonna go run that file, index.js, but I'm gonna put some other stuff after this file. So I'll just say thing and then thing2 and then I'll say this number here. I'm just gonna run that. And you see I get back this array.

[00:02:56]
The first two is always gonna be the environment, the process itself. So the first thing in the array is always gonna be the path in which the instance of node that I used to execute this file, it's always gonna point to that. The second one is always gonna point to the file that this node executed.

[00:03:13]
And then everything after that is just gonna be in order of the other things that you passed. So you can think of this as like passing arguments to a program in your terminal. That's basically what this is. It's passing arguments, right? So, yeah, and if we think about building a CLI, this is very useful cuz we want our CLI to be dynamic and take in different arguments and do different things when those different arguments come.

[00:03:40]
So that's basically how you would do it using the argv one, very powerful. There's other things on there as well. But that's probably one of the biggest ones. And then also, of course, can't forget process.env, which is going to be your environment variables. If you've ever deployed anything, anywhere, you've probably used environment variables, right?

[00:04:00]
You're talking like, I have an app that uses this API key or these secrets or something like that, that I cannot check into GitHub. So how do you get those in your environment? Well, you need to create an environment variable and then inject it into your platform, whether it's AWS, Vercel, wherever you're deploying stuff.

[00:04:16]
Because you don't want that hard coded into your code so people can steal it. So you inject it into your environment and then you can read it from your environment by doing process.env.whatever the name of that environment is. So this is where you can store secrets and stuff like that and get access to it.

[00:04:33]
Every operating system language in the world has this. In fact, pretty much everything we're covering, there's something very similar to every other language that runs on your computer, cuz they all are trying to accomplish the same goal, so they have very similar things. So it would be really hard to, actually, it would be impossible to deploy a safe app on a remote machine without environment variables.

[00:04:59]
You just couldn't do it, not safely at least. So every language needs to has this. Does that make sense? All right, so this common one right here is Node environment. This is something that we use in the community to basically switch the mode of our app. We can put it in production.

[00:05:17]
We can put it in development. We can put it in testing. And then somewhere in our code, it's checking to see what mode we're in. And it might change certain things. For instance, if I'm in development mode, I might say, turn on logging, so all my logging works.

[00:05:31]
But when I'm in production, I might turn those off or vice versa, however you wanna do that. If I'm in development mode, maybe I'll turn off authentication. I wanna bypass authentication so I can just test things out. But in production, I wanna turn it on. So I can use that environment variable as a flag to switch things on or off.

[00:05:49]
Big one is analytics. If we have tons of tracking going on in our servers, every interaction that someone's doing, I don't want that running during development mode, so I'll turn that off, if NODE_ENV equals development or testing, but in production I'll turn that on. So it's just a way to toggle things almost feature flag.

[00:06:08]
It's also a way to turn on performance. So React for instance uses NODE_ENV to, you ever did something in React, and it'll give you a warning or something like that? Whereas if you turn it on in production, it'll probably give you an error. It'll change its behavior on how it reports warnings and errors, depending on what the node environment is.

[00:06:27]
And then it and optimizes itself too to perform better if NODE_ENV is set to production. Whereas in development, it kinda ignores those optimizations so it can be faster during a hot reload. And it doesn't care about optimizing for rendering speed and things like that, yes.
>> Is there something like process.argc in Node?

[00:06:53]
>> Process.rc?
>> Argc.
>> Argc, I've never heard of argc? I mean, we can log it to see if it's there. I'd be curious, but I don't think so. And if it is, I don't know what it is. No, there's nothing called argc.
>> Used for counting arguments.

[00:07:12]
>> Yeah.
>> Something like that.
>> Yeah.
>> And then one other question here.
>> Yep.
>> What is the best practice for sharing .env files?
>> You hop on the phone with somebody [LAUGH] no. There's a lot of ways to do, I mean, there really isn't one way.

[00:07:32]
There's apps that you can store all your environment variables in. And then they'll give you one environment variable and a script that will take that environment variable, go to their API and pull down all your other environment variables and inject them for you. So as a team you'll need to know one of them and not all of them.

[00:07:47]
Some people put them in password managers. So put them in LastPass, or OnePass or something that's encrypted with a vault. And they'll do that. Other people might just pass around their .env files on Slack or whatever because it's just local things. There really isn't, I mean, that's a billion-dollar problem, right?

[00:08:07]
If someone gets access to your environment variables, they get access to your whole system. Some of the biggest hacks in the world with some of the bigger systems out there is because someone got a hold of their environment variables. So that's a really hard problem to solve. So I don't know if you can solve that problem cheaply.

[00:08:22]
You might have a really good start-up idea there. But yeah, there really isn't a perfect way. There's just trade-offs for every single situation that you do. But for the most part, people don't really share them. They either put them in a vault where they share across the team, or everyone gets their own instance of that environment variable.

[00:08:45]
For instance, if you have like, I don't know, you need database connection string. Well, you'll probably go into that database, make your own user with your own password. That way you're not sharing it with anyone cuz you have your own version of that. And that way you don't need to share it.

[00:08:58]
You just put it into your environment variable file and things like that. And then you might have people who are in charge of DevOps or something like that, and they'll go into AWS and put them in there. So it's never really shared. It's just where it needs to be and no one else needs to see them.

[00:09:14]
But yeah, no one does this perfectly. GitHub does now detect environment variables in your pull requests, in your repos now, and it'll tell you, like, hey, you got some secrets here. So it's getting better. It's not completely solved.