API Design in Node.js (using Express & Mongo) Deployment Overview
This course has been updated! We now recommend you take the API Design in Node.js, v4 course.
Transcript from the "Deployment Overview" Lesson
>> Scott Moss: I had to cut some stuff, I cut the real-time thing, cuz that actually takes a long time. But it will be in the repo, so if anyone wants to look at that stuff, it'll be in there, as far as like the sockets, having web sockets and be able to do like.
[00:00:17] Write a blog post in real-time with somebody else, that's gonna be in there, you can look at the code for it. The thing that I thought was more important was to get in was employment, so that's what we're gonna do now. So, we have some notes on deployment.
[00:00:33] I had some notes on protecting your routes. I forgot I had that. We didn't need it, though. We talked about it already. So deployment. Deployment is actually really easy. You probably don't even need to write notes on this, in my opinion. But what we are gonna do is, I'm gonna talk about this stuff and then we're all just gonna deploy the app together.
[00:00:49] You can follow along with me, and just watch me, or you can do it in your computer, but we're just gonna do it together and walk through the process as to what it takes to deploy it. A node app. I don't know, let's use Heroku, it's probably the easiest.
[00:01:03] AWS will be here forever [LAUGH]. So deployment though is relatively easy. All major, this is the first typo I have today I promise, this was the first typo. Or no I had one earlier. Only two typos today, that's actually really good. So all major platforms support it these days and adhere to conventions to smooth the process even more.
[00:01:24] Some things to consider when deploying. Use envs for secrets, don't check them into source control. Right, don't check your secret stuff in the source control. Once it's there, it's there forever. I don't care if you like, you checked it into GitHub, and you're like, wait hold on. When they get that out.
[00:01:42] Okay, you got it out. But there's this person who has built this service that just listens to all the hooks on GitHub. Every single thing that comes in GitHub, and he listens for the stuff, and he logs it. He logs everything. So that event was already sent off, so whoever's listening to that public API on GitHub already got it, even though you already took it off.
[00:02:03] So it's still there. The chance of them using it, probably not. But I'm just saying, it's never gone. So another way to get around that is just to change the secret. Then you gotta go like change your stuff. So just don't put it on GitHub. Make sure you're error handling.
[00:02:17] We talked about that. That's gonna keep the server running. So if you're being weary of errors, try catching, setup middle-ware. Anywhere you think there might be an error, you probably wanna handle it, otherwise your servers gonna see this and it's gonna crash. And if your server crashes with five people in here writing their blogs together, it's not gonna be fun.
[00:02:41] So, handle those errors.
>> Scott Moss: Make sure all your dependencies are being installed. A misconception is people they'll deploy, and they think that the thing that they're deploying to installed all their dependencies, but it really didn't. For instance, you might have a global dependency that your app is relying on.
[00:03:04] I don't know what that might be. Or maybe you are using Gulp to build your stuff. But you are using the global version of Gulp on your computer. So when you deploy Heroku doesn't npm install. Gulp is not in the package.json. Cuz you're using it globally. And then you tell Heroku to do a Gulp build and it's like, what's Gulp?
[00:03:21] I don't know what that is. Cuz you never put it in your package.JSON. You were using the global version. So make sure all you stuff is installed. So, anything that you application needs, make sure it's in the package.json. Speaking of which dev dependencies and dependencies. So, by default, what Heroku will do, and I think most other platforms do too, when they run npm install.
[00:03:41] They'll actually do something like this, they'll say npm install -- production. And what that does it only npm installs stuff in the dependency section, it's only on npm install this stuff, it won't npm install this stuff,. The dev dependencies or maybe I'm not sure if it does that.
[00:04:01] Peer dependencies are going away anyway. But if we're sure, only install that. So if you were relying on something again like Gulp, if you we're gonna tell Heroku like once you install everything, do a Gulp build. But Gulp was a dev dependency, it's gonna be like, I don't know what Gulp is, I never installed it.
[00:04:18] So again make sure all the dependencies that you need are installed. And now it comes down what you need to happen before you deploy. Some people like to build before they deploy. Some people like to have their code built during deployment. So it all depends on what you're doing.
[00:04:34] If you have a CI, and you're CI's testing and it's building. Or maybe you just give it to Heroku and Heroku does the building, or maybe you build it locally and give it to Heroku. I'm not sure. It all depends on what you're doing.
>> Scott Moss: But yeah, again, if you're gonna have your platform build it for you, make sure it has access to all of your build tools.
[00:04:57] Heroku and AWS don't have gulp just hanging around waiting for you to use it or web pack or whatever you use. It's not just there chilling. They got npm for sure, they don't have the other stuff. You can also freeze node modules by running npm shrinkwrap. Npm shrinkwrap will just freeze the versions of the dependencies.
[00:05:17] So they don't, so every time you run npm install, they don't go fetch the latest. It's like freeze everything to be this version and that's it. And you could do that.
>> Scott Moss: And don't hard code things like development URLs. Right, for instance if we, like in our user controller.
[00:05:41] Let's say we made a call to Facebook in here, we're like, yeah Facebook. Or like I don't know, otherServer.get, all right, and there was like some URL here and this is a bad example or like it was like it was almost another port. We had another server on another port that was a local host.
>> Scott Moss: And it was on port 5000. By hard coding that in, what happens is now when we deploy this server, and when this route gets hit and it tries to hit localhost:5000, it's gonna be like, what's that? And it's not gonna work. All right and then if you deploy the server that's on 5000, it's got its own URL and they change too.
[00:06:24] So don't hard code these things.
>> Scott Moss: You can pass those in with environment variables. Anything you need to change on a per environment basis, it should be an environment variable. And then you can use the config to change those things. Another thing you don't wanna hard code is like database URLs, stuff like that.
[00:06:52] Right? So we did like a hybrid approach of where we like hard coded the database URLs but only for a specific environment, all right, so if we go to hard config. Like development.js it has this database url. Yes, it's hard-coded, this URL will ever work in development environment.
[00:07:12] Which is fine, we don't really care. This is exactly what we want. Testing.js. This URL is hard-coded, but it will only ever be here during testing environment, which is probably also fine. But maybe you run your tests somewhere else and they have a different environment variable for that, so you need to add that here.
[00:07:31] But for production, you definitely don't wanna hard-code that. Production will be an environmental variable, cuz you're gonna be binding to some hosted database. So on Heroku they have like hosted Mongo and things, but other servers it's Mongo sup, Mongo beta, whatever freaking Mongo thing they have on there.
[00:07:45] You'll be binding to some environment variable there for your URL. So that's why I didn't put anything here, we're gonna do that next
>> Scott Moss: And ports. Ports is another one, so again development. I think we articulated this. Process.env.port. We don't know what port we're gonna be on, it's whatever the thing we deploy on says what port we're on.
[00:08:08] And they always put it on this. It will, almost every platform uses that, it's on the P-O-R-T environment variable, or default to 3,000. Which is why ours is on 3,000. Any questions on that? Another good thing is a good practice is like put stuff like this in environment variable too.
[00:08:29] This time and days, all right, what if we wanna go change this, now you got to go redeploy, just to change this one line. If this was in an environment, I could just change the environment. But in environment, we'll will just restart and then it's still good. So stuff like this is great, put in an environment variable.