Architectural description of the new Frontend Framework

Andrzej Tuchołka Lead Code Architect
Prem Gurbani Frontend Architect

Abstract

Web applications are becoming more feature rich and ever more ubiquitous, while trying to address the needs of millions of users. Server-side scalability and performance are a serious matter as farms are unceasingly expanding for high growth sites. User Interface designers are looking for novel approaches to stimulate user engagement which results in more advanced and feature-rich clients. Remaining competitive requires companies to constantly push and release new features along with overall UI redesigns.
The evolution of the web paradigm requires architectural changes that use models that will increase the flexibility and address the scaling problems in terms of performance, development process and demanding product requirements.
This paper presents a web architectural design that decouples several layers of a web application, while delegating all presentation related routines to the client. To address organizational concerns in the design, client-side layers have been highly decoupled resulting with a well defined, natural responsibilities for each of them: structure – HTML, layout – CSS, behavior – JavaScript. The server exclusively produces data that is sent to the client and then mapped to the HTML templates taking advantage of interpreting data structure (presence of items, detecting sets of data, manual operations) for constructing result view to the user. The data produced by the server is client-independent enabling reuse of the server API by several clients. Overall, the strong responsibilities of identified layers allow parallelizing the development process and reduce operational friction between teams.
The server-side part of the frontend framework is designed with the novel Printer-Controller-Abstraction (PCA) that was constructed as a variation of the Presentation-Abstraction-Controller (PAC) architectural pattern. The design keeps the high flexibility of the graph of controllers and introduces additional concepts like response caching and reuse and allows easy changes of the input and output formats.

State of the Art

The current system is running rich-client JavaScript and HTML/CSS generated by the server. The Responses are generated using an in-house designed template engine working on a MVC-like (Model-View-Controller) framework. From an organizational perspective frontend engineers build the controllers and views in PHP and afterwards the framework populates the templates (mixture of PHP, HTML and Javascript) to produce the output. Since each part of the response can be generated with PHP, they are taking many shortcuts that result in tight coupling of every possible piece of the code.
From a design perspective the existing front-controller is an ad-hoc control flow that routes the calls to the MVC framework. The standard request protocol is done through URL-visible GET requests complemented with data sent via POST. The existing template engine is tightly coupled with the View, and delivers final HTML to every user.

The existing system has several problems that need to be addressed on an architectural level:
- minimize inter-team dependencies that force the work organization to be sequential,
- avoid duplicating work while introducing additional client applications,
- maximize possible optimization and caching solutions that can be implemented on several levels of the system,
- reduce TCO (Total Cost of Ownership) by reducing bandwidth and CPU load of the in-house infrastructure,
- maximize flexibility in terms of changing the UI (User Interface) while reducing time required to release UI changes,
- implement easily adoptable communication protocol to increase opportunities for external usage of the system,
- maximize the reuse of the common data used of the system (list of friends, partitioning schema) and minimize the cost of bootstrapping the system.

An analysis performed on existing web applications such as Facebook, Gmail, Flickr, MySpace or Twitter shows that none of these sites produce AJAX (Asynchronous JAvascript and XML) responses which decouple data from presentation. Usually, these responses are a pre-built stream mixing Javascript, CSS, HTML and data which is then inserted into specific containers in DOM (Document Object Model) or just evaluated in the Javascript engine.
The abstract of suggested solution defines a communication protocol built on JSON-RPC (JavaScript Object Notation – Remote Procedure Call) with well-defined scopes of responsibilities for technological components of the client and a highly customizable structure of server-side controllers.

Several frameworks exist that introduce similar solutions in order to decouple HTML from data and perform rendering at the client browser.
ExtJS [1] allows placing templates in separate files that can be fetched and cached by the browser. Later, AJAX is used to fetch data from the server to populate the templates. This leads to bandwidth savings as there is no redundant HTML served in every pageview and cost of producing rendered HTML is moved to the client browser. However, the drawback of Ext JS approach is that they are introducing a new language in the templates and therefore increase the cost of any UI and design related operations. Consequently there is an increased need for interaction between designers and client-side developers. Also, the HTML templates produced by designers must be converted into Ext Templates increasing the possible points of failure and the complexity of the development process, as well as making maintenance cumbersome.
Many other JavaScript libraries essentially work with a similar concept. These include: Mjt [2], UIZE [3], TrimPath [4] or EmbeddedJS [5]. An implementation worth mentioning here is one done by PureJS [6], which tackles this issue by creating HTML templates that do not require usage of conditional or looping statements. The templates remain in HTML and the data is matched with injection points identified by a specific attribute in the structure. Conditional statements are triggered by simply hiding or showing an element. In order to implement loops, they are inferred automatically by detecting if the data is an array. However, PureJS does not effectively manage decoupling of data from the structure. More complex (real) usages of PureJS framework require constructing statements named “directives”. These define the process of inserting the data into HTML along with other elements such as additional data structures or adding user interaction.
The existing system produces server-side Views as part of the MVC framework. In a multi-client environment this leads to an added load on the server infrastructure along with increased complexity of implementing any changes to the presentation. Currently the system uses seven different interfaces, each with a separate set of views, controllers and dynamic templates. The new solution will reduce that to much simpler and static templates. An additional limitation of the current MVC system is that it is capable of producing only one view per URL with a request; in contrast, a request with a chained JSON-RPC call can perform several operations and return data that can be used for display, caching, or configuration of the client. The new approach also opens several optimization opportunities in terms of reusing bootstrapped instance and in-memory cache of the system and number of client connections.

Overall front-end architecture and strategy

The front-end framework project is part of the overall architectural redesign of Tuenti.com. The front-end layer is responsible for rendering views, communication with the server and UI interaction. The second part of the project includes back-end redesign which is outside of the scope of this document. Main concerns identified by the stakeholders for the system and that are addressed by the front-end design include: flexibility, cost and schedule, and integrability.

The frontend framework’s principles are to produce a highly decoupled system by introducing a natural separation of concerns in the source code: structure (HTML), layout styles (CSS), behavior and control (Javascript), and data (JSON-RPC). All except for the data will be cached on the client and in content caching solutions reducing the load of the in-house infrastructure. Furthermore, due to the nature of some requests that return mostly unchanged data, it is possible to cache and reuse them. This opportunity is supported by dramatically (45% to 91% according to the tests) reducing the size of the response produced by the server.
The decoupling mentioned above also supports the organizational aspects of development projects based on the framework. Work can easily be parallelized between teams participating in the project. The only required interaction between them takes place in the analysis stage, when the interface and the model are defined to satisfy product requirements. Projects that involve redesign of the user interface can remove (or minimize) the need for developer involvement due to lack of any transformations to the templates that are now based on pure HTML.
JSON was picked as a data transport format because it is technology independent (easily parsed) but also native for the presentation layer of the main client, which is written in Javascript. It can be easily (in accordance to PCA design of the server-side) replaced by XML or other formats on demand. The communication protocol itself has been designed to address the need for semantic identification of the data, human readability, and server-side optimizations. The performance concern is being addressed by the possibility to chain multiple calls in one request; this technique not only reduces the need to bootstrap the system but also can drastically reduce the number of connections between the client and the server (which is especially significant for mobile applications).

A more detailed view of the execution flow:

Client-side framework

The approach followed in the framework makes use of a similar concept followed by Pure JS for templates. However, all behaviour and logic is provided by client-side JavaScript only and the mapping between the data and template structure is performed automatically basing on the semantical information contained in both. Since the mentioned mapping information is contained within standard id and class attributes of the HTML tags, they can be naturally reused by Javascript and CSS without introducing any new meta-language.
Effectively, the framework resides on the user browser and is responsible for interacting with servers to fetch static and dynamic data, template rendering, and user interaction. Specifically, the server interaction involves sending requests for downloading all statics from the content caches by pooling and parallelizing requests for optimal bandwidth usage and total time of handling the request. Upon receiving the response from the servers the framework executes the hooks for client data transformations (e.g. date transformation) and renders the page. The Main Controller is the core of the client-side framework, as it manages the communication with the servers and handles several hooks allowing code execution within the process of handling user action.
The data is retrieved by sending JSON-RPC requests to the server which provide the response to called procedures, but also can contain additional information. This will usually contain data corresponding to the actions that took place within the functional scope of interest of the user (e.g. new message has arrived) but also can contain data used for configuration of the client such as re-routing the client to a different farm, throttling automatic chat status updates, etc.

Example JSON-RPC call:

{
    "Friends": ["getOnline", {"maxCount": "10", "order": "recentVisit"}],
    "Messages": ["getThread", {"id": "12670096710000000066", "msgCount": "5"}],
}

The server will provide a response in JSON which has a flat structure, so it does not infer or suggest any hierarchy on the final display, and is purely data-centric.

{
    "output" : [
        {"friends" : [
            {
                "userId" : 23432,
                "avatar" : {
                    "offsetX": 31,
                    "offsetY": 0,
                    "url": "v1m222apwer124SaaE.jpg",
                },
                "friendAlias" : "Nick"
            },
            {
                "userId" : 63832,
                "avatar" : {
                    "offsetX": 32,
                    "offsetY": 50,
                    "url": "MLuv22apwer114SaaE.jpg",
                },
                "friendAlias" : "John"
            },
        ]},
        {
            "threadId": "12670096710000000066",
            "canReply": true,
            "totalMessageNumber": 3,
            "messages": [
                {
                    "isUnread": true,
                    "senderId": 32,
                    "senderFullName": "Daniel Martín",
                    "body": "But I must explain to you...",
                    "validBody": true
                },
                {
                    "isUnread": false,
                    "senderId": 66,
                    "senderFullName": "Carlos De Miguel Izquierdo",
                    "body": "Sed ut perspiciatis unde omnis...",
                    "validBody": true
                }
            ]
        }
    ]
}

The page structure is defined in pure HTML. This means that the templates themselves do not require introducing any new meta-language, relying instead on the framework to show/repeat pieces depending on the interpretation of the response data. It is possible though to extend execution of the user action by arbitrary routines that can add additional logic. Still, that doesn’t influence the way that the templates are being created and all of the routines for handling templates are implemented in Javascript.

Here is an example of a piece of HTML code which serves as a template to display user avatars:

<span>
 <img src="" alt="" />
</span>

With this code sample the Template Engine is capable of implicitly performing a very flexible conditional statement where it is possible to show the element basing on the presence of the avatar in the data, repeat it if the avatar is an array, and inject data into the DOM element basing on the information contained in the params attribute.
If no matching with the data can be found the DOM element will be left unprocessed. The data centric approach of the framework means that the Template Engine will identify elements in the structure by iterating through the data, and matching them in the DOM structure that is being dynamically scoped. When iterating into nested structures, the Template Engine will now search only within the corresponding context in the DOM. If certain DOM elements are not identified by the Template Engine they are left unprocessed and their default appearance will apply. In order to match elements to data the DOM elements only need to refer to the data through values set in two distinct element attributes, class attribute for data to be injected in the page structure and params attribute for data to be made available to UI interaction scripts.
Specific actions for user interaction can be added to the DOM elements by specifying the action. All actions will be implemented in an external static JavaScript file and, as a good practice and internal coding convention, it will not be allowed to place any other JavaScript code inside the HTML Templates. This is a natural decoupling of behavior from structure which is similar to decoupling page structure from style by not setting inline CSS using the style attribute.

Server-side framework

The main architectural element of the server-side part of the front-end framework is inspired by an architectural pattern known as Presentation-Abstraction-Controller (PAC) [7][8]. The design (named Printer-Controller-Abstraction) bases on identifying data-centric controllers and allows free interactions between them. The graph structure of controllers receives data from the abstraction layer where abstractions are instantiated by controllers. The abstraction layer communicates with the domain layer that manages and identifies domain entities. All of the controllers that participate in the request processing populate a central response buffer that later is printed (currently only JSON printer) and output from the system.
The Abstraction layer plays a relatively small role in the PCA structure and only interacts with the Domain layer. But its presence is very important from the perspective of the back-end framework.

General model:

None of the PCA agents produce the presentation as such. Instead the response is sent to a Response Buffer where each agent caches the data it produces. The Response Printer is a lazy component which just produces a representation of the data when the full request has been performed (when Printer asks for it). The Response component allows greater control over re-usability of responses across the hierarchy in a request, allowing reuse of the agent response throughout the lifetime of a request. At the end of processing, the Printer component can accept any printing strategy to produce output in desired format.
The complexity of each agent is dramatically reduced as the framework does not produce any views. The Abstraction layer of an agent will access the Domain layer, which is part of the backend framework, to fetch the requested data. The Controller contains all the actions an agent can perform and it may instantiate multiple Abstraction objects to fetch data to build its output. The structure of controllers provides them with a lot of flexibility. A Controller can delegate tasks to other agents or fetch their responses and then perform the requested action. Additionally, the controllers are capable of accessing responses of other agents through the response buffer.

Conclusion and Future Work

The new design improves the project organization performance by reducing inter-team dependencies and abbreviating communication to its initial analysis stage. Apart from that it reduces amount of work that is required to prepare the front-end code for the rich UI clients. Teams are able to focus more on their core activities and technologies reducing friction and optimizing the communication paths.
Upcoming visual redesign projects can be done primarly by a design team rather involving significant work from client-side developers to support iterative changes to views, templates and controllers. Simple and pure HTML templates improve the throughput of designers who may now work in a WYSIWYG way, able to use their tools directly on the templates.

Key benefits of this architecture are:
- minimize overhead of maintaining multiple interfaces,
- shift team focus to match their responsibilities,
- removing the need of server-side changes when changing page structure, layout, design or UI scripts,
- parallelize development project efforts,
- minimize bandwidth consumption (savings of 45%-92% depending on the page type),
- minimize server-side CPU use (savings of 65%-73% depending on the page type),
- improve developer’s performance by providing tools with clearly defined responsibilities and scope.

A working prototype has been built, proving the above concepts are viable and functional. A subset of an existing feature, the Private Messages module, of the Tuenti.com application was used to test the above framework. This initial proof of concept (PoC) of the framework has preliminary been evaluated using Firefox 3.5. and Chromium.
This successful PoC shows that highly complex and feature rich applications can be developed with the proposed framework. Server-side code complexity is greatly reduced through the usage of the PCA framework. Preliminary results show that response time is almost a third when compared to the existing MVC framework. Templates can now be visualized directly in the browser, raw template sizes are at least 30% smaller, and there are no conditional or iterative flows.
Cost of producing rendered HTML is now moved to the client browser’s which might now become a challenge that has to be faced before rolling out the system into live environment. However, the overall response time observed by the user is still lower than in the current implementation and will be subject to further optimizations.

References

[1] Ext JS. Palo Alto CA (USA), 2009 [Online].
[2] Mjt, “Template-Driven Web Applications in JavaScript” [Online].
[3] UIZE, “JavaScript Framework”, 2010 [Online].
[4] TrimPath, 2008 [Online].
[5] Jupiter Consulting, “EmbeddedJS, An Open Source JavaScript Template Library”, Libertyville IL (USA), 2010 [Online].
[6] BeeBole, “PureJS, Templating Tool to generate HTML from JSON data”, 2010 [Online].
[7] Coutaz, Joëlle, “PAC: an Implementation Model for Dialog Design”, 1987. H-J. Bullinger, B. Shackel (ed.). Proceedings of the Interact’87 conference, September 1-4, 1987, Stuttgart, Germany. North-Holland. pp. 431–436
[8] J. Cai, R. Kapila and G. Pal, “HMVC: The HMVC: The layered pattern for developing strong client tiers”, 2000, JavaWorld [Online].