Have you ever wondered what makes a website tick? Did you imagine how it works at a grander scheme and why this seems so complicated? The short answer would be “because it is” but we’re committed to delivering an inside look on how web-enabled software works. Last time we spoke about concepts. Now let’s take a deeper dive and see what stands behind those fancy terms we spoke about.
Web-enabled software would not exist without the internet (duh: you can’t spell “web-enabled” without “web”). There are 4 main layers you should perceive: the Application layer (nickname “the Operator”), the Transport layer (or “your dial-tone phone and all phone stations you can imagine”) and the Internet and Link layer (or “the copper wiring that connects you to other local stations and phones”). The latter two are combined as one for the example’s sake, leaving us 3 conceptual entities that enable your app.
In other words, every time you do something on the internet, you’re asking an operator to dial a location. You reach that location through the good-old copper-wired equipment that enables that dial tone (or your internet connection) and only if someone picks up, you can initiate the conversation. Explaining how the entire internet works would take a book (by the way, this one is a pretty good start) so instead, we’re going to focus on the most relevant aspects that enable a web application: “the operator”. More specifically we’ll speak about the Hypertext Transfer Protocol (aka HTTP).
Invented in 1991 by Tim Burners Lee, HTTP became an internet standard that enables access to any web application there is. In essence, HTTP is a set of rules and standards that allow sharing collaborative, distributive and dynamic media across “the internet”. To align it with the previous analogy we’ve set, imagine that HTTP is the phone operator that recognizes the number you’re eager to reach, dials it and then makes sure you can exchange voice messages via equipment and copper wiring.
The protocol achieves this by exchanging, serving, storing and updating hypertext documents (basically any web page and its content: links, media and other info) written in a Hypertext Markup Language or HTML (we’ll get to this one a bit later).
It does this by acting as a request-response mechanism between the client, the server and the data layers (the “holy trinity” of any app). To initiate a query, the client sends an HTTP request to a specific server. If the query is successful, the server returns a response message, stats and requested content, served as an HTML document. Otherwise, if the server is not available or experiences issues, an error code is displayed as a regular view in your web browser: “HTTP/1.1 500 Internal Server Error”. There are various error codes that give you an idea of what and where a request failed. For instance, any error that resembles a 5xx code is related to the web server while 4xx error codes are related to issues triggered by your computer’s configuration or a bad request. Going back to our classic phone analogy, any 4xx error code could be interpreted as: ”the phone number you have dialed does not exist”; while any 5xx error would be associated with “the number you’re trying to reach is not responding”.
Of course, depending on the client’s request (placing a comment, attaching and sending a file, performing and recording various operations) the client makes use of a various set of request methods (such as head, post, put, delete, trace, options, connect or patch). These methods enable any website and can be considered as “the operators” machinery that keeps the web flows at pace.
Those requests aren’t the only dial board “an operator” can use. In addition to them, there are extensions such as the Hypertext Transfer Protocol Secure (HTTPS). This protocol is a standard set of rules and procedures designed to keep the client-server communication private via cryptographic means. In essence, HTTPS encrypts any request or response before sending it and decrypts it when it’s received (regardless of the recipient).
Of course, HTTP alone could not enable a web application. For it to be useful, it needs to send messages that can be interpreted by the client and here we’re getting to that Hypertext Markup Language story.
To keep it short, the same guy who invented the HTTP and its extensions had to design a language that your phone’s or your computer’s web browser can understand. He did not have to look too far though.
While at CERN, Tim Burners Lee was already familiar with a document markup language called SGML (or Standard Generalized Markup Language) that was used to define and structure documentation. Inspired by SGML, Mr Burners Lee developed the Hypertext Markup Language (further as HTML) as the main content interpretation language for its first web browser.
Assisted by Cascading Style Sheets (further as CSS – which is a set of representation rules defined for HTML) the markup language delivers your browser the ability to display any content (text, images, documents and/or media files) in a variety of usable formats.
For instance: when a page is served to your web browser by the HTTP protocol, the browser itself renders the webpage according to a page view CSS. However, when you decide to print-out that page, the CSS renders a printing view of the same page, which might represent a simplified version designed for printing or an entirely new print-oriented structure.
To put it simply, the web browser is a canvas, HTML is the vase, fruits and background that needs to be painted/rendered/projected on that canvas, while CSS is all the paint, brushes and talent owned by an artist. The painting process here is called rendering, while the end-result is the web-view you’re browsing.
This would be where you’d say “now I get it”, but hold to this piece a bit longer since there is more to making a web app tick. Now, we’re talking a greater deal than simple HTML documents.
If you had the chance to read our previous post, you’re probably aware of the “holy trinity” of web-enabled software: the client (or the representation tier), the server (or logic tier) and the storage layer (or the data tier).
You also might know that when we speak about a web app, this trinity converges into two separate entities: the client (a user’s web browser where all buttons, bells, whistles and all the user-related action takes place) and the server (that local or remote computer or collection of computers where all middleware, the application’s logic and storage lives on).
Any Client and Server can exist as separate entities, however, communication between these two would not be possible without a third virtual entity: the middleware. This is a fancy term for any software that runs on your client either your server’s end.
For instance, you can consider as middleware your web browser that acts as a client, while Nginx, Apache, or Microsoft ISS should be considered as software that satisfies World Wide Web Client requests (those generated by your PC’s OS and web browser). Access to “The Internet” can also be considered as middleware since it is in essence, a huge collection of hardware, software and interconnection means that enable those HTTP requests we spoke about a while ago.
Now, to make a web-enabled app work, one should put “the holy trinity” together via middleware and a collection of scripts (or snippets of code). Depending on their purpose, the practice of putting together those scripts is called: client-side scripting and server-side scripting.
In this grand scheme of things: a Client should be referred to as a virtual location where a website is rendered (like a phone, tablet, laptop or desktop computer’s browser) while a Server is a virtual location where all the logic is performed.
Respectively, any code written to run in the web browser is related to the practice of “front-end development”, while code written to perform logic and data operations can be referred to as “infrastructure and back-end development”.
Both of these practices, generate the action and build-up everything you experience, gain or achieve while using any web-enabled software. Without those minions (front-end and back-end developers) that build bits of logic and markup code, HTML itself would’ve not evolved and we’d still consider computing a huge and obscure term related to boring counts and dials.
Your take away here should be focused on the following: web applications are powered by HTTP, its various extensions, the “markup”, web server logic and middleware. It generates the “magic” we’re all experiencing when sending an instant message, liking a photo, posting a live video or joining a gaming stream.
Of course, as in the case of any magic trick, all this is not a supernatural occurrence – it just takes agile hands and highly trained brains. These resources exploit HTTP requests, web server logic, hardware and markup frameworks to deliver you an outstanding digital experience every time you’re watching cat videos, chasing clients throughout your CRM sales funnel or paying your bill via online banking.
Keep in mind we’ve just turned the second page of the story, but we’ll dive even deeper into those inner workings of a web application next week. To get a front-seat, make sure to follow us on Linkedin, Facebook and/or Twitter. As always, if you want to say hello or simply want to add to the story – make use of the comment box below.