Application Environment Variables

[00:00:00]
>> Erik Reinert: Okay, so now we're gonna hop into source code. So personally, you're going to notice that I like to get the annoying stuff out of the way so that we can do the more fun stuff. And for me, both of what we just did is annoying, so I'd rather just get that out of the way.

[00:00:12]
Let's go ahead and go back into source code. And what we're going to do now is we're going to start learning about the application. Like, we're going to start getting ourselves a little bit comfortable with what this is, how it works. If I open it up and I look at again, consider this a scenario where you were just given this.

[00:00:29]
You have no idea what this is. This is very common in the DevOps world. So is there anything in here from a DevOps perspective that stands out to you in this list? What would be, maybe, and I'll say there's at least two, yeah? README. README, okay, that's one of them, yep.

[00:00:47]
What else? The env. The .env file. Yep, yep. The .env file. Env, yeah. Yep, yep .env file, yep. What else? Docker Compose. Yep, Docker Compose as well, yeah. So if I was jumping into this project, those would be the three things that I would look at first. I would first look at the readme and say, like, please help me, please, God, make sure somebody documented.

[00:01:10]
If they didn't, which more than likely they probably didn't, then I would go and look at the other two. So let's really quickly look at the readme and we'll notice. Okay, cool. We actually have documentation. Nice, all right, cool. So if we look at it, we see that again, it's a platform.

[00:01:27]
We're just gonna call it goals for now. It has some features to it, so it has user auth. Like Mark said you could create profiles. So, okay, we're gonna be doing database work, that's for sure. It has the ability to share updates. It's got some functionality to it.

[00:01:45]
Let's look at the prereqs. We've got Go. We'll need to make sure we've got Go installed Docker and Docker Compose. Cool. Postgres as well. Then Google Cloud, which we just did. We're off to a good start. We've got a little bit of information in here on the Docker setup.

[00:02:01]
It looks like we can use Docker Compose to bring up a database. Okay, cool. Then we've got some information on the OAUTH setup, which is what we just did. Boy. This is definitely not the most ideal solution to manage your SQL schema. But hey, it's a start. At least we have schema.

[00:02:21]
So that's good, that's good. But that's kind of like, if I was being brought onto this project and I saw it here, I would immediately go, God. That's something we need to fix, right? Because you don't want to be seeding databases through a readme file. But it's actually really good that it was done in this scenario because it gives us an opportunity to do it.

[00:02:39]
Okay, cool. We know that we're using Docker. We know that we need to set up Google. We know that we've got some schema in here as well. And then, okay, cool, we've got some more schema. And then, okay, yeah, there we go. Yeah, .env. So we've got a .emv is here as well.

[00:02:58]
It looks like we copy that, we create a new one, we update it, we then source it and then we run it. Why don't we do that? Why don't we make sure the app works basically before we try deploying it? That would be my next recommendation. By the way, if you're in a scenario where you're taking on an app like this and you have no idea how it works, familiarize yourself with it because you're going to be debugging it.

[00:03:24]
And so if you don't know how to run the app, you don't know what credentials it requires and stuff like that, you're just going to be bashing your head against the wall later when you try debugging it and understand why it's not working. I think our first goal should be let's get a dev environment up and running, let's make sure that it works locally and everything is good to go.

[00:03:43]
What I'm going to do is I'm going to take the document's advice and I'm going to copy my ENV example to a ENV file itself. The reason why I'm doing this is because the repository should ignore that ENV file, but I should then be able to use it and keep it in the repo for future stuff and whatever.

[00:04:04]
So I'm gonna copy that. Then I use neovim to be clear. So all the stuff I'm going to be doing is in neovim, but yeah, by the way, yeah, but you're welcome to use any editor, obviously you don't have to use NeoBIM, so let's go ahead and open that file.

[00:04:20]
Okay, cool. So we've even got some stuff here that we kind of noticed. So we've got a Google client id, we've got a Google client secret, we've got a URL that's already populated, and we've got a database URL that's already populated. Okay, cool. So it looks like what we need to do is we need to put in the client ID and client secrets that we just generated.

[00:04:38]
So I'm going to do this off screen because I don't feel like doxing myself again. But what I would tell you to do next is to paste in that client ID and that client secret values directly to it. So it should look something like this and then something like this once you're done, but with the actual values.

[00:04:54]
So let me go ahead and do this off screen. I have a strong feeling I'm going to be generating multiple credentials today. All right, and if you are curious to make sure that you know which is the right for which value, the client ID is the like .apps.googleusercontent, and then the secret is just the pure string value.

[00:05:23]
So just to note. So again, make sure you've got the client ID and client secret and then just save and close that file. So there we go. Now I should have my .env fully populated. Cool, and then I'm just gonna do source.env. That's it. Can anyone tell me what source does reads it into your shell?

[00:05:48]
Can you give me a little bit more of a detailed answer than that? What do you mean by reads it into my shell? I guess that it sources and it makes the configurations live into your environment source shell. Basically what it does is it will take any variable that I put in here or I export and then it'll immediately make it available in my shell environment.

[00:06:09]
It exports those for me. So if I do echo POSTGRES_URL, you can see I now have that URL, right? This is common in development where I want to load a configuration, but I don't want to have to do a ton of stuff to do it. ENV is a really nice approach so that then again, once you're ready, you just do source ENV and whenever you update environment variables or add new ones, you can just do source ENV again and then it'll update it and then once you exit that shell, it will no longer be there does in that ENV file.

[00:06:45]
Do you have to have the export in front of the environment variable for source.env? You don't. No, it's just like a habit I have because sometimes it doesn't work and I don't really remember why. But yeah, you normally don't have to. Yeah, normally you just do. But underneath the hood, Source is just running a shell script.

[00:07:07]
So you can do that. It's just like when you have this, it's actually just bash. So if I wanted to, I could actually write bash code and da, da, da. Source just runs a script, is all I'm trying to say. So if you want to put export in there, you can, but you don't have to.