Web Servers, Web Apps, and More


Sometimes it’s easy to over-complicate things. One such over-complicated topic is web servers / web apps.

What are webapps?

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.

Your browser, or whatever you’re reading this article on, takes that bunch of HTML, CSS, and/or JavaScript and renders (i.e., translates) it into the format you currently see.

Simple Web Server Example

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.

1
2
3
4
5
6
<!DOCTYPE html>
<html>
<body>
Hello World!
</body>
</html>
Above code turns into this in your web browser

This is bare bones. HTML is a markup language — it only shows info or data. If you want to make things look pretty or have fancy animations, you introduce CSS and JavaScript, which we will not cover in this article.

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.

1
2
3
4
5
6
7
8
<!DOCTYPE html>
<html>
<body>
About page!!
<br/>
<a href="index.html">To Home Page</a>
</body>
</html>

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.

Different path requested = different data

This is a concept called routing, which is delivering different information / files based on requests to different paths (i.e., URLs).

Great. How do I show the world my new website?

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:

  1. You enter a URL in your browser.
  2. Your request goes to a DNS server, which looks up the IP address for that URL (also called a hostname).
  3. Your request is redirected to that IP address, where a server (computer) has some kind of web server app running (Apache in this case).
  4. The app services the request, and based on its configuration, maps the request to a resource / file on your file system.
  5. 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.

Quick note on terminology

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.

Adding Capability and Complexity

Source: janjf93 (Pixabay)

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.

Installing Prerequisites

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:

  • Python3
  • Pip3
  • Pipenv

Python Flask Application

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.

1
2
3
4
5
6
7
8
9
$ pipenv shell
(python-flask-hello) $ export FLASK_APP=app.py
(python-flask-hello) $ flask run
* Serving Flask app "app.py"
* Environment: production
WARNING: Do not use the development server in a production environment.
Use a production WSGI server instead.
* Debug mode: off
* Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)

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.

Our First Route

Let’s revisit the above scenario again, but this time using a web application. Here is our complete app.py Flask app:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
from flask import Flask
from flask import redirect
from flask import request
app = Flask(__name__)

# Basic Route
@app.route("/")
def hello():
return "Hello World!"

# Different Route
@app.route("/test")
def test():
return "Test different route"

# Route with parameter in route
# Variable must be passed to method
@app.route("/test/<param>")
def param_test(param):
return "Received: {}".format(param)

# Route with parameters passed as args
# Example: /test/args?name=<name>&age=<age>
@app.route("/test/args")
def arg_test():
name = request.args.get('name')
age = request.args.get('age')
return "Name is {}\nAge is {}".format(name, age)

# Route with HTTP method constraints
@app.route("/methods", methods=['GET', 'POST'])
def default():
if request.method == 'POST':
return "Received POST Request"
else:
return "Received GET Request"

# Route with type constraint on parameter
@app.route("/test/square/<int:param>")
def int_test(param):
return "Square of {} is {}".format(param, param * param)

# Route to three amigos
@app.route("/three-amigos")
def three_amigos():
return redirect("https://www.denverpost.com/2013/09/04/broncos-original-three-amigos-ride-again-living-on-in-nfl-history/", code = 302)

This might look like an intimidating wall of text, but let’s take it one section at a time.

1
2
3
4
from flask import Flask
from flask import redirect
from flask import request
app = Flask(__name__)

In the first few lines above, we are simply including libraries we need and creating a Flask object called app:

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!”:

1
2
3
4
# Basic Route
@app.route("/")
def hello():
return "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.

You’d also have templates to render HTML and deliver CSS and JavaScript so ] you have a nice, pretty webpage. But that’s another topic for another day.

Add a Route

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.

1
2
3
4
# Different Route
@app.route("/test")
def test():
return "Test different route"

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.

Passing Parameters

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.

1
2
3
4
5
# Route with parameter in route
# Variable must be passed to method
@app.route("/test/<param>")
def param_test(param):
return "Received: {}".format(param)

The above code results in this:

Taking parameters from the URL and doing something with them

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!

The “parameter” to request Static Void’s YouTube channel is this massive, colossal mess of letters

What happens from here?

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.