At my first full-time Web development job, we deployed our code by typing a command into our chat client. Thirty seconds later, the site was updated with our changes. It was great — I could think exclusively about application code, which was everything I should have been thinking about as a self-taught dev working on my first large-scale application.

One day, I asked our infrastructure specialist to explain what happened when someone visited our site. How was it that our code actually ran when someone hit our servers? The next two hours were revelatory, but promptly forgotten. A few years later, staring down a 504 error from something called NGINX, I wished I had taken better notes.

To that end, I am writing up a junior developer’s guide that demystifies what happens when a server — outfitted with a fairly standard NGINX/Unicorn/Rails stack — fields a Web request. It’ll be in four parts:

1. A top-level overview (which follows this introduction); 2. How to set up a server on your local machine (so that you can simulate what happens on a production Web server without paying someone to host it); 3. How NGINX handles incoming Web requests; and 4. What Unicorn does.

### A top-level overview of how some servers handle Web requests

In the words of Sunlight alum [Eric Mill](https://twitter.com/konklone), a server is just a computer without a monitor (and, who knows, it might even have a monitor!). When this computer’s job is serving a website to Web browsers, it needs to know how to respond to HTTP requests, since that’s how browsers typically communicate. Hence, the first stop for visitors’ Web requests to your server will typically be software designed to accept HTTP requests and pass them off to a program that contains more logic about what to do next. One popular program for this is [NGINX](http://nginx.org/en/). NGINX’s most salient feature for this guide is its ability to hand off Web requests to another HTTP server.

If NGINX is configured to do so, it will pass the Web requests to software that manages and queues them. This program acts as the glue between the public-facing Web server and your Web application; a common one is [Unicorn](http://unicorn.bogomips.org/), which makes fielding multiple, concurrent Web requests go a lot more smoothly. If your company or organization has a `unicorn.rb` file in its Rails app, this file provides settings for this piece of software. While the reason for programs like Unicorn might not be obvious, consider the case in which 20 people visit a particular website simultaneously. If you know that your server can only fulfill (that is, run the code that generates the HTML body of your Web server’s response) eight Web requests at a time, it is very helpful to have a program regulating access to your application code.

Once Unicorn (or a program like it) has a Web request, it intelligently hands that request off to the actual Web application. This is when the code that you write and deploy _actually gets run_.

### 3 truths about Web servers I wish I had understood sooner

In the interest of clarifying the above top-level overview, here are three things about Web development I wish I had understood sooner:

1. Your Web app is a computer program (or a few of them) that relies on other computer programs; 2. Your server is a computer where that computer program runs sometimes; and 3. When someone visits your application’s URL, programs on your server (some of them outside of your Web application) are responsible for making your Web application run in response to that Web request.

The next installment of this “System administration for junior devs” series, in which I write about how to set up a virtual server on your development laptop, is available [here](http://sunlightfoundation.com/blog/2015/05/12/system-administration-for-junior-devs-setting-up-a-virtual-server-with-vagrant).