Transcript
  • Servers and Tools

Serve Static Files Quickly

From the class:  Getting Started with NGINX

One of the other features of Engine Access, we can really easily serve static files. Remember back in our project that folder Public? It's where we might put any files that we want to be served directly as files.

So we don't want to have to create a special route for those in our application. We just want them to be served up exactly as they are as regular files. And here's an example of that.

It's a robots.txt file. This tells search engines what they're supposed to be allowed to see or what we want them to index. In this case, we're saying all user agents are allowed and you can start from the root and go from there.

So this is a typical file you'll see in web servers. But you can imagine other files in this public folder we might have an icon, for instance, or images. We might have built CSS files or JavaScript files, if you have assets. So we could have all kinds of different files that go into the public folder.

What I want to do is to configure nginx to provide access to these files in this folder. So I'll go over to the Configuration area. And I'm going to use a new directive now called Root. Root is going to say what is the root file path that will serve up this application.

And in this case, it's going to be apps boom current and then I want the Public folder to be the one that gets served up to the world. So any files that are in the Public folder can get served directly from nginx. So be careful with what folder you choose to use for this.

Now, we'll login to the server. You can SSH into it if you're not there already. And you can say sudo system control reload nginx. And now we should be able to CURL for boom.com. And we can just grab robots.txt directly.

We need to use the capital L option to follow the redirect remember, otherwise we need to use WWW. OK. And now we get back the content for that robots.txt file. Here it is down at the bottom.

And another nice feature is nginx automatically figured out the content type as text plain simply by looking at the extension of the file. Another nice feature of nginx is we can tell it to automatically gzip content when the client requests it. So let's uncomment this line on 55 that says we want to gzip text plain types if that's what the client requests.

Now, usually the browser will automatically add this as an excepted including type but we're going to do it manually using the CURL command line tool. And we'll head over and restart the nginx again. And this time I'm going to CURL for boom.com robots.txt. But I'm going to add a special header. So the header is going to be accept encoding gzip.

This time notice the content is in this binary format. And that's because it's actually been compressed using the gzip format, if I can say it properly. And here's the content encoding header that tells us that it's been encoded using gzip.

So normally when a browser requests a resource like this, it's going to send along this header that says that we are accepting an encoding of gzip. And nginx can automatically gzip this for us and send it back to the client this way. So really useful for speeding up the transfer of content.

Another useful feature of nginx is we can route paths and treat them each uniquely. I can use the location directive to do that. And I pass the location directive a path name. So in this case, for instance, if I wanted to treat anything under the assets path a particular way, I can put those things inside of this block.

Oftentimes in web application frameworks, the assets path will be where you'll put CSS or JavaScript that's been compiled or minified during a build process. And we want to be able to serve those up as files directly to the client. We might also want content delivery networks or CDNs for short to be able to cash those files indefinitely or for one year. And that speeds up their delivery.

So we can tell a public servicers out there, hey, you can go ahead and cache this file for up to one year. Then after that, come back to me. I'm going to be the origin server. And you can grab the original file.

So what we'll do next, we'll take a look at the path and see if it starts with this assets thing. So if I say assets, if I request assets, let's just say build.css. This location block will be used to handle this request. And what we can do is to add some directives in here.

And the first one is going to be the expires directive. And I'm going to say I want content to expire after one year. It's going to set a header that will inform clients that the content should be considered expired after one year.

Next, access to assets can really clog up our logs. And so if you're going to request a bunch of images in CSS and JSS or JavaScript, I'm going to go ahead and turn off logging for those things. So we can tell nginx to just quiet the logs for anything in the assets path.

And finally, I'm going to add a custom header. And the header key is going to be called cache control. And its value will be public. This tells CDNs that it should be OK to cache this content, that it can be publicly cashed for up to one year. And then after that, we got to come back here and grab the latest version.

To grab those latest changes, we'll reload nginx inside of the virtual machine and make sure that it loads correctly. In this case, we're getting an error. It's telling us that it was unable to restart or reload nginx.

So what we need to do is to check the system control status of nginx. And it should tell us why it failed. Notice down at the bottom, if you look through the logs, it gives us an error message, expires. It says that the directive has an invalid value. So let's go back and take a look at the config file and see what we put there.

Sure enough on line 77, it's not year RY it's just Y. And so there's just a syntax error. I'm glad that happened because it gives you a chance to see what to do if you run into an error like that. Just check the logs and see what it's telling you.

OK. Let's try restarting this again. This time it appears to be good. But we can double check by checking the status of nginx. It looks like it's active. And now inside of the project, let's go ahead and add an Assets folder.

Normally, this would happen for you automatically during a build process. But we'll just add it ourselves now to simulate. And I'll put a file in there called build.css. You could imagine that this is a CSS file they gets built for us automatically during some build process.

Obviously, it's not minified or doing any of the things that a build process would do. But it'll give us a chance to see whether things are working. Now since I've made a change to the project, I need to get the latest changes up to the deployment server. So I'll add these files and folders, commit the result, and get pushed to ploy a master. That'll send out the latest to our deployment server.

Now that we've got that assets folder deployed, we should be able to CURL with the inspect flag and or the inspect headers flag and the follow redirects. And we're going to look for boom.com. And we're going to look for the assets path. And let's grab the build.css file.

Great. It looks like it's working properly. We get back the CSS file that we just wrote correctly. And notice there's a couple extra headers here. One is the expires header. This is the one we set with the one year that we fixed at the end there. And notice that it says to the client that it should expire this content one year from now.

Then there's two cache control headers, the max age for one year and the cache control public. So this is going to be the one that tells our CDN that it can go ahead and cache this content if it wants for up to one year and then come back and grab the original version from this server. nginx is able to treat this path specially by using the location directive.

One little tricky part here is notice that in order to find this file, it still went into the root area, the root area that we designated with the root directive, and that was under the Public folder. And then it appends this path to that root area in order to find the file that needs to be returned. But when we're specifying the location, we just give it the assets path.

And from that it's able to say anything that requests that path, go ahead and treat it specially. And in this case, we added a couple extra headers to it. And then nginx went into the Public Assets folder to find the actual file.