Basics: a user perspective on web-enabled software

Web-enabled software has taken over our devices and changed the way we work, shop, entertain, exercise or even medicate. In just a couple of decades, specialized software migrated from our office computers and servers towards “the cloud”. This ephemeral change led to some confusion and blurred-out the generic conception of how software works.

Following-up on that idea, we thought a fresh introduction about how typical web-enabled applications work would not hurt. Hopefully, this post will bring more light on what a typical web application is. Which are the main components and who is responsible for building them?

A bit of background – how did web-enabled applications emerge?

Back in the day, the web was not as friendly as it is now. Mainly, it consisted of static pages and links, missing the interactivity layer we’re taking for granted today.

It all began back in the 1990s when several Bulletin Boards Systems started to move to the web. These transitioned to traditional HTML-static pages  and  libraries.  The upgrade allowed users to perform functions such as uploading and downloading software and data. Reading news and bulletins. And exchanging messages with other users through public message boards or via direct chatting.

The transition was not as smooth as we’d imagine. The first web-enabled applications required a heftfy disckspce budget. I.E. users had to install a particular program on their machine. Think about AOL’s GeoWorks and countless IM/forum clients back in the ‘90s.

However, WEB 2.0 era concept switched the online focus from access to static resources to incentivizing user-generated content. With its rise, web applications became an internet default. Resources such as Wikipedia, Flickr, Orkut, Youtube, MySpace, Hi5 and many others outgrew the static HTML pages.

Just to give you an idea… According to Netcraft and W3Tech’s January 2019 Web Server Survey, there are over 1.5 billion websites. Only 2% of these account for static HTML web resources.

With the WEB 1.0 to WEB 2.0 transition, web application models changed to suit our needs. So did their structure and  main parts that make a web-enabled piece of software tick.

The basic definition of a web application

According to Wikipedia, a standard definition might sound like this: “A web application is a client-server computer program, where the client runs in a web browser”.

Now, let’s translate that into something anyone can get.

Typically, an application that makes use of a database refers to as multi-tier (or multi-layer) apps. Such apps decompose into three main conceptual layers:

1. The client layer aka the presentation tier

This layer represents elements such as:

The Graphical User Interface. The screen, views, windows, buttons or virtually anything you can click/tap/interact with as soon as you open an application.
And the Client-side logic. All that magic that happens when you save a task, send a message or simply click on a button. These mechanics usually run powered by code instructions, including processes like temporary storage of data generated by your actions.

This layer serves as the main interaction point with an application. Usually designated for users with various tech awareness.

2. The server layer aka the logic tier

This tier converges elements that handle processing for the client layer. It powers request translations as well as data storage, processing and deletion. In other words, think of this part as of the application’s “brain” that commands all of your actions. Actions generated within the client layer, according to a pre-defined set of rules and procedures.

3. The data layer/tier

A entity defined by data storage strategies and configuration. Usually, this layer consists of a relational database or various databases, stored on a server’s hard drive. Now, depending on the application’s scope, this layer can expand into various models and structures. However, we’ll leave this for another post, dedicated to data only. After all, we’re covering basics here.

The only difference between a traditional multi-tier app and a web-enabled one is the location of those layers. For instance, take the most basic App you’d find on a computer (like msaccess.exe). All those layers are residing on your machine (except when you connect to an external data source). You do not need to access the internet for it to work. There’s a dedicated Graphical User interface (further as GUI).  You get all the tools you need to record, delete, filter and view data. An; you can as well, save everything to a file – right?

Local Storage – a downside

Now, because it resides on your machine, you cannot update that file at any time or anywhere. Well, you could, but the main issue here is data consistency. Even if you are a proud owner of a 32GB USB stick […] you’d have to be carrying a backup or a copy of that file. When you’d make changes to it, the original file would not be updated. You’d have to update the original by replacing the machine file with the one residing on your USB stick. Also, if your hard drive “died” and/or you’ve lost your precious USB stick. If those evil internet minions infected your Operating System. Or, if you love pouring cups of coffee over your motherboard and hard drive… That data can be corrupted or lost forever.

In comes the web application

A web application changes that operating paradigm by moving all those layers somewhere else. All your data, all those actions and updates performed on that file is handled by a trusted big brother… The server-side and its storage layer.

This way, you can edit that “blacklist.mdb” anytime, anywhere… As long as the machine you’re operating has an updated web browser installed and features a reliable internet connection.

Now, depending on your web application complexity and purpose, the data and server layers can reside “in the cloud”. That means, within your company’s or application’s owner datacenter. Essentialy, a web application is yet another computer program that “lives” on the internet, rather than on your local machine.

What makes a web application tick (the essentials)?

Remember those conceptual layers we spoke about when defining an app? Well, if you got those, from here on it should be easier to get a grip on how inner workings. Those layers are split at the code level too. Only this time, they are defined a bit different, especially for those in the business of building web-enabled services.

If you’re going to work with a team of developers, the most widespread terms you’ll hear about are “the front-end” and “the back-end”. You’ll also hear about terms like frameworks, programming languages, Application Programming Interface, libraries or development, test and production environments.

All of these might seem a bit confusing to you, but if you’ll keep reading our blog. I promise: you’ll get around them quite easily. After all, you don’t have to write code to understand the basics of developing a web application or the main tools (also defined as “the software stack”) used to deliver one.

Part 1: The Client-Side aka Front-End

Now, as a starting point, take another look at that “client-side” definition. This is where the holy grail of “front-end development” emerges. That’s because a working “client-side” aka user interface is the end-product of front-end programming.

Here, you’ll have to deal with User Experience engineers, then with User Interface Designers and finally with Front-End Developers. In other words, these guys will plan, design and program everything your user, employee and system administrator see when they interact with your web-enabled application.

The User Experience Engineer is in charge of how your app should feel for a particular stakeholder. Simply put, this guy or girl will have to think about where all buttons, bells and whistles should be placed, as well as when should someone receive a notification, get a functional pop-up window or hear a triggering sound. Their work usually results in a prototype of your interface, also called a “wireframe” that looks somewhat like this:

The Front-end – from UX to UI

Once that wireframe is ready, together with a descriptive action strategy as per each wireframe view (think of different windows from within the app) – it’s time to call in the Make-up artist or The User Interface Designer. 

This master of colours will design each user view, shape each button and build the eye-candy part of your client-side. If you’ve ever played Candy Crush – you know what I am talking about. 

When the User Interface is ready, things become quite straight-forward. Here, the Front-End developer (or an entire team – depending on the application’s scale) gets to work. These are responsible to implement the entire User Experience according to the designed interface. Essentially, they translate everything into code that will render (or draw) the final “client-side”.

This process is usually called the ”markup” of a particular design. In essence, it is a basic shell that performs rudimentary logic functions and renders or draws the interface. In addition to markup, Front-End engineers might also create the interface logic scripts that account for tiny or non-essential events like eye-candy colour rendering or interface switches, transitions or basic list sorting that does not reflect on the back-end. It is to mention that complex logic can also be executed on the front-end, however, this is not recommended by practice since exposed logic can easily be hacked.

Part 2: The application’s infrastructure and back-end aka the application’s logic tier

This is one of the most crucial ones. If the “front-end” is the skin, all the muscles and bones of the app are defined by its infrastructure and back-end. Here, you’ll deal with System Architects, Back-End developers and DevOps. These guys will have to do the heavy-lifting since anything that is received from the client-side, must be processed and executed according to your application’s logic.

From the beginning, the System Architect will decide which infrastructure model, programming languages, frameworks or third-party APIs, hosting mediums as well as storage strategies should be used for your web-enabled app.

This stage has a direct connection to your application’s purpose and it is arguably one of the most important steps that will decide your software’s fate. Such decisions are usually taken as soon as the user experience map, main application requirements and wireframes are ready. Work on your application’s infrastructure might be performed in parallel with the markup – “part 2” is only a symbolic divider meant to segregate the “Front-end” from the “Back-End”.

From web applications blueprints further…

Moving forward, you’ll have to interact with the Web Weight-Lifters: The Back-End developers and Quality Control Agents. They will code all of your described logic, build each end-point of your API, connect each data-source to its destination and make sure everything works as intended.

In simpler terms, they do a tremendous amount of work you don’t even see. For instance, every message you send in a texting app, every comment you post – any action you’re able to see right after you click Save/Send or Upload can be defined by hundreds if not thousands of lines of code on the back-end. In less than a blink of an eye, the back-end processes all of your client-side actions and makes sure the data is saved or altered according to a given action.

On top of the above, the same people follow System Architecture blueprints to enable and deploy any middleware.

This element can be described as the glue between the front-end and the back-end. You can define as middleware any database connection means, any API procedures (requests/responses), or anything that enables communication between the “Client” (your computer’s web browser) and the “Server” (the computer or the collection of computers that your app runs on).

Part 3: The application’s data layer

It is to mention that a typical view of a web app arguably consists of two parts: the “front-end” and the “back-end. This is usually achieved by absorbing the data layer into the back-end, which in our own opinion, is not the best practice.

It is safer to have a separate layer orchestrating both data sets and the database management system software. Not to mention the current GDPR guidelines that require web-enabled applications to feature a dedicated data layer that allows concealing, encrypting and deleting particular user data by request. Since web-enabled applications consist of user-generated-content (90% of the time) this segregation shifts from the recommended box to the compulsory one.

To enable such a layer, you’ll work with a Database Architect that will design, manage and provide policies for data access. On top of that, if your app will operate with critical user info (like first, last name or email), you’ll also have to get coverage from a Data Security officer.

ENDNOTES

While we’ve summed up the main elements of a web application and outlined those involved in building them, there is still something quite important to mention. Such a perspective is a very traditional one and web-enabled apps are in continuous metamorphosis.

The Internet changes shapeshifting towards semantic web (or WEB 3.0) and it is not long until this bird’s eye view changes. It has already changed, generating multiple architecture models, multiple interpretations of the “server” and “data” layers and countless application frameworks.

I am quite aware that we’ve just scratched the surface with this post so, needless to say: there is a series of follow-up articles on the way, covering semantics and mechanics behind web services, APIs, frameworks and many more. So make sure to follow us on Twitter and LinkedIn to get a fresh update on inner workings of the web.

For anything else, there’s a comment box below. Feedback – as well as suggestions – are welcome.