Basics: web apps – from perspectives to action

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 into a web app and see what stands behind those fancy terms.

From the Web App beginnings: the internet and it’s mighty HTTP

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 become 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 app: “the operator”. More specifically we’ll speak about the Hypertext Transfer Protocol (aka HTTP).

In the “beninging” 😉

Invented in 1991 by Tim Burners Lee, HTTP became an internet standard that enables access to any web app there is. 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 […] 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 so 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. Plus stats and requested content, served as an HTML document.

Web-enabled software “dial tones”

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” […].web-enabled software

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. It’s safe to deem them as “the operator” machinery that keeps the web flows at pace.

Those requests aren’t the only dial board “an operator” can use.

Web-enabled software (HTTP and Encryption)

In addition to them, there are extensions such as the Hypertext Transfer Protocol Secure (HTTPS). This protocol resembles 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 app. For it to be useful, it needs to send messages that can be interpreted by the client. Here we’re getting to that Hypertext Markup Language story.

The Hyper-Text Markup as a WWW / Web App Language

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 deemed 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.

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.

Simply put…

The web browser is a canvas, HTML is the vase, fruits and background. These subject to processes such as painting/rendering/projection on that canvas. Here, CSS brings together all the paint, brushes and talent owned by an artist. The painting process here makes up the renderings’ definition, while the end-result is the web-view you’re browsing.

Over the years, HTML evolved and made use of various scripts and tools. These built the participative internet we’re all familiar with. Such kits aggregated into several frameworks we make use of today,. That’s how the HTML concept grew into something greater than Burners Lee could ever imagine. Following-up on this evolution, semantics behind the traditional “markup” term expanded. It ended up encapsulating the entire collection of HTML, CSS, JavaScript […] Any code really,  interpreted by your web browser into a single entity.

This would be where you’d say… “now I get it”… But hold to this piece a bit longer. There is more to making a web app tick. Now, we’re talking a greater deal than simple HTML documents.

Back to the basics: the “holy trinity” of an app

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.

Client? Server? What are these?

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.  Although, 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. Nginx, Apache, or Microsoft ISS however, enable 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. After all, the www is in essence, a huge collection of hardware, software and interconnection means that enable those HTTP requests we spoke about a while ago.

The Middleware

Now, to make a web-enabled app work, one should put “the holy trinity” together. Middleware and collection of scripts (or snippets of code) enables just that.

Depending on their [scripts] purpose, the practice of putting them together relates to client-side scripting and server-side scripting.

In this grand scheme of things… A Client resembles a virtual location. A place to render websites. Think of a phone, tablet, laptop or desktop computer’s browser. At the other end, a Server represents a virtual location powering the entire app logic.

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.

A short(ish) wrap-up: the grander scheme of an app

Your take away must focus on the following:

HTTP, its various extensions, the “markup”, web server logic and middleware power any web app.

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 for one sake. Delivering 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. 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; use of the comment box below.