Jake Pruitt

This is where I write.

← Home

HTTPster

One of my favorite movies is The Usual Suspects, which is about a murder mystery surrounding a mysterious figure named Keyser Söze (SPOILER ALERT: I may give away some clues about the movie in this article. You’ve been warned). At one minor point in the film, a half-dead Turkish man lying in the hospital says that he saw Keyser Söze, and they bring in a forensic sketch artist to draw the face based off of his description. I found this scene to be one of the most interesting scenes in the movie, since the forensic sketch artist had to translate a poor description of a man in Turkish into a highly detailed drawing.

I saw this around the same time that I was struggling to learn how the Internet really worked. I loosely threw around words like “client-side” and “server-side” without really knowing what they meant. Once I saw this part of The Usual Suspects, everything seemed to make sense. The analogy of a forensic sketch artist and a dying Turkish witness seemed to work really well for the relationship between the browser and servers.

The Turkish witness and the forensic sketch artist

To help explain the ideas of clients and servers working over the Internet, let’s imagine a Turkish witness named Serge talking to a forensic sketch artist named Clementine. Clementine asks Serge to describe a person, and Serge responds with a Turkish description of the person, which Clementine translates into an image of that person.

In the world of the web, Clementine is your browser, like Mozilla Firefox or Google Chrome, sometimes called the “client” or “front-end”. The client is responsible for requesting web pages, and translating the response into a human-readable web page. Without Clementine, we would have a very hard time asking Serge to describe the person, since his response would be totally in Turkish. It is possible to request web pages without a browser, and receive a response, but the response would be all in HTML and not mean much to us. Brian J Brennan seems to be cool with it though:

Serge, the Turkish witness of the man you want to identify, is the server, or the “back-end”. He recalls his memory of seeing the man, and tries putting that memory into words that accurately describe things like the shape of his eyes or his hairline. In the web world, the server is responsible for taking incoming requests, looking up appropriate files in the file system, and sending back all of the HTML files and CSS and JavaScript and images that the browser needs to render the page.

This request-response model is the way that pretty much all things on the web work. The protocol for requests and responses is known as HyperText Transfer Protocol, or HTTP. HTTP is the glue that connects servers to clients. It uses URL’s to locate specific servers and ask for specific information. Did you ever notice that every URL starts with http://? HTTP is also responsible for carrying the response to the browser, whether that’s the successful response of the HTML page, or a 404 error, which you may have seen before. 404 stands for the code HTTP uses to say “Resource not found”. This would be like asking Serge to identify someone he could not remember. The typical code for “Success” is 200, which would mean Serge remembers the person and can describe him.

BONUS: Deep dive into the dynamic web

So this model works when thinking about things like my blog, javascriptjake.com, which are just static sites. By “static”, I mean the server is just a computer with a file located at /2014/12/02/httpster.html that it sends to the client whenever it’s asked.

My site can work this way because it is not very complicated, just a few HTML files that I wrote sitting somewhere in the cloud at the address http://javascriptjake.com. Things get very complicated with dynamic sites like Facebook, where every page is created by the server based on a database of information that is constantly changing. Facebook has to use server-side code, mostly in PHP, to find this information, combine it with HTML templates, and send back to the client as static HTML, CSS and JavaScript. On top of that, Facebook takes care of authentication, keeps track of who your friends are, allows you to chat with friends, and performs analytics on the information that you would find most interesting. This is not just like Serge describing a rough sketch of a person to Clementine. It’s more like Serge giving the full description needed for Clementine to create a 3d animated model of the culprit, with accurate voice capabilities.

There are tons of different languages that perform these actions on the server, including Java, PHP, Python, C#, Ruby, and even JavaScript in the form of Node.js. If you want to learn more about these languages and how they do the heavy-duty back end code, check out my earlier blog post where I compare them to real languages.

There are many sites that are greatly dynamic, with logins and database interactions, that perform all of these actions entirely on the client side. The server is only responsible for sending over the minimal HTML files, and then the JavaScript performs all of the dynamic interactions in the browser. This would be like Clementine having special paper that would take the sketch and turn it into a full 3d model in small matter of time. Modern browsers are pretty close to doing a lot of cool things with JavaScript that could only be done on the server before. However, not everyone has ultra-modern browsers, so rich client-side applications, like gmail.com, are very dependent upon what browser people use and the amount of latency/bandwidth they have. If you’re interested in reading more about client-side application frameworks, check out my earlier post comparing them to shoes.

If you’re still very curious about how things work in the browser in terms of taking HTML and JavaScript and turning it into a web page, check out What the heck is the event loop anyway? and Pixels are expensive, which are two of my favorite talks on how browsers do their magic.

In terms of server-side magic, the first server I ever created was a Node.js server that I learned from reading the Node Beginner Book. Node is nice for learning some server side things for the first time because you actually have to create the HTTP server and handle the requests and responses manually. If you are more of a Python guy, or just want to start a server from a directory on your computer, check out this short article on getting that started.

What kind of metaphors do you use to understand the Internet? Would you say it’s more like a kitchen or the post office? Let me know in the comments below!