REST & GraphQL API Design in Node.js, v2 (using Express & MongoDB) Solution: Dynamic Config

Transcript from the "Solution: Dynamic Config" Lesson

[00:00:02]
>> Scott Moss: All right, welcome back. So I hope everyone had fun making their configuration driven application. Either taking inspiration from what I did, using what I did or creating your own. At the end of the day, there's really no wrong answer. You just wanna make sure that you're able to change your configurations.

[00:00:18] So things like secrets, URLs, pretty much anything that needs to change, depending on where you are. You wanna make that dynamic. And the best way to do that service side is with environment variables. So we gotta walk through pretty much how I did it. So I'm curious, anybody do something different?

[00:00:34] Slightly different, no? Yeah, I mean the only other way I could think of doing something like this is, you can do a dynamic require, right. So this name right here is dynamic. But I don't recommend doing that. Then, we can do some pretty cool things with webpack as well but you don't have to.

[00:00:56] I say this is probably the safest way that you can do it, and then if you wanna load in secrets there is a package called .env that you can use locally to, you can add a .env file to your repo. And then, probably during development, maybe testing, you'll load up those environment variables in your environment and then you'll have access to them, that way you'll never even do stuff like this.

[00:01:18] This is all inside of a file, and then just make sure you don't commit that file to git.
>> Scott Moss: Any questions on configuration development. Why we needed? Why it's important? Why you should have it? Yes?
>> Speaker 2: What is a good place to keep your secrets?
>> Scott Moss: Yeah, so a good place to keep your secrets is, so let's say, let's take this out.

[00:01:37] Let's say we were doing something with stripe. All right, everybody uses stripe, right? So, let's say we were doing that and we were like, you know, new stripe or stripe equals. So new stripe thing and we had to pass in some secrets right here, right. To this object to this new stripe.

[00:01:55] I'll tell you what you don't do and then we'll eventually get to what we should be doing. So let's say we need to put the secret right here. You're not gonna put it right here, because it's in plain sight. You commit this to GitHub now your secret is there, right?

[00:02:11] Even if you got a private repo it's still somewhere on the Internet, right? So you're not gonna put it there. So the next thing you might say is, well, I'll put it on my config, right? So you'll have config.stripeseeker. Okay, that's cool but let's see how you actually put that on your config.

[00:02:27] So let's go down to config. So you definitely want this to be config driven, so then you go down to you config and you're like, cool let me put my start in here, and my hard in here. That's the same thing it's still in plain sight, so you definitely don't wanna do that.

[00:02:39] So what you do instead is you using environment variable process.env.STRIPE_KEY or whatever, right? So you have that, and then what you would do is you would make a .env file locally right here. Right here make a .env file. And you'll get that environment variable, which was called stripe key like this.

[00:03:03] You'll do that. And you'll give it its key value or whatever it is.
>> Scott Moss: And then just save this file. But then you don't check this file in the GitHub. You put it in gitignore, you just don't put it in GitHub, it's only local, right? And then you use a package called .env, it's called .env right here.

[00:03:28] Let me make this bigger.
>> Scott Moss: .env basically allows you to, it'll read the .env file on the root of your repo and it will take every environment available in there and load it into your environment for you. So you only need this for development. So you'll be like, if it's development, or if it's testing.

[00:03:49] Let me go ahead and load up this environment file, and it'll load it up for you. So that's what you would do locally. And then production, you use your platform to inject your environment variables. You don't need this file. So that's why don't need to check it into GitHub.

[00:04:00] Because in production you would just go in the back end of Heroku, AWS, Digital Ocean, whatever you're doing, and you would put them in there, right? So those are the places for a birevel so that means like that means summon your readme you put something like. You would tell basically you would do is to practice this.

[00:04:18] You would come in here, because the .env file is not gonna detect in GitHub, you'd make a new file called .env like, stat sample or something like that, or example. And then you come in here and you put the keys of all the env variables that someone would need to run this locally.

[00:04:37] So you're like, hey, and then you'd be like, get it from Sarah. And then you would put all that stuff here. And then what they would do is, they will come in here and then you read me. You like, hey, there's a .env, .simple for each key in there.

[00:04:52] You can read where you need to go get that key from. Your data team uses this like, vault where you store your secrets or something. Wherever that is, you would get it from there. You would make a .env file and put them in there. This is an example file of what keys you need.

[00:05:07] Or we could just put them in the read me. But basically somewhere in your repo you need to say, these are the keys that you need. Go get the values from our place where we store our values, wherever that is, and then they will just use that and then everybody has their own local.env.

[00:05:21] .env never gets checked in but the env sample does. Does that make sense?
>> Speaker 2: Because I was wondering where do you keep all the secrets maybe online? Who is the bearer of the secrets?
>> Scott Moss: I see what you're saying. Like I said, it depends on your platform, right?

[00:05:40] If you're talking about keeping the secrets for production, you literally just put them in like, let me, if I can just show a quick example without showing some. Have you ever deployed on AWS or Heroku? Heroku, so Heroku you can go to the settings, you just put them in right there.

[00:06:01] Have you ever done that before? Yeah, so whatever your secrets are you'll put them in there. But if you're just saying where do you store those, so you can remember them. That's up to your team. Your team could use something like, man, there's so many secret password things out there.

[00:06:16] Basically, use some type of encrypted vault. I can't think of one off the top of my head cuz I don't use them anymore. But, cuz most of the secrets we have are generated from a third party because most of our secrets tie into like, this is your secret for this API key like Stripe.

[00:06:30] Or here's your AWS secret, and we keep that in like a CSV file somewhere locally, or something like that. So most of the secrets we have are not generated by us, so we don't need to save them somewhere. But they're usually generated from third party, and we just go to that third party's app and copy from the settings.

[00:06:45] So it's created there. But yeah, there are secret sharing apps, I don't know why I can't think of one right now, there's so many of them that you can use and they all cost money. Last pass is one of them, they do passwords. You can also do secret stuff.

[00:06:58] There's also 1Password. 1Password is one. Yeah, you can do 1Password, pretty much anything like this, allows you to store your secrets and share them across your team. So however you wanna do it. You can throw them in a Firebase if you want like, put them in an adjacent file on S3, whatever you wanna do.

[00:07:19] Good question.