Zero to Production Node.js on Amazon Web Services Exercise 1 Solution

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

[00:00:03]
>> Kevin Whinnery: You all have risen to the challenge very effectively here. Good job team. I knew you could do it. I had nothing but the utmost confidence. I perused the poll request that came in for these specific issues and we have great solutions for all three issues. So we have two that are clearly winter like there what I was looking for and then we have one that is correct, and one that is more correct.

[00:00:33] So look at both the correct one and the more correct one. So number, one we got from 1267 who I imagine is hanging out on the live stream. So what's up buddy? Good job. This is the most minimal edition of the morgan logger that we could have added.

[00:00:55] So what he did was he NPM installed that module, using probably the --save command, or he might have added it manually. That also is a possibility. But when you know that you wanna add another module to your projects dependencies. You can execute this command npm install. And then --save will actually write the dependency to your package.json, so that the next time another developer npm installs your project they will get that dependency as well.

[00:01:31] So it's always a best practice when you added dependency to add it to the package.jason as well. And npm install -- save is usually the best way to do that and lock in the current version of the module. Probably all we had here was an npm install --save Morgan which would add that dependency to our packaged.json as we have here.

[00:01:55] And then we require the Morgan module and by the default behavior of Morgan is to log HD pure quest to standard out. And he's mounted that middleware there in front of just about everything else on here. So we will get that HTTP logging output on every request to the server.

[00:02:21] So I'm gonna go ahead and plus one that.
>> Kevin Whinnery: So plus one for me. And I'm gonna merge that down, so good work.
>> Speaker 2: [COUGH].
>> Kevin Whinnery: Will pull that down here in just a little bit. All right, so the other we did was to take a look at removing that X powered by, Actually will do that last because that has the two answers.

[00:02:48] The other one was adding an extra shenanigans none header to the response. So we have a couple of submissions there, so we'll go to this one from James that fixes number seven and this is probably the lightest weight way of doing it. In the Web App.js, he added a new middleware just declared it in line which is probably fine.

[00:03:19] He could have created another file. Probably, would've been overkill here. He sets the extra shenanigans header on the response using response .set which is a method available on an express response, express decorated HTTP response object and then he calls next to move on to the next piece of middleware.

[00:03:40] And that's all we need to do, to add that header to do his route. So I'm gonna plus one that, for great work, and I'm gonna merge it down.
>> Kevin Whinnery: Awesome. So now, for the removing the power by express issue. We had a couple approaches both of which are both of which work.

[00:04:07] One of which is slightly more correct. So let's see if I can find the one, okay. So this is the version which is correct, but not as correct as it could be. So here we've defined a global middleware which is gonna be executed on every request that will remove that header X powered by from every response that we send back.

[00:04:35] And that will have the desired effect. But it will also execute on every single request. So it's a little bit inefficient. We don't necessarily need to take that header off on every single request to the to the server. So probably what we want to do is I actually disable that option in Express.

[00:04:56] So I think we have a pull request here, which does just that. So within the configuration options for express, so on an express app, it has a set and a get function and those will set configuration properties, and also get configuration properties. I mean in this case he is setting a configuration property, this x bar powered by header to false, so express will never send it at all.

[00:05:26] Yes question?
>> Speaker 2: Is there any meaningful difference between doing this method of .sets for the header to false And doing it .disable of the entire header [INAUDIBLE] .disable the next power by specifically.
>> Speaker 3: This one's not a header it's a config value.
>> Speaker 2: Okay, so this one are apps.

[00:05:47] Where is the other it was on response.
>> Speaker 3: Right, but you can also do at least according to the interweaves you can do app.disable X powered by in the same area in webapp.js in the rest of the middleware.
>> Kevin Whinnery: Yeah, I believe there's also a signature there for disable for Boolean properties.

[00:06:08] So this is expressly just setting a property to false. Disable I believe toggles a Boolean property, like X powered by to false. So they're equivalent in this case. So the correct guess to might have been app.disable X powered by it would have saved us a couple characters there.

[00:06:28] If we wanted to go that way. So go back out here. Got some plus ones. James added some docs look at you. Good work. I'm gonna add my own plus one.
>> Kevin Whinnery: And we're gonna merge it down.
>> Kevin Whinnery: Super job. So now if we go back out here, we've got some add logging middleware.

[00:07:00] I thought we would have closed this out. So I think we just didn't mention it in the commit message, which is fine. I'm gonna go ahead and close this out. So 30 minutes later, we just knocked out two or three GitHub issues on our project, so great work.

[00:07:19] We're gonna do that again. A couple more times here today. And then I got a fresh batch that I'm gonna load in there tomorrow for you guys to go crazy on as well. So knocked this first one out of the park, very nicely done.