In the previous post, we learned about the basic architecture of any web application. Things are not quite that simple, though. Depending on the programming languages used to build the application, those two layers can divide into many sub-layers. In this post, we explore different architecture patterns and how they work.
Traditional Web Application (or Multiple-Page Application)
The traditional architecture dates back to the early 1990s, and many web applications still use it. We already discussed it in the previous post, but let’s recap the main idea.
Within this design, whenever a user clicks on a link, the web browser sends a new request to the web server. Once the request is processed, the web server returns the demanded data to the client. If the user decides to go to another page, the process is repeated.
But something is different from the previous post’s diagram, right? It seems there are a few new sub-layers.
Once the application receives the user’s request, it fetches the relevant data to be displayed. The job of the presentation layer is to select the appropriate template for the requested page and replace the placeholders with actual data. After this process finishes, the resulting HTML file is returned to the user’s browser. Next, the browser renders the requested page after a UI refresh.
The business logic layer drives an application’s core capabilities and handles user requests. It validates data, identifies the user, provides services, and communicates with the database, all based on the logic defined by the developer. The tools used to implement this layer are server-side programming languages such as Java, PHP, ASP.NET, Ruby, or Python.
The persistence layer is a centralised location where all relevant data is stored. Usually, it is implemented as a database management system (e.g., MySQL, MSSQL, PostgreSQL), or even plain text files. This layer plays an important role in the reusability and exchange of data.
Note
The definition of these layers is applicable for other architectures too, not just for the traditional applications.
Single-page web application
In the past, all web applications used a multi-page architecture. When you clicked something, a new HTTP request was sent to the web server, and the browser updated the content via a UI refresh. Some developers even tried to deliver web applications that feel like desktop applications through various technologies such as Adobe Flash, Microsoft Silverlight, or Java Applets, as Javascript was poorly supported by most web browsers. But the user experience was far from perfect.
Note
Now, Javascript is a standard, and according to W3Techs, more than 95% of existing websites use it.
The widespread adoption of web applications forced leading technology vendors to step up their game so that they can keep up with the users’ requirements. Soon, web browsers started to improve the support for Javascript, and new technologies such as AJAX came in. These advancements led to the first of many Javascript libraries that allowed developers to build single-page web applications (SPAs).
In a SPA, the application code is loaded only once in the browser. Next, when the user starts interacting with the app, Javascript makes all requests in the background and updates the page content on-the-fly without refreshing the page. Facebook, Google Mail, and Twitter are just a few examples of SPAs. Figure 2 illustrates the architecture of a single-page application.
By comparing SPA architecture to the traditional one (Figure 1), you probably noticed that the presentation layer was moved from the server-side to the client-side. Hence, the server is no longer responsible for combining the requested data with the appropriate HTML template. This is a decoupled model where the browser manages the routing to the correct HTML template (or view) and how the data is presented, while the web server can be used only as an API.
Widget Web Application
Widget web application architecture is a hybrid architecture that combines the stable nature of traditional web applications with the powerful features of Javascript. In this paradigm, pages contain independent widgets that can interact with the users, process their actions and display additional content without reloading the page. As a result, the application feels more agile, dynamic and mobile-friendly, allowing real-time widget updates. The Uphack learning platform is built this way.
Moving between pages on learn.uphack.io triggers a full page load, but individual pieces of the interface update on their own. Opening the account sidebar, for example, fires several HTTP requests in the background to fetch notifications and recent activity, and none of that touches the rest of the page. Amazon and Dribbble are built along the same lines.
Now that you have a basic understanding of what widget web applications are, let’s see how this architecture differs from the previous two that we discussed.
Since this architecture is heavily based on the traditional architecture, they look quite the same, right? The only difference is the addition of web services. Also, some small parts of the business logic that govern the widgets could be implemented in the frontend layer.
Conclusion
Web applications are intricate pieces of software consisting of many components such as databases, the UI, and the application server. Web architecture ties all of these parts together and makes them interact. Depending on the programming languages chosen by the developer, a web application can be either a multi-page app, an SPA or a widget app. Until we dive into security stuff, do this simple exercise: whenever you use a web application, try to identify its architecture type and think about all the interactions that happen behind the scenes. In the next post in this series, we look at web architecture from a holistic perspective: monolithic vs. microservices.