Web Servers, Web Apps, and More
Sometimes it’s easy to over-complicate things. One such over-complicated topic is web servers / web apps.
At their core, web servers and web apps are just applications that allow people to see files or data. This article you’re reading is information being retrieved and from a server (computer) somewhere, in this case, an AWS S3 bucket.
Let’s do a simple example. Copy and paste the below contents into an
index.html file, and then you can open it and immediately see it in your web browser.
You didn’t need to do anything extra here to view it in your browser because your browser can just read
index.html on your file system. In this case, your file system itself acts as a “simple web server.” To serve a file merely means to make it available to read.
Now, let’s add another page to your website (i.e., more data). Copy and paste the contents below into a new file called
about.html in the same folder.
You’ll see here that we’ve added an additional link pointing back to the index page. By clicking on “To Home Page”, you are directed back to the
index.html page we had created before. Notice the URL in your web browser changes with the page.
This is a concept called routing, which is delivering different information / files based on requests to different paths (i.e., URLs).
In order for people on the Internet to see your website, you will need to allow them controlled read access to your file system. You could browse your own file while screensharing via Google Hangouts. But that’d be pretty dumb.
So that’s where different web server apps like IIS, Apache, NGINX, etc., come in. When you run an Apache daemon (background app), it can actually connect your web port(s) (default 80 / 443) to a specific folder in your file system.
Then, when a user requests your website, they are pointed straight to a directory on your server based on your config, and they will get the
index.html file (there’s some nuance here, but don’t worry about it for now).
Here’s a quick overview of what happens when you request a website:
- You enter a URL in your browser.
- Your request goes to a DNS server, which looks up the IP address for that URL (also called a hostname).
- Your request is redirected to that IP address, where a server (computer) has some kind of web server app running (Apache in this case).
- The app services the request, and based on its configuration, maps the request to a resource / file on your file system.
- The server sends the information requested as a response back to the user.
This is very high-level and greatly oversimplified, but this is all you really need to know for now. What you’re seeing is the pure, distilled essence of the Internet — you’re just viewing data and files from other computers.
Remember that a “server” is just a computer. However, a “web server” is a computer specifically for the purposes of serving web content.
Even more confusing, you will find that in industry, the term “web server” is typically used interchangeably to refer to both the software (i.e., program on the computer like Apache or your application) or the hardware (the whole computer itself). This is because usually, you only want servers dedicated to specific tasks, which in this case, is serving a website or web app.
Software engineering isn’t exactly known for its lack of random jargon.
For some people, hard-coded static pages are enough to display the information they want (i.e., online profile / résumé). But what if you want to display dynamic data or process information?
That’s where web applications come in. Think Netflix, Amazon, Facebook, Twitter, Medium — these are websites whose content are changing everyday.
It would likely be impossible to code all of these things as just static files because literally everything is changing every second. So how does this work?
Well, rather than reading information on a file, you are reading information returned by an application.
This is powerful, because now we’re not limited to what we’ve pre-written to a file somewhere — we can generate content dynamically according to logic. Let’s observe this through a demo.
We have a companion repository for this article. Follow the README in the repository to set up the following prerequisites.
In short, you’re going to need these things installed:
Flask is a lightweight Python web framework for creating a web server. Some other frameworks you may have heard of include:
…and like, dozens of others. There are plenty of different frameworks to choose from, in plenty of languages, each with their own advantages and disadvantages. The ones I listed above are just frameworks we have personally seen and worked with.
If you’ve already cloned the repository and followed the README, then let’s go ahead and start our web app.
You’ll notice a bunch of output. It’s basically just telling you what it’s doing. The website is configured to run on port 5000 on your local computer by default. So visit http://127.0.0.1:5000/ to see your web app.
Let’s revisit the above scenario again, but this time using a web application. Here is our complete
app.py Flask app:
This might look like an intimidating wall of text, but let’s take it one section at a time.
In the first few lines above, we are simply including libraries we need and creating a Flask object called
If you aren’t familiar with Object-Oriented Programming (OOP), we’ll be creating a post in the future about it which we will link here. Stay tuned! Sorry about all of the “we’ll explain it later” portions. Programming is complicated. There are lots of prerequisites and assumptions.
The juicy stuff comes on line 6. Here, we are creating our first route. You’ll notice that it’s the web app equivalent of what we created above with the static index.html page (without the HTML). So if you visit your link to port 5000 above, you should see “Hello World!”:
What we’re basically defining here is when visitors visit the “root” or “home” of our website, our app should execute the following function. In this case, the function is
hello() and all it does is return “Hello World!”.
The root of a website will typically be its URL. For example, if you visit https://medium.com, you will go to Medium’s root page. Do you notice how each time you visit Medium, the posts on the front page are different?
This is the concept behind a web application. They’re not literally writing out a different
index.html file for each time someone visits — they’re dynamically fetching different articles based on what’s popular, what’s recently posted, and what things you’re interested in.
Our “Hello World” example is simple and largely useless. But the potential behind it is powerful. In a real web application, you’d replace that “Hello World!” with dozens, hundreds, thousands of lines of code performing complex logic to retrieve information dynamically.
The next section is just adding a route. Here, we’re adding a new function, which does something different and is executed when a different route is requested.
This is the web app equivalent of adding a new page to our static website above. Try going to http://127.0.0.1:5000/test. You should see “Test different route” now.
Make sense? Different request = different data. This time, instead of reading things from files, an application is checking what you’re requesting and changing what it’s sending.
Here’s another small taste of the “dynamism” of web apps. Go to our publication at: https://medium.com/static-void-academy. You’ll get our articles and our publication. Notice how the name of our publication is at the end of the URL.
If you were to modify that URL to be: https://medium.com/google-cloud, you would no longer see our publication, but Google Cloud’s publication and their stories/posts. In this case, the name of the publication in the URL is a parameter (i.e., changing argument), and it changes the data you receive.
The reason you know this is dynamic content and not static files is because the content is constantly changing. If you go to our publication next week, you’ll see another article. If you periodically visit Google Cloud’s publication, you’ll see different articles. This data is fetched dynamically.
Our example route will take a parameter and merely tell you that it received that parameter. Again, not all that useful — but the point is demonstrated. You can supply it anything you want, and it will be able to differentiate and adjust.
The above code results in this:
Now, with these parameters, you can fetch data from databases or stream files from servers, etc. Next time you’re on YouTube, keep an eye out on the URL and check out how changing that URL changes the content you receive!
We could spend the rest of the article going through the rest of the example routes, but we’ll leave that as an exercise for you. Feel free to experiment with the code and modify it.
This is a very limited, high-level view of what web sites, web servers, and web applications are and what they do. The end concept is the same —they deliver data in response to a request over the Internet (i.e., Web).
Some good next steps would be to get in-depth with web applications and learn how to build them for various things. Or, if you don’t have your basic programming down, dive into a specific language and fill your toolbox for software engineering.
Here are some additional resources for learning:
Good luck and happy learning! If you have any questions or concerns, please comment on this article as well as on the YouTube video. We make it a point to be as responsive as possible.