Transcript from the "Deploying Your Servers" Lesson
>> Scott Moss: So publishing MPM modules is one thing, but now if you have a server. You don't really publish a server to MPM. You gotta deploy that thing, this is an app, so you would host it somewhere else. But basically every cloud provider has its own instructions, and just never hard code secrets.
[00:00:13] If you ever created a server before, you know you don't hard code secrets in a server. You use the environment variables that you inject into the server at run time. Most cloud providers have some GUI or some script or some CLI that you can say, here are the environment variables that I want you to read from the environment.
[00:00:28] You just don't put secrets in your app and check it in the git, just don't do that. Anybody that's ever got hacked ever did that, and they regretted it. So just don't do that, use environment variables and you can read them with process.env, and that's how you get your environment variables.
[00:00:43] So that's the only thing. Other than that, you have to follow instructions of the cloud provider. Each one has their own, Heroku says you have to do it this way, AWS has got this way. But from my experience, most of them just tie in to GitHub and some type of CI and go from there.
[00:01:00] So if you can set up some type of git integration, some GitHub integration, that's probably the best way to go. So as long as you stuff like GitHub or GitLab, you're pretty much good to go when it comes to deploying things. But again, it's gonna be very specific to the needs of your application.
[00:01:14] If you've got load balancers and all this other stuff, and on-premise infrastructure, it can get pretty complicated. For most call providers, they just tie it to GitHub, and you can go from there. And deploying static websites and APIs are two different things, but at the end of the day, you're going to some machine on the cloud.
>> Scott Moss: A few things to remember, like I said, remove the secrets and use environment variables. Set up a CI flow for your app, so set up some type of continuous integration. I don't want to go over that because it's literally just dev ops, and it's a whole other thing.
[00:01:47] But that's just something to help you get going. And make sure you are developing with the same version of Node locally that you are deploying to. So if you're deploying Heroku with Node 8, but you're developing locally with Node 10, yeah, your app's probably not gonna work. So, just make sure they're both on the same version.
[00:02:04] This is where MVM comes in, because if your Cloud provider only supports Node 9 but you use Node 10 locally. No problem, switch to Node 9 on MVM and now you can develop on that. You're good to go. Or you can use a transpiler like Babble to transpile your code down to something that works for the right version.
[00:02:21] So there's a lot of things you can do. But either way, you need to make sure you're matching the versions from your deployment target to your local target, so you don't get differences, which is a big problem.
>> Scott Moss: Any question on that? Yes?
>> Speaker 2: Are Node applications siloed enough that if the version is right, that's enough?
[00:02:42] You don't need to mess with Docker to get the whole operating system to be in parity?
>> Scott Moss: Yep, that's exactly right. Yep, if it's the right version you're good. There's nothing else you've gotta do. It just works. There's literally nothing else you have to do. I've never come across it's the right version, but you have, it's just not a thing.
[00:03:00] Actually let me take that back. The only time I've ever seen that is when the NPM doesn't match. All right, you may have a version 10 of Node, but you have NPM version 4 for some reason, I don't know how you got that. But that might be a problem, but I don't really use NPM use Yarn.
[00:03:14] But yeah, then you just got to update your NPM, and you just got to make sure you have the latest NPM. Because NPM ships with no, you should almost never have that problem, but it could happen somewhere. So yeah, I would imagine just that those differences.
>> Scott Moss: Any other questions?
>> Scott Moss: Yes?
>> Speaker 3: Earlier, you said that we shouldn't really serve static assets.
>> Scott Moss: Yeah.
>> Speaker 3: With Node there are so many tools that produce static sites on top of Node.
>> Scott Moss: Yeah, but they don't serve them. So static site generators and static site servers are two different things.
[00:03:52] So a static site generator is something that takes a combination of data from some remote server, some JSON file, some markdown file, wherever it's coming from. Takes some type of templating engine, whether it's Angular, React, I mean, pick your flavor, there's so many of them. And then outputs HTML and CSS ready for the website, that's a static site generator.
[00:04:13] Those are different. A static site server is something that's deployed in a cloud, that serves files. So if I go to mysite.com, and when I get back that index.html, if a Node server is serving that, probably not the best. Because it's just not going to be that good, it just can't compete with something like a CDN, that's just like all over the world.
[00:04:34] You got this one origin server that's all the way over here, and you have a user that's right here, that's like just like give me the user HTML. So it's gonna go all you over here, get the index.html, come back And that index.html has script tags and link tags that are all the way over here.
[00:04:49] And just keep doing this. Whereas if you had a CDN it'll just be right here.
>> Speaker 3: Yeah but this basically applies to Apache servers as well, correct?
>> Scott Moss: Yep, it's the same thing as any other server, it's just I think a lot of people. When Node first came out, there was just so many examples and documentation of creating these servers that serve static assets, and it's just not the thing.
[00:05:10] Highly recommend just not doing it. The only time you would ever do something close to that is like I said, we're doing universal isomorphic applications, but even then you'd need to add some type of caching layer. At some point you gotta cache some of that stuff. So I just recommend keeping Node, as far as APIs are concerned, as JSON.
[00:05:26] Don't really do static. And if you absolutely have to, then put a reverse proxy in front of it, like NGINX. Have NGINX serve the static assets, and then have the node server always serve JSON. That way it's like, at least you did that part, you can cache stuff on this layer.
[00:05:40] So that's what I recommend. But yeah, I do not recommend having Node read from file and send stuff back, because eventually you'll just build your own CDN. Be like, all right, I gotta cash these file reads, then I gotta globally distribute these servers. You're just building a CDN at that point, so yeah just don't do it.
>> Speaker 4: So I here you can do in Node these days.
>> Scott Moss: You can do that in Node now, yeah, you can totally do that. It's pretty awesome, but not that way, [LAUGH] yeah.