Check out a free preview of the full Full Stack for Front-End Engineers, v3 course

The "Setup Nginx Web Server" Lesson is part of the full, Full Stack for Front-End Engineers, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Jem walks through installing the Nginx web server and using it to route server requests. A brief discussion regarding installing the latest Node.js source is also covered in this segment.


Transcript from the "Setup Nginx Web Server" Lesson

>> That was a lot, and we barely did anything yet. We haven't even built our web server, it still doesn't do anything. So let's make that happen. Let's make our server response to request at this point. So to do that, we need a web server. There are two main web servers, and the two big players are Apache and Nginx.

You've probably heard of one or both. Nginx, if you've ever seen it, it looks like Nix. It's one of those you don't know how to say it until you hear someone else say it, and you're like, okay, okay, I get it. So Nginx, Nginx does a lot of things.

It's a web server, it's reverse proxy. It's a forward proxy, it can do it. It can email proxy. Nginx is really, really powerful. It's written in C, so it's gonna be faster than pretty much anything else you can possibly come up with, faster than node depending on the use case, things like that.

There's also Apache. Apache is great too. Apache has a lot of built-ins, it works well with Java. It works well with PHP right out of the box. For this case, we're using Nginx cuz it's faster, it's pretty configurable, and I just like it. But we can also use Apache.

So we talked about what a, I said reverse proxy and these kind of weird terms, but what does that mean? So when a request comes in from the Internet, what happens then? We know sort of now how the Internet works and how things happen when it hits your server.

How does it know where to go? Who's handling that request? We need some sort of web server in place to route that request to the right place, whether it be the database, the application you wanna run to, or even another server. And that's what Nginx does. It just says, hey, there's a request coming in, where should I route it?

Okay, go into the application, that's what I do. You can create in later and create a node application. We actually don't need Nginx to do that. We can route directly from the Internet to our node application, but that's not a good practice. Nginx is much faster and it has a lot of capabilities that if we were to implement, then a node would just be a pain in the butt, because Nginx is specialized at this.

And Nginx is always gonna be faster than node always. It's different language, different low-level things we won't go into. All right, so this is where it's gonna get even messier. But it's okay, we're gonna walk through it step by step, and I'll explain everything that's happening. So the first thing we have to do is we need to install Nginx.

So we're gonna use apt again. But this time, we're using sudo, because we're not running as root. So we're gonna sudo apt install nginx, and then we're gonna start nginx. And then we're gonna navigate to our server and see what's happening. Is our web server actually up and running?

So let's go ahead and do that now. So sudo apt install nginx. I'm gonna say yes. Okay, so now, let's start Nginx. It may already be started, but let's just do this just to be sure. So sudo service nginx start. All right, one small step for you, one giant leap for your web page.

So now, let's check out what we did, is it working? So I'm gonna grab my IP address, cuz I'm not sure if my hostname is up yet. I'm just gonna grab the IP. Is it up? No, still not working. Hey, instead of a blank page, we got the Nginx welcome page.

So now, you have officially hooked up your IP domain. It's coming in, says, takes time to propagate to your server. Now, we're doing something. Now, we're in the realm of something that's a little bit more familiar as frontend engineers, which is building web pages and hooking them up.

Don't celebrate yet, we still have a while ago to actually make it do more, but this is a good starting place. So one thing I want you to do is check out the default nginx configuration. So I'm gonna do, just do that here. So remember I said Nginx, most of your processes are gonna be looking at etc file, so that's for your Nginx.

So I'm gonna cd there, cd /etc/nginx/. We're gonna do ls to check out. So there's sites-available, sites-enabled. This gets a little messy, it's hard to explain. It's an Nginx thing, we're gonna dance around that and we'll fix it, make it easier to reason about. But for now, go to sites-available, and we can use less to check it out.

Sites-available, and we're just gonna look at the default configuration. So this is the default server configuration for Nginx. Remember I said things are gonna get a little bit dicey, and you're gonna be like, what's going on here? I thought I was an engineer, but I don't recognize any of that stuff, that's okay.

Nginx configs are their own kind of language itself, but they're all really powerful and every line has a reason for being there. So let's explore kind of what the configuration is doing. So the first thing you see is that root. That's just the base directory for your requests.

All of that kind of Welcome to Nginx page, that's located in /var/www/html, and it's just pulling one of those HTML files right down here. So that's where that page is, we can edit it. I think in the next slide, we're gonna touch it a little bit, but we might skip that in the interest of time.

But if you wanna edit that default page, that's where you do it. If you only wanna serve an HTML page, you can just do that from here, and we can be done. We don't need application or anything. Nginx can serve HTML pages just fine. The location block says, where am I going from paths?

The root path is always slash, very similar to your operating system. Slash is just root. But if we wanna say /gojemgo, and we want it to go somewhere else, we just add another location block. So we can do routing within Nginx, we can do it on our application level in our server itself, doesn't really matter, but Nginx has a capability.

They kind of look like programs, so they're called directives. And they essentially say, hey, do this within a server block or a location block. And this guy in this case, it's try_files. It's gonna try to serve an HTML page, which is not there. It's gonna serve a 404 page.

We're not gonna use try_files too much, but we will use a directive called proxy pass, which is just gonna proxy all of our requests into node from Nginx. And then I talked about these are where the default pages live. So let's get and touch that. I want you to feel you have ownership of your server.

Let's go and edit this default page. So default page is located in cd/var, where most of our application will live, in the HTML. And there's no index.html, just this long index.nginx-debian.html. Let's just go and make an index.html page. Or you can add it to the existing one, it doesn't really matter for this exercise.

That should do it, and I'm gonna say, Hello world. And we know from our earlier experiments that this is perfectly valid, symmetrically correct, html, up? Man, how did I get into this spot? I didn't sudo when I should have sudoed, and now I've edited this file and I don't remember how to save anymore.

How do I save? I need sudo permission. I might just quit this one. There is a command to do this if you ever get into this situation, and I will share it later. But it's kind of long and it doesn't really make sense for this case. So I'm gonna cheat here.

And I'm gonna say quit bang, because I should have sudo this file, sudo vi index.html. Good thing I didn't get too far into my wonderful web page where I got stuck. Say, Hello world. Now, I can write quit. And if we go back to browser, what should we see?

We see Hello world, cuz it picks up the index.html before it picks up the Debian file. And there you go, you made your web page, you hooked it up to your domain. Still not working on the domain yet, but you hooked up to your server. Now, we're starting to move.

All right, so Nginx is great. It can do a lot of things, and we can actually create entire applications just run it out on Nginx. But let's move on to the domain we're comfortable with as frontend engineers. Let's move into JavaScript world. We're gonna use Node.js to actually host our application.

So the request will come in to the server, it will go to Nginx, and Nginx will proxy it to Node.js. So we're gonna go through a few steps here. The first one is making sure we have the latest Node.js source. If you just do an apt install nodejs, it's probably gonna be like version 10 or 12, which would work, but we want a more recent version.

So this is just saying, hey, pull from Debian in the, and we want the setup for version 19. We going to execute it using the sudo command into bash, and it's just gonna execute into its own shell. And it's gonna download all of that things and package it up.

And that way, when we do apt-get nodejs, it'll be the latest version linked to the latest source. Make sense? I know, your brain is hurting at this point, cuz we've touched on so many different things. We're almost there, we're in the home stretch for getting this all hooked up.

So now, we're going to install node.js, but if we just install from apt, it's gonna be an older version. We want 19 because we're on the bleeding edge here. So we're gonna use the curl command to pull from nodesource, the Debian version. We're gonna execute that in our shell using sudo, and it's gonna pipe it into a new shell that's gonna run the install.

That way when we do apt-get install nodejs, it's gonna be the latest version rather than the general package maintain version that they have.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now