Basics: a user perspective on the frontend
A while ago, we started peeling off web-application layers to deliver a better perspective on what terms you should be aware of when building such software. Of course, we’ve only scratched the surface of what a web-enabled application is, leaving space for a series of follow-ups. As promised, we’re getting back to you with a user perspective, tearing down the presentation tier of an app and revealing its structure as well as basic frontend terms you should be aware of before you adventure into building an app.
Back to the books: standard definitions of the “frontend”
As any computer-related term, this one tends to be ambiguous and oftentimes gets confused. This is because in some instances the “frontend” can define a variety of concepts.
For instance, according to Wikipedia, this term requires disambiguation when we speak about software:
A: When speaking about content management systems, the term refers to tweaking end-user facing views (or the public interaction side of the system, where all the commenting, sharing and content rating is performed).
B: In speech synthesis software, the client-side or the frontend is a part of the system that transposes the input text into a symbolic phonetic representation (or converts phrases into machine speech, that is aware of punctuation and phonetic aspects of a specific word).
C: When talking about compilers (software used by developers to translate written code into a lower-level computer language or regular applications), we call frontend, the part of the system that translates a computer programming source code into an intermediate representation or re-arranges simple input text into sections, stacks or graph structures that are easier to understand and analyse by a programmer.
All of the above are valid definitions of what frontend is. However, in regards to building web-enabled software, the definition is a bit different than what you might have expected.
Here, we call “frontend” the entire User Experience replicated as an Interface that is segregated into various segments or views, designed for particular stakeholders (i.e. Administrative, operational and System Management gateways). Usually, these interfaces enable users to view and interact with data to reach a role-specific scope.
Analogically, anything unseen to the user’s eye that takes place anywhere else the client area can be referred to as “backend development”
To put it in even more basic terms, everything you click, interact with, or see when working with a web-enabled app, is generated by frontend development processes.
Fundamental processes to be aware of
As we’re tackling frontend fundamentals, we cannot ignore the holy trinity of any web app: the client (or the presentation tier), the server (or logic tier) and the storage layer (or the data tier).
We’ll decompose the above model, into smaller pieces, so you would get a glimpse of processes happening within the presentation tier’s backstage.
For the beginning, let’s imagine you as the client interacting with any given web app. To do so, you must connect to the internet, open your favourite browser and type in the application’s URL.
The URL’s role is to point you to the right location of a particular server – think of it as a record in the internet’s phonebook that you’re dialling every time you need to access any particular website. It will usually represent something like this:
Now, to clarify the above, any given URL will define:
- The access Scheme or Protocol (in our case it’s the Secured HTTP Protocol);
- Any User Information (e.g. username required when accessing services such as mail or a file transfer protocol; in case of web pages it is usually represented as a null value treated as “guest” by any particular server);
- The Server’s Location (think of it* as of a corporate phone where the main number is any given host);
- The Connection Port – (*any department extension of a given corporate number);
- The Access Path or any specific page you’re visiting (usually “/” will query the main index.html page, but if you’d access a blog, the path would be altered to “/blog/” depending on the configuration. Going back to the phone number analogy, this would represent a direct extension to someone’s desk);
- The Server Query (represents a specific option – again, if compared to a phone call, this would be similar to calling someone’s voicemail by adding # or a specific number at the end of the extension); and
The Query’s Fragment (that is, in essence, the specific location within a webpage);
The above is a default instruction set, but when you’re accessing a website for the first time, only 4 of those 7 identifiers are used:
Since most of humanity’s inventions are driven by comfort – your web browser fills in default values such as the protocol, connection port and implicit path of a particular website. In most cases, all you need to know for accessing a website is the hostname. Even that is translated by middleware services (such as the Domain Name Service or DNS), into user-friendly names, humans can relate to. Regularly, a server’s name represents a set of numbers you would never remember by heart.
Moving on to the process, before we can talk frontend mechanisms, let’s imagine the entire Request/Response journey that loads-up a website. You, the internet-enabled device and your browser of choice represent one of the application’s holy trinity – The Presentation Tier:
(1) as soon as you’ve entered the URL and hit enter in the address bar, an HTTPS request is initiated via the internet. (2) When a request hits the application’s server, aka “the backend”, the latter’s scripts consult the logic, data and storage layers. If there are no issues the server will produce a response (3) sent over the internet. That response contains all of the required data to produce a web view within your browser, as well as a collection of files and scripts (or links to those resources), meant to enable your entire User Experience.
(5) That’s courtesy of Responsive Design. This practice enables content to adapt to a variety of screen resolutions in the most user-friendly way possible. No wonder one of the most popular frameworks, that powers Responsive Design, is called ”bootstrap”. Pretty much as in case of that loop sewn to the boot calf’s edge, frontend scripts ensure all those buttons, text and images are best-fitted to any non-standard screen (with limitations of course).
Another courtesy of frontend development is re-usability. Some of those code snippets define which files are less likely to change, and thus should be stored on your local drive (or “cached”) for eventual use. Caching as a practice is not frontend specific though. These mechanics are a bit more complex. I’ll make sure to cover them in one of our eventual posts, but, for now, you must keep in mind: in some instances, a part of any given frontend collection or markup, might reside on your hard drive.
(6) Frontend scripts that are Cached on your local machine, are in most cases ensuring offline operations. For instance, whenever you’re typing, choosing options or simply clicking on any button that doesn’t require additional information from the backend, the Markup fills that functionality in. If you must select a Country from a predefined list, that is most definitely done on your machine – there’s no reason to load-up the server for that.
(7) On the other hand, anytime additional information is required, the markup sends one or several requests to the server (depending on the usage scenario). For instance, when you’re scrolling down on Facebook, you might have noticed that new posts might take some time to load, but at the same time, you’re browsing the same page.
All this is possible due to proper frontend engineering. In essence, the markup performs URL requests without you even noticing, repeating the entire request/response cycle in the backstage. Here, all those 7 URL definitions come in handy and, depending on the scope, protocols other than HTTP might be used.
Across the entire journey, you might have noticed a particular overlap between the frontend and backend practice – this is because both of these go hand in hand and one cannot work without the other. A frontend without a particular backend layer is nothing else but a simple HTML page on your local computer, while a good application backend would be accessible as back in the ‘80 – via terminal consoles. This is, of course, usable, but who are we kidding: a console is nothing but a frontend for those who really like to make it difficult (guilty by the way – I still like doing stuff via CMD or bash).
I know this might be too much (or too little for some) to ingest but there’s no easy way around it. There is definitely more to the story and the frontend journey (for some of you) might’ve just begun. There are a few things though, you should definitely remember, especially if you’re planning to build a web application with a dedicated team.
- The scripts are embedded in the website’s mark-up that, in turn, powers your entire User Experience when operating a web application;
- The markup (or the collection of embedded frontend scripts) orchestrates backend operations defining server side workloads. In essence, whenever an action triggers data-driven operations (such as updating, storing, re-arranging, sorting or deleting records) the frontend sends required instructions to the application’s logic.
- As an entity, frontend scripts ease server load, since they leverage your computer resources locally, querying backend scripts only when these are essential for a particular operation. This is why today, we gave snappier apps than we used to have 10 years ago when most user operations relied on the backend.
In matters of choice, there are several options to explore, however, we’ll cover this in another post, where we’ll cross-examine the most lucrative frontend options. As always, you can get a front-seat to that trial by simply following us on Linkedin, Facebook and/or Twitter. As for those who would like to join the frontend conversation, make sure to use the comment box below and we’ll be happy to engage.