From the course: Linux for PHP Developers

The lifecycle of a request

From the course: Linux for PHP Developers

Start my 1-month free trial

The lifecycle of a request

- [Instructor] One of the job interview questions I've both received and given is what happens when you type a URL into a browser and press Enter? The answer can get pretty long and is intentionally open-ended. The point of this type of question is not to trap or confuse. It's to determine if the candidate has a broad understanding of how the web works. A high level perspective provides context for architectural decisions, troubleshooting and delegation responsibility. Let's start with the abstract for just a moment, then I'll relate the abstract with concrete examples to give relatable context. A client-server model is a distributed computer application structure with two main roles, client and server. The client requests data from a centralized resource, known as a server. The server then responds with the requested data. The World Wide Web as we know it is built with a client-server architecture, where a client requests data sent over hypertext transfer protocol or HTTP. A client makes a request for an HTML document from the server over HTTP, who builds a response to fulfill the request and sends it back to the client for presentation. It's a roundtrip that happens over and over again. A client makes a request from a server and the server sends a response. Then, the response is rendered by the client. Then the client makes another request. The server sends another response and so forth. That's really abstract, so let's take a closer look at the individual pieces. A HTTP client makes the request for data to a server, but what exactly is it? You are almost certainly using one now. The vast majority of the time, HTTP clients are web browsers with common examples of Mozilla Firefox, Google Chrome or Microsoft Internet Explorer. A browser is way more relatable than an HTTP client. Browsers make requests from a web server. A web server is a program that uses HTTP to serve files that make up a webpage, including HTML documents, images, stylesheets and so forth. There are a number of different web servers. The most common is Apache and NGINX is also becoming increasingly popular. We'll compare these two later in the chapter. Once the request is received by the web server, it decides how to handle it. There are two types of response. The first is static, which doesn't need to be generated and already exists. Static responses typically consist of files that already exist such as images, stylesheets or even HTML documents. If the web server finds the asset, it just sends it back, job complete. The other type of response is dynamic, which needs to be created on the fly. Dynamic responses are where the real fun is. A dynamic response is generated using an interpreter that executes scripts written in languages like PHP, Ruby, Node.js and others. With an interpreter like PHP, the dynamic response can be created completely independently of any other service. Here's a full HTML hello world. If we made a request directly to that file through the web server, we get a W3C valid HTML5 document, not particularly interesting, but valid. It's not really practical to store content in code, so it's more typical to use a database server for storing persistent data. Persistent data is information that doesn't change often like the text of a blog post. Database servers provide an interface for organized collections of data. PHP or another interpreter can connect the database server in order to store and retrieve data. PHP then uses the contents of the database to build the response such as rendering a blog post. A popular database management system or DBMS is MySQL. We'll explore MySQL and some other alternatives later on as well. With this context, let's reexamine the lifecycle of request, starting with a static request. A browsers sends a request for an image from a web server over HTTP and the web server finds the file and sends it back, also over HTTP, pretty straightforward. A dynamic browser has some more steps, but at a high level, it's pretty similar. A browser like Firefox sends a request for a page from a web server like Apache. Based on a rule like the name of the script, the PHP server gives the context to the request of the interpreter such as PHP. If necessary, PHP connects to the database like MySQL to get or set the data as requested. PHP then assembles the response and gives it back to the web server, which finally sends the response back to the client. The end user never actually directly accesses the database in this model. All requests go through PHP. To review, the components of the lifecycle of a web request are HTTP clients or browser, web server such as Apache, interpreter such as PHP and a database server such as MySQL. I don't think we need to worry about the web browser, but where should we be setting up the server components?

Contents