As mentioned in the previous article, one of the requirements of using PHP on a page is that it must be on a server in order to work. This often confuses web developers who are only familiar with HTML and CSS: until this point, they have been able to store and view their web pages on almost any digital device. That is not true of pages that feature PHP.
In order to understand why, we need to look at the very basics of the internet. In particular, we must define two terms:
A client is, for our purposes, a device, or some software, that requests a resource on the internet. The client is often, but not exclusively, a web browser running on a computer. Other possible clients include internet-accessing software running on other devices such as smartphones, eMail programs, games, etc.
A server is software or a device that provides services in response to requests from clients. The possible services are many and varied:
- Print servers forward documents from clients on a network to appropriate printers, controlling printer queues and priorities.
- Game servers provide a single location for game clients to form teams, and communicate the moves, current positions, actions, and scores of players.
- File servers store files in a centralized location so that everyone in an organization has equal access to resources.
- Web servers store web pages and associated files (such as images), and provide those resources in response to client requests.
Servers are often specialized machines. If they consider them at all, most people probably think of servers as giant humming computers with blinking lights in a vast, cavern-like room. The reality is that almost any device with a processor can be turned into a server: what makes them special is the software, not the nature of the physical hardware that the server runs on. Obviously, computers with more memory, hard drive space, and processors tend to make better servers, as most are expected to respond to simultaneous requests from dozens to thousands of clients.
So in the traditional client-server model, a request for a web page could be shown as something like what you see at the top of this article.
A good analogy for the client-server relationship is that of a well-to-do Victorian household in the late 19th century. You, a London gentleman or woman, reside in the upper story of your home. The “help” – the servants and cooks – live downstairs. Being a very proper class-conscious Victorian, you don’t ever wish to be seen by the staff. Instead, all interaction with the help downstairs is made via a dumbwaiter: a small goods elevator in the wall that travels up and down between the floors. When you are hungry, you write requests for food on little slips of paper, sending them down in the dumbwaiter. The hired help reads the note, places food in the dumbwaiter, and sends it back upstairs to fulfill your request.
At the beginning of this arrangement, you have very primitive level of communication with your staff. If you ask for potatoes, the servants will simply put potatoes in the dumbwaiter and send them up to you – it’s up to you to do the peeling, mashing, and cooking. This means that your staff can respond very quickly to requests, but it places a good portion of the work of actually making food on you.
As a basic request-response system, this works well. If you want more work done by your help staff (you send a request down for potatoes, and your cooks prepare potatoes au gratin in just the way you like) then the server must do more work. This means you (the client) gain prepared meals, but at the expense of working your servants harder. Obviously, if you have a dinner party, during which all of your guests order special meals, then your serving staff will have to work even harder. Too many requests and deliveries flying up and down the dumbwaiter run the risk of slowing down service.
In our case, why would you want to place more work on the server? Typically, server-side languages are used to create dynamic web pages: features on the page that alter under certain conditions. HTML (and to a certain degree, CSS) are stateless: they have no comprehension of the passing of time or (broadly speaking) the actions of a user on a web page. Some scenarios for using a server-side language such as PHP might include:
You want to place today’s date on your page, to make it appear current.
You want the user to select an option from a drop-down menu, and show them different pictures based on their choice.
You want to alter the appearance of the site based on seasonal changes, or the time of day.
Combing both server-side and client-side processing, our diagram becomes:
There are some other important reasons to use server-side technologies:
- So long as the server is running and not overloaded with requests, server-side technologies always work. You don’t have to worry about browser type, available plugins, or platform: the server always remains the same, and PHP code always works.
- Server-side code is inherently more secure than client-side, as the client never sees the server code, just as our Victorian gentleman never saw his servants: the server works to fulfill a client request, and sends the completed order. The client never sees the actual process of chopping, cooking, etc.
Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.