Two-Tier Architectures: Client-Side Rendering

methodolo-gies such as Scrum [SB02] and Extreme Programming (XP) [Bec00] from being ap-plied to frontend and backend teams separately. As applications shift towards more complex frontends, the coupling of frontend and backend development inevitably increases time-to-market.

cuted in the client and parts that require confidentiality, security and stricter control and are therefore executed co-located with the data tier. Server-side business logic includes enforcing access control, validating inputs, and performing any protected business logic (e.g., placing an order in an e-commerce shop). Actions carried out by the client can be directly modeled as update operations on the database, with a potential validation and rewriting step enforced by the server.

Request Flow

The request flow in two-tier web application architectures is slightly different from three-tier architectures:

1. With the initial request, the client retrieves the HTML document containing the single-page application logic.

2. The server or cloud service returns the HTML document and the accompanying JavaScript files. In contrast to server-rendered architectures, the frontend’s struc-ture is data-independent and therefore does not require any database queries or business logic.

3. The client evaluates the HTML and fetches any referenced files, in particular, the JavaScript containing the presentation logic.

4. Via JavaScript, the data required to display the current application view are fetched from the server via a REST/HTTP³API either in individual read operations or using a query language (e.g., MongoDB [CD13] or GraphQL [Gra17]).

5. The frontend renders the data using the presentation logic of the JavaScript front-end, typically expressed through a template language.

6. User interactions are sent as individual requests and encode the exact operation per-formed. The response returns the data necessary to update the frontend accordingly.

Implementation

For the realization of two-tier architectures, the technology choices for three-tier archi-tectures also apply. IaaS and Paas offer low-level abstractions for building REST APIs consumed by single-page applications. Most web application frameworks have support for developing not only server-rendered HTML views, but also for structuring REST APIs.

In the Java ecosystem, REST interfaces have been standardized [HS07]. In most other web languages such as (server-side) JavaScript (Node.js), Ruby, Python, and PHP, frame-works employ domain-specific languages or method annotations for minimizing the over-head of defining REST endpoints (e.g., in Ruby on Rails, Django, .NET WCF, Grails, Ex-press, and the Play framework [WP11, The17]). Static files of single-page applications are delivered from a web server, the web application framework, or a content deliv-ery network. The REST APIs are consumed by the frontend that is technologically

in-3Besides HTTP, real time-capable protocols like Web Sockets, Server-Sent Events (SSE), or WebRTC can be employed [Gri13].

dependent of the backend and only requires knowledge about the REST resources to implement client-server interactions. One notable exception is the idea of isomorphic (also called universal) JavaScript that applies the concept of sharing code (e.g., vali-dation of user inputs) between a frontend and backend that are both implemented in JavaScript [HS16, Dep17, Hoo17, Par17].

Database-as-a-Service (DBaaS) and Backend-as-a-Service (BaaS) models provide high-level abstractions for building and hosting two-tier applications. In the case of a DBaaS, the data tier is directly exposed to clients. As this is insufficient if protected business logic or access control are required, BaaS systems extend the data APIs with common building blocks for business logic in single-page applications. Typical BaaS APIs and functionalities consumed in two-tier applications are:

• Delivery of static files, in particular, the single-page application assets

• DBaaS APIs for access to structured data

• Login and registration of users

• Authorization on protected data

• Execution of server-side business logic and invocation of third-party services

• Sending of push notifications

• Logging and tracking of user data

In Section 2.2.6 we will discuss the characteristics of the DBaaS and BaaS models in detail.

As the frontend becomes more complex and handles the presentation logic and signifi-cant parts of the business logic, appropriate tooling and architectures gained relevance.

Therefore, numerous JavaScript frameworks for developing and structuring single-page applications have been developed. A large part of these frameworks is based on the Model-View-Controller (MVC) pattern [KP⁺88] or variants thereof (e.g., Model-View-ViewModel [Gos05]). In client-side MVC architectures, the views generate the document visible to the end user, usually by defining a template language. The model contains the data displayed in the views, so that it embodies both application state and user interface state. A model is filled with data retrieved from the server’s data APIs. Controllers handle the interaction between views and models (e.g., events from user inputs) and are respon-sible for client-server communication. The MVC pattern has been adopted by most widely-used JavaScript frameworks such as Angular [Ang17], Ember [Emb17], Vue [Vue17], and Backbone [Bac17]. Recently, component-based architectures have been proposed as an alternative to MVC frameworks through projects such as Facebook’s React [Rea17]. Com-ponents represent views, but also encompass event handling and user interface state.

In contrast to two-tier applications, any technological decisions made in the frontend are largely independent of the backend, as a REST API is the only point of coupling. Some frontend frameworks additionally offer server-side tooling to pre-render client views. This can improve the performance of the initial page load and is necessary for crawlers of

search engines that do not evaluate JavaScript for indexing. In native mobile applications, the same principles as for single-page applications apply. A major architectural difference is that the frontend is compiled ahead-of-time so that its business and presentation logic can only be changed with an explicit update of the app. Furthermore, static files are usually not provided by the backend, but packaged into an installable app bundle, which shifts the problem of initial load times to both client-side performance and latency of the consumed server APIs.

Problems of Client-Rendered Architectures

Two-tier architectures can improve on several of the difficulties imposed by three-tier architectures, while other non-functional requirements remain challenging:

High Availability and Elastic Scalability. The task of providing high availability with elastic scaling is shifted to the BaaS or DBaaS backend. As these systems employ a standard architecture shared between all applications built on them, availability and scalability can be tackled in a generic, application-independent fashion. As a DBaaS/BaaS is a managed service, it can furthermore eliminate availability and scalability problems introduced by operational errors such as flawed deployments, inappropriate autoscaling rules, or incompatible versions.

Fast Page Loads. Navigation inside a single-page application is fast, as only the missing data required for the next view is fetched, instead of reloading the complete page.

On the other hand, data requests become very latency-critical, as the initial page load depends on data being available for client-side rendering. In two-tier applications, the client can start its processing earlier as there is no initial HTML request blocked in the server by database queries and business logic.

Engaging User Experience. Single-page applications are able to achieve a high degree of interactivity, as much of the business logic can be directly executed on the client.

This allows applying updates immediately to remain under the critical threshold of 100 ms for interaction delays.

Fast Time-to-Market. As the frontend and backend are loosely coupled through a REST API and based on different technology stacks, the development process is acceler-ated. The implementation of the frontend and backend can proceed independently, enabling individual development, testing and deployment cycles for a faster time-to-market.

In summary, many applications are moving towards client-rendered, two-tier architec-tures, to improve the user experience and development process. This shift reinforces the requirement for low latency, as data transferred from the server to the client is critical for fast navigation and initial page loads.