API Design in Node.js (using Express & Mongo) Configuration

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Speaker 1: So on to like configuration now. We can use process.env.NODE_ENV like I was saying before, that variable to tell our application what environment it's running in. And the possible options that we use as a community is gonna be some variance of these three, but usually these three. So it's either you're in testing, development, or production.

[00:00:24] By default you're in nothing so you have to set that default yourself. So it's a good practice, or at least in my opinion, to just set it to development by default. So just assume you're always in development until you specifically change it from production or testing.
>> Speaker 1: So, those are the common ones.

[00:00:43] Depending on the ENV, we can change things in our app, like database URLs or toggle logging on and off. That way we don't have to go in and erase every single, where's that console log. I think I'll find it and erase it. You can just turn it off with an environment variable like turn off all logging.

[00:00:59] All right. We can also set and reference other environment variables. So if I wanted to get the secret token for Facebook so I can have it work on my authentication scheme, you can do that, right, environment variables. So instead of searching everywhere for these values to change, so for instance, if I just sprinkled these values all the way through our server, right, and then now I had to go change them like if I was like all right, logging, you're going to be enabled if node E and V is production.

[00:01:27] And then another file, I did the same thing for logging. And another file, I did the same thing for logging. And now, we're at testing, so right now I got to go change all of this stuff. It'd be great if we could just put this in one place.

[00:01:38] So what we're going to do is have a config file. Just one file that sets up all these variables inside of our application. Now files is gonna export an object. That will just pass an object around our application. And that's gonna tell our application about what it can and cannot do, and what certain values are, and what they are not.

[00:01:58] So depending on the NODE_ENV, we can require other config files in. And merge the two together so our app can use it. So I'll show you what that looks like and why that's important. So here's our config file. It might look something like this. Yeah, question.
>> Speaker 2: The question is why are we using service oriented instead of MVC?

[00:02:16]
>> Speaker 1: Good question. There really isn't a specific reason other than, one I really like service oriented approach. It's very familiar if you've built on the front end for things like a components with like React or Angular or anything like that web components it favors that and the Node is actually moving towards that.

[00:02:35] So like there's big push for different types like real time applications with Node so using things like Falcor or GraphQL or even using Flux architecture on the back end, it just makes more sense for us to reason about our application in this way. But there's definitely nothing wrong with the traditional way, I still see that happening.

[00:02:55] So frameworks like JS still use that, there's nothing wrong with it. Just like there is nothing wrong if you're on the front end and you wanted to organize your code like put all my JavaScript in this file, put all my CSS in this file, put all my HTML in this file.

[00:03:06] There's nothing wrong with that, it'll work. But, in my opinion it's a lot easier to just have everything that belongs to something in one place. That way I don't have to go look a million places for it. It also allows me to, if i just want to not use that feature anymore I can just go to whatever is using it and comment it out and it will still work, everything will still work it just won't that feature.

[00:03:25] Versus if I wanted to turn it off in the other approach I'd have to go in many different places to find where it's being used and that could be kind of hard. So this is pros and cons for both approaches but I think this is a better approach and because Express has those mini routers it kind of like encourages you to set it up this way.

[00:03:47]
>> Speaker 1: Any other questions on that? Great so we have this config object so it looks something like this. We'll have like a ENV which is like what environment are we in. So remember I said by default NODE_ENV is nothing so you should set it to something and that's what I'm doing here.

[00:04:02] So ENV is either gonna be process ENV or development. Logging I don't know maybe turn it off by default, and then we have like some secrets we'll have like a GitHub token or a JSON web token secret something like that. So this is just an example of like what a config file may look like.

[00:04:19] It's depending on what your app needs but very important things that we use throughout applications we'd store in like a specific file. Right notice I didn't hard code the actual secret GITHUB_TOKEN in here, or the secret JSON web token in here, cuz this file's gonna be in source control, so I didn't hard code it in.

[00:04:33] It's gonna be passing through the environment, all right? But I also don't wanna go around every single file and have to write this out. I need the GITHUB_TOKEN. Let me write process.env.GITHUB_TOKEN. I don't wanna write that out, right? So I could just say, just give me config.secret.GITHUB_TOKEN. Which is actually just as long.

[00:04:51] [LAUGH] Right. But at least I know it's in one place.
>> Speaker 1: So the part that I was talking about as far as like using the environment variable to load up different configurations, this is really cool I think, this is a practice that I learned, I can't remember where I learned it, but I adopted it and I went with it and I really liked it.

[00:05:12] And I'm starting to see a lot of people use it too. What we can use this approach, you can think of this config object as the base config. This is the config that it starts off with, but depending on the environment. We'll load in a different config object that will override properties on here, right?

[00:05:30] So depending on what the no EMV is, whether it's development, testing or production, we'll have an equivalent file. So this is config.js, and then we'll have development.js and testing.js and production.js. And because those names of the files line up with the name of the environments that we're in.

[00:05:50] We can just use the environment to require the appropriate file. That way we don't have to guess which file to require. So we can just say require the process.NODE_ENV, which could be testing, development or production. And since we have that testing.js development.js and production.js, it's gonna require one of those files, depending on the environment.

[00:06:08] All right.
>> Speaker 1: Just like this. So you can put variables inside of require statement. So it's like I wanna require whatever the environment is. So this might be requiretesting.js, or requireproduction.js, or requiredevelopment.js. And that itself is gonna be another object just like this that has different properties on it, and maybe some of the same properties.

[00:06:32] Maybe it will overwrite logging to be true. So in development, we definitely want logging to be true. We wanna, if we write a log, we wanna see the development. So maybe in development.js, it will say logging true. And that will override this. All right, so then we do that.

[00:06:46] And then what we do is we just merge them.
>> Speaker 1: So actually, now that I think about it, assign probably wouldn't work here because it doesn't go all the way deep. You probably use something like underscore merge but, you get the point. We need to extend these objects together.

[00:07:05] So the way this, if you don't know what assign or extend how that works is every, so what happens is every argument after the first argument, every object, it'll take it and put, and it will merge the properties onto the object on the left. So I can put as many objects as I want over here and it will just keep putting them on this object and then return it.

[00:07:32]
>> Speaker 1: So that's like ENV will take precedent over this config and it will overwrite properties on it and then we'll export it. So now our application now has this new object with all these properties on it and we can use these flags or these values in here to do things in our application.

[00:07:47] Any questions?
>> Speaker 1: You're gonna see this and you're gonna do this so.
>> Speaker 1: Okay. So.
>> Speaker 1: For our blog application which is what we're going to be making. The server part at least, not the front end. The front end's already made. We made it on Monday and Tuesday.

[00:08:13] We can start thinking about what resources we would need, to make and start planning out the resources. So think about routes, models, controllers, right? So we can plan out the routes so that we can start organizing it. So for the resources we'll be using just very minimal resources.

[00:08:34] We're not gonna get too involved with this API so as far as resources goes we're only gonna be using three. We're gonna have users we're gonna have posts, which are the actual blog posts themselves, and then we'll have categories, that way we can organize our posts like this post has this category like a simple blog.

[00:08:50] So those are the only resources we are going to use. We're not going to get too crazy. There are so many things. We can have tags, we can have all different types of stuff in a blog. But we're gonna have users who can create posts. We'll have posts that belong to users and have many categories.

[00:09:04] Then we'll have categories that don't belong to anything.
>> Speaker 1: So knowing what we know about REST and API design so far, we know that we will be creating CRUD routes for these resources using middleware and routers. Just like we did with the lions and tigers. So we have our resources.

[00:09:23] We know we will create CRUD routes, and we know for sure that there are at least five CRUD routes we'll make for each one of these resources. So if we just do the math, that's 15 routes. We know that just by that. Will we ever use all those routes?

[00:09:37] No, but it's nice. We should probably start with them and then we'll take back. So, for instance, we don't want the ability to go in and create users. Right? You'd be God. Right? You don't want to go in and just start making users. You need some type of authentication for that.

[00:09:49] You need to sign up. Or be invited or something like that like you can't go to somebody's work place blog and be like I am a user now I'm gonna start writing posts. You can't do that, you've gotta be invited right, or you have to be the creator and then there's different roles and stuff.

[00:10:03] So yeah but we'll start off just assuming that we'll create all crud routes for these things. So yeah we'll use middleware and routers to tweak and configure those and then we'll model the resources later, so don't worry about modeling the data. All right, we don't need to do that right now.

[00:10:20] All we need to know is that we have these resources, they will have crud and they definitely need those routes so we can actually start writing code for it now. But we'll model the resources after we get done with this, then we'll talk about Mongo and stuff. So but now that's all we need to have the resources so we can get started building out the skeleton files.

[00:10:35] So knowing what we know about organization and configuration and the resources we're gonna use, that's enough information for us to go ahead and start building out the scaffold version of our API. So we'll have all the files in place, they might not be doing anything yet, but we'll have it all in there.

[00:10:58] Does that make sense?
>> Speaker 1: Okay, any questions on this, cuz I about to tell you what you're about to do? Yes.
>> Speaker 2: They were kind of discussing the mock and the fixture. And somebody mentioned that, when you were talking about the lion that you created, in his opinion that that wasn't a mock, that that was a fixture, where a mock is used more like an API call that, rather than waiting for it to complete, you just mock the API.

[00:11:29]
>> Speaker 1: Yeah that's also true so yeah that's true. I think they're loosely used, I don't really think there's a right answer and that's probably why I couldn't come up with a good one because when I think of mocks, I guess I'm thinking more of on a front end of using stuff like angular.

[00:11:42] I'm like mocking dependencies, but also at the same time that does make sense. You're mocking API calls you want to wait for them. So, yeah it's really hard to determine, those are some of the loosely used terms in our profession so, but that, I like that explanation, so that works very well in our context.