Multi-page, Single-page, or a Hybrid?

Choosing the right architecture for your webapp

Single-Page Applications (SPA) have been the modern trend in designing web applications. But is it actually the design you should go for? A key success factor for your web application is the design and architecture choices you make. There are three main design patterns to consider:

1. Multi-Page Application (MPA) — Also known as traditional web apps
2. Single-Page Applications (SPA)
3. A Hybrid of SPA and MPA

In this article, I’ll explain each type, analyze their pros and cons and also analyze how each fits for different types of applications.

Multi-Page Applications (MPA)

Let’s start with the traditional web apps, MPA. In MPA, most of the application logic is performed on the server side, rather than on the client side (as we will see in SPA). Server side technologies like python are used to serve static HTML for the client. As shown in the below image, when a user loads the home page, a request is made to the server to fetch a static HTML page that will be rendered by the browser. Any action that is done on the browser, say a button click, will make a request to the server to retrieve a whole new static HTML page.

This can be inefficient in some cases. Let’s assume that we have a page with four large images and a Registration Form (check the image below). When the user clicks “submit”, the request would be processed by the server and a registration number would be displayed to the user afterwards. If we follow MPA design, we would load a static HTML page first with the images and the registration form. Upon submitting the form, we request a new static HTML page with four images again and a registration successful message. Here, we are doing redundant work of requesting the server twice to load the same images. The images were already loaded!

Ajax: Asynchronous JavaScript and XML

In the beginning of 2000s, Ajax came to optimize this type of performance issues in MPAs. Ajax is a client-side script that allows you to reload parts of the page without reloading the whole page. The script will send a request to the server to perform a request and load data, however, it does not wait for a response from the server (this is the asynchronicity part of Ajax). As soon as a response is received from the server, a browser event is executed to update parts of the page. Consider the below scenario for an example: when a user clicks “submit”, the browser sends a request to the server to add user data to the database. If successful, the browser will process the response from the server, and replaces the registration form with a success message and a user generated ID number. We saved a lot of work compared to MPAs as we didn’t have to reload the images again.

This is a code example to make things clearer:

Example: https://www.w3schools.com/jquery/tryit.asp?filename=tryjquery_ajax_ajax

When a button is clicked, an Ajax request is made to the server. If there is any code following this code snippet, it will be executed even if no response is received from the server. This is due to the asynchronous nature of Ajax. When /demo_test.txt is loaded by the server, the browser changes the content of #div1 with the result it got from the Ajax request. You can check the HTML content that the server responds with: https://www.w3schools.com/jquery/demo_test.txt

Single-Page Applications (SPA)

SPAs started in early 2010s, which was considered as an evolution of MPA + AJAX together. SPA perform most of the user interface logic in a web browser. It communicates with the server using web APIs to retrieve data. Initially, all UI resources (HTML, JavaScript, and CSS) are retrieved by a single page load once. Any update to the page happen dynamically in response to user actions. The page does not reload (or loads other pages) at any point in the life span of the application.

JavaScript Frameworks for Implementing SPA

There have been multiple approaches for implementing SPA. We have already seen AJAX. I will discuss AngularJS as an example. Wikipedia has listed all the other possible approaches. You can find it here: https://en.wikipedia.org/wiki/Single-page_application. I will have a separate post on these technologies later. For now, I will go through a simple example that explains how AngularJS works for building SPA.

AngularJS is a fully client-side JavaScript framework. AngularJS is based on a concept known as UI Data Binding. UI Data Binding as the name says, makes a connection between the UI elements and the data it displays. When the data changes its value, the UI elements that are bound to this data reflect changes automatically. In AngularJS , the logic and data states are maintained within the client browser. Therefore, a single page’s content is capable of being changed without any interaction with the server. Consider the below code snippet, where a request to get demo_test.txt is made to the server and on success, the response data are stored in the application’s scope on the client-side.

How AngularJS uses AJAX

Here, only one request is sent to the server and then the app stores all the data it receives. This gives the app the capability to work offline pretty well. Even in poor internet connections, local data can be later synchronized when the connection is re-established.

Angular uses Ajax to build SPA. Ajax as we discussed is a client-side script that communicates to the server and processes server responses without the need to reload the page. Angular, however, offers much more functionality than Ajax.

A Hybrid Approach: MPA + SPA

Now that we have an understanding of MPA, AJAX and SPA, we can look into the design choices for a hybrid approach. In a hybrid design pattern, you can mix any design choices as per your requirements. For example (but not limited to):

1. Build MPA as sub applications of SPAs
2. Build SPAs as sub applications of MPAs
3. A hybrid of SPA/MPA with static pages
4. Build separate modules for SPA and MPA and probably make them work together.

SPA, MPA, or A Hybrid?

Let’s go back to the original question of the article: which approach best fits our application requirements? The answer would be it depends on the nature of your application. Let’s analyze each approach in terms of performance, caching, architecture, user experience, security, development efforts, debugging, and some use cases.

SPA Approach Analysis

Performance: SPA enhance performance and web responsiveness. The whole site front-end resources (HTML, CSS, JavaScript) are loaded once from the server (they might load longer the first time). During the lifespan of the app, only data will be transmitted back and forth which would generally enhance performance.

Caching: SPA provide better caching capabilities. As we have seen in the case of angular, it sends a request to the server and then stores the data it receives locally (the scope) in the client-side. Therefore, SPA can cache any local data efficiently and hence users can work offline. This is evident from Facebook and Gmail as you can see how they function pretty well offline.

Decoupled Architecture: Oftentimes we integrate multiple clients (such as web, mobile and desktop apps and third parties) with a single backend. In SPA, the backend and frontend are decoupled in their architecture. The backend no longer renders UI elements and they are now fully handled in the frontend. In the backend, we must already expose an API for other clients. SPA by nature makes extensive use of web APIs to query and update data as users interact with the application.

Search Engine Optimization (SEO) & Analytics: these were a concern in SPA before Google updates its algorithms to consider SPA design patterns. SPA used to have poor SEO as they were not indexed through the search engine. The fact that most of the data come on request from the client gives the application poor SEO. The URL does not change often and it can’t quite be scanned by the search bots. Similarly for Google Analytics Insights, there was a limitation in the information collected by Google Analytics. The only information you could collect is who the visitors are and for how long they stay on your app. However, currently Google has the Google Tag Manager (GTM) that can be used for tracking navigation in SPA by sending information about user events to GTM.

User Experience: SPA can give users poor experience in their browsing history. The URL does not change often and it can’t be saved or bookmarked when a user performs an actions. However, the page can use hashtags in the URL based on user actions to partially enhance this experience. Developers might need to implement additional features such as displaying a meaningful URL based on the current user operation to enable users to bookmark pages, to have browsing history, and to browse back and forth in the app.

Security: Since most of the work is performed on the client-side, SPAs are more vulnerable to Cross-Site Scripting (XSS). Malicious users have easy access to the scripts in the client-side and can work on bringing malicious scripts to the users. One advantage of SPA from the perspective of security is that SPA allow developers to just secure data points, as opposed to MPA where each page has to be secured separately.

Debugging: Since most of the logic is performed on the client-side, and UI changes based on user behavior is not compiled, it is usually harder to debug SPAs.

Data Volumes & Content: SPA retrieves data from the server once and stores it in the client-side. This makes it fit perfectly for dynamic applications with small data volumes. SPA are a better choice if you don’t need heavy data processing and many pages with different designs.

Efforts: Generally, SPAs are easier from a development perspective. However, they require more security and architectural expertise to get the best out of them. SPAs require frequent updates and new frameworks. In addition, Automated builds and deployments are more complex in SPAs. Developers might also spend more time implementing additional MPA like features in SPAs such as bookmarking, managing URLs, and browsing history.

Use Cases: SPA would work perfectly in the following cases:

• Pages that tell stories about a product or a service.
• Social networks, private communities and SaaS solutions.

MPA Approach Analysis

Performance: In MPA, a browser reloads most of the UI resources with every user interaction. This lowers speed and performance.

Search Engine Optimization (SEO)& Analytics: MPA are generally more optimized for SEO as each page has its own URL and can be retrieved by web crawlers separately. Although Google currently indexes dynamic pages, developers have to ensure that JavaScript files can be indexed by the search engine crawlers. In addition, developers can add meta tags to every page separately. Similary, for Google Analytics, in MPA we can provide a lot of analytics with more detailed information on the website performance.

Efforts: MPAs take longer time to develop. Developers have to develop the backend from scratch, to maintain the separation between frontend and backend during the implemtation, and to use frameworks for both the frontend or backend.

Maintenance & Updates Maintenance and updates in MPAs are a chore and it gets complicated as the application gets more complex.

Security MPAs might be a bit complicated and time consuming because developers need to secure each page separately.

User Experience With MPAs, each page has a unique URL which allows the users to bookmark pages and maintain navigation history. However, they are less responsive overall.

Data Volumes & Content MPA is suitable if you have a lot of content and data volumes such products and services. In this case, most of the processing will be on the server and therefore, MPAs would work better for you.

Use Cases MPA would work perfectly with the following cases:

• Your application has a broad range of products or services
• Online stores, business sites, catalogs, marketplaces such as e-Bay.
• Client-side requirements are simple or even read-only
• A search engine, a simple UI with complex server-side logic.
• A blog or content management system, a lot of content with little client-side interactions

Hybrid

Researching this approach was quite interesting. It might sound attractive at first to combine both approaches so that we increase the advantages and decrease the disadvantages. Yes, a hybrid approach might allow us to combine the complex functionality with the enhanced speed and responsiveness. However, we can also have some drawbacks, such as:

• Decrease performance if we load MPA content and also the client frameworks that we need for the SPA.
• Complex development experience for managing both MPA and SPA efficiently.
• We don’t have the benefit of a decoupled architecture anymore, which makes it more complex for exposing APIs and also integrating other clients.
• Securing the application will be more complex as well as managing updates and maintenance.

Sometimes, if the resources are available, a hybrid approach would work best if the application can be separated into modules. SPA/MPA can also be mixed with static web pages to enhance the performance.

That’s it for this topic! Let me know if you have any questions or comments.