Ever wonder what it takes to deliver a website to the world? There are quite a few components required, some of which overlap and even share names. It can make for some confusing discussions and lead to misunderstandings. In this post, I’ll explain how the pieces fit together.
The Language of Browsers
The browser gets to a website through a URL (uniform resource locator) which is made up of words… like google.com or kmde.us. Those words only mean something if they can be translated into an IP (internet protocol) address (like 188.8.131.52). When you type a URL into your browser, a Domain Name Server looks up the URL and, if a valid IP address is returned, your browser’s request gets passed along to that IP address.
Webservers and Webservers
IP addresses normally point to servers, and most of those servers are computers (usually virtual these days) running the Linux operating systems. Sometimes these servers are called web servers because that’s their job. But these servers need to run another piece of software (which is also sometimes called “web server”) that listens for requests. The most popular products in this category are Apache and Nginx.
Quick recap: a server (a physical or virtual computer) running an operating system (usually Linux) has Apache or Nginx installed on it and configured to listen for web requests. That’s a web server.
Inside of the public folder of Apache or Nginx, you could put a simple HTML file and you’d have a website (a terribly boring and static website, but a website nonetheless). Take for instance this example from W3Schools:
<!DOCTYPE html> <html> <body> <h1>My First Heading</h1> <p>My first paragraph.</p> </body> </html>
That would work, and technically it would constitute a website. (I wouldn’t expect a lot of traffic, but who knows… anything can happen.) Back when I started making websites, that’s pretty much all there was! These days, however, we need a little more.
A “stack” is group of software products that facilitate the development and deployment of sites or applications. At KMDE, we work mostly with LAMP or LEMP. The “L” is for the aforementioned Linux, the “A” for Apache, and the “E” for Nginx (because it’s pronounced “engine x”).
The “P” is for PHP, a language that runs on servers and is generally used to produce HTML. About 80% of all websites run with PHP, and although it’s trendy for developers to hate, New Kids on the Block were once trendy too. PHP went through some ugly years, but these days it’s fast, stable, and the learning curve isn’t insane.
When the request that started with a URL in your browser makes it to a webserver running PHP, instead of a static HTML page (like the one shown above) getting returned, PHP executes and, based on the incoming request, dynamically produces the HTML that gets sent back to your browser. That’s a big part of how websites became interactive… you get a page sent to you, you put some information into it and send it back, and PHP reads what you sent and sends you something else.
This whole process gets even more powerful if the web server has a place to store (and subsequently retrieve) information. The “M” in our stack is MySQL (or MariaDB), a relational database engine. PHP stores information in MySQL/MariaDB and fetches it as needed.
So for example if you type a word into a search box on a web page and click “search,” that word gets received by the web server and picked up by PHP. PHP can use that word to search a database like MySQL/MariaDB and then build a new HTML page from the results, which it can then send back to your browser.
Are we there yet?
Why yes, we are. At a very high-level, we’ve covered the pieces required for you to be able to type an address (or click a link) in a browser and end up with a response. From small sites like ours to Amazon or Facebook, the principle is the same.
Hopefully this brings a bit of clarity to the big picture for those who may have been curious.