Part 1 – Development Environment Components

September 22, 2024

Before we get started, it is important that we understand each of the pieces we need to include in our local development environment:

DNS records in our hosts file
An HTTP server
A server-side scripting language
A database server

It’s easiest to understand these components when we walk through how they each get used. To do that, let’s walk through what happens when a user visits a hypothetical website, www.example.com/soup.

Step 1: Request Created

Illustration of a request being created

When you want to visit a website, you use a browser to go to a web address. The browser creates a request. A request has many components and we don’t need to get deeply into the details. We just need to know about two specific parts of the request.

First, a request includes the Host header, which indicates the host name (in this case, www.example.com). Secondly, a request includes the uniform resource identifier, or URI, which indicates the resource you want to access (in this case, /soup).

We’ll be coming back to both of these in future sections.

Step 2: Host Lookup

Illustration of DNS lookup

At this point, the request has been created but there is an additional step that needs to happen before the request goes out.

The internet uses IP addresses to direct requests to their destination, not domain names. That means that before a request can be sent, your browser needs the IP address where it should go. This happens through a process called DNS lookup.

We talked about how the request contains a Host header, which indicates the host name of the site you want to access. During DNS lookup, several locations are checked to see if they have a record for what IP address matches that host name. DNS lookup ends when a match is found.

The first location to be checked is the hosts file, which is a standard file on your PC. The hosts file manually sets an IP address to be used for a particular host name, and it trumps any other records. This will allow us to point our local domain names to our server later in the project.

Once the client has translated the domain name into an IP address, it can send the request to a server.

Step 3: HTTP Server

Illustration of request being sent to HTTP server

A server is simply something that provides a service. A server that can receive HTTP requests and respond to them is called an HTTP server. An HTTP server doesn’t really know anything about the files it’s sending back. It is simply a conduit to receive requests and send back information.

It is possible to simply make a webpage with static HTML files that don’t change unless you edit them yourself. However, most websites don’t work that way today.

Suppose you were hosting a recipe website. If you wanted to use static HTML files, you would have to write every recipe as its own HTML document, save that to your server, and add links to it on every page that needed to point to that recipe. That’s possible but quite tedious, so we will want a few more components to help us create the files our HTTP server is sending back.

Step 4: Server-Side Scripting

Illustration of a server checking its configuration and passing a request to a server-side script

An HTTP server can be set up to take additional actions when it receives a request. For example, it can reject any requests that come from a blacklisted IP address. However, it’s very common to have an HTTP server run a script when it receives a request. Because these scripts run on your server, they’re called ‘server-side scripts’.

Server-side scripts are often used to generate dynamic web pages. Let’s go back to our example of a recipe website. As we mentioned, it would be tedious to create a separate HTML file for every recipe, when only the title, ingredients, and instructions are going to change.

Instead, we can use a server-side scripting language to create an HTML template with some placeholders. When the user requests a particular recipe, our server-side script will fetch the information related to that recipe, put it in the template, and send the finished file back to the HTTP server.

This still leaves a problem, however. Where is that data coming from?

Step 5: Database

Illustration of a script requesting data from a database

A database server stores data in a structured form and responds to requests for that data (called queries). For example, in our recipe website, the database might store the name, ingredients, and directions for each recipe.

Our server-side scripting language can request information from the database, insert it into a template, and return the finished file to the HTTP server to be sent back to the client (the user’s browser).

Step 6: Response

Illustration of a response being sent to the browser

Let’s recap the steps so far.

The user visited a website on their browser. When the user does that, the browser becomes the client. The client looked up the IP address for the website the user wants to visit. It sent a request to the HTTP server at that IP address.

When the HTTP server got the request, it checked its configuration and found that it needed to run a script. It handed the request to the script. The script called some data from the database and used it to fill in a template. Filling in that template produced a finished HTML file, which is passed back to the HTTP server.

Now that all the steps have been completed, the HTTP server can send a response back to the client, and the user will see the webpage.

Conclusion

That’s it for this section! In the next section, we’ll installing and running Apache as our HTTP server.