A Highly Decoupled Front-End Framework For High Trafficked Web Applications
A Highly Decoupled Front-End Framework For High Trafficked Web Applications
A Highly Decoupled Front-End Framework For High Trafficked Web Applications
Abstract—Web applications are becoming more feature rich working on a MVC-like (Model-View-Controller)
and ever more ubiquitous, while trying to address the needs of framework. From an organizational perspective frontend
millions of users. Server-side scalability and performance are a engineers build the controllers and views in PHP and
serious matter as farms are unceasingly expanding for high afterwards the framework populates the templates (mixture
growth sites. User Interface designers are looking for novel of PHP, HTML and Javascript) to produce the output. Since
approaches to stimulate user engagement which results in more each part of the response can be generated with PHP, they
advanced and feature-rich clients. Remaining competitive are taking many shortcuts that result in tight coupling of
requires companies to constantly push and release new features
every possible piece of the code.
along with overall UI redesigns.
From a design perspective the existing front-controller is
The evolution of the web paradigm requires architectural an ad-hoc control flow that routes the calls to the MVC
changes that use models that will increase the flexibility and framework. The standard request protocol is done through
address the scaling problems in terms of performance, URL-visible GET requests complemented with data sent via
development process and demanding product requirements. POST. The existing template engine is tightly coupled with
the View, and delivers final HTML to every user.
This paper presents a web architectural design that decouples The existing system has several problems that need to be
several layers of a web application, while delegating all addressed on an architectural level:
presentation related routines to the client. To address minimize inter-team dependencies that force the
organizational concerns in the design, client-side layers have work organization to be sequential,
been highly decoupled resulting with a well defined, natural
avoid duplicating work while introducing additional
responsibilities for each of them: structure - HTML, layout -
CSS, behavior - JavaScript. The server exclusively produces
client applications,
data that is sent to the client and then mapped to the HTML maximize possible optimization and caching
templates taking advantage of interpreting data structure solutions that can be implemented on several levels
(presence of items, detecting sets of data, manual operations) of the system,
for constructing result view to the user. The data produced by reduce TCO (Total Cost of Ownership) by reducing
the server is client-independent enabling reuse of the server bandwidth and CPU load of the in-house
API by several clients. Overall, the strong responsibilities of infrastructure,
identified layers allow parallelizing the development process maximize flexibility in terms of changing the UI
and reduce operational friction between teams. (User Interface) while reducing time required to
release UI changes,
The server-side part of the frontend framework is designed
implement easily adoptable communication protocol
with the novel Printer-Controller-Abstraction (PCA) that was
constructed as a variation of the Presentation-Abstraction- to increase opportunities for external usage of the
Controller (PAC) architectural pattern. The design keeps the system,
high flexibility of the graph of controllers and introduces maximize the reuse of the common data used of the
additional concepts like response caching and reuse and allows system (list of friends, partitioning schema) and
easy changes of the input and output formats. (Abstract) minimize the cost of bootstrapping the system.
An analysis performed on existing web applications such
Keywords-component; frontend; framework; architecture; as Facebook, Gmail, Flickr, MySpace or Twitter shows that
flexible UI; performance none of these sites produce AJAX (Asynchronous JAvascript
and XML) responses which decouple data from presentation.
I. STATE OF THE ART Usually, these responses are a pre-built stream mixing
Javascript, CSS, HTML and data which is then inserted into
The current system is running rich-client JavaScript and specific containers in DOM (Document Object Model) or
HTML/CSS generated by the server. The Responses are just evaluated in the Javascript engine.
generated using an in-house designed template engine
33
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"}],
}
{"output" : [
{
"friends" : [
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 "userId" : 234,
but also can drastically reduce the number of connections "avatar" : {
between the client and the server (which is especially "offsetX": 31,
significant for mobile applications). "offsetY": 0,
See figure 2 for a more detailed view of the execution "url": "v1m222apwer124SaaE.jpg",
flow. },
"friendAlias" : "Nick"
III. CLIENT-SIDE FRAMEWORK DESIGN },{
The approach followed in the framework makes use of a "userId" : 638,
similar concept followed by Pure JS for templates. However, "avatar" : {
all behaviour and logic is provided by client-side JavaScript "offsetX": 32,
only and the mapping between the data and template "offsetY": 50,
structure is performed automatically basing on the "url": "MLuv22apwer114SaaE.jpg",
semantical information contained in both. Since the },
mentioned mapping information is contained within standard "friendAlias" : "John"
id and class attributes of the HTML tags, they can be }]
naturally reused by Javascript and CSS without introducing }, {
any new meta-language. "threadId": "12670096710000000066",
Effectively, the framework resides on the user browser "canReply": true,
and is responsible for interacting with servers to fetch static "totalMessageNumber": 3,
and dynamic data, template rendering, and user interaction. "messages": [
Specifically, the server interaction involves sending requests {
for downloading all statics from the content caches by "isUnread": true,
pooling and parallelizing requests for optimal bandwidth
"senderId": 32,
usage and total time of handling the request. Upon receiving
the response from the servers the framework executes the "senderFullName": "John",
hooks for client data transformations (e.g. date "body": "But I must explain to you...",
transformation) and renders the page. The Main Controller is "validBody": true
the core of the client-side framework, as it manages the }, {
communication with the servers and handles several hooks "isUnread": false,
allowing code execution within the process of handling user "senderId": 66,
action. "senderFullName": "Paul",
The data is retrieved by sending JSON-RPC requests to "body": "Sed ut perspiciatis unde omnis...",
the server which provide the response to called procedures, "validBody": true
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
34
The page structure is defined in pure HTML. This means response buffer that later is printed (currently only JSON
that the templates themselves do not require introducing any printer) and output from the system.
new meta-language, relying instead on the framework to The Abstraction layer plays a relatively small role in the
show/repeat pieces depending on the interpretation of the PCA structure and only interacts with the Domain layer. But
response data. It is possible though to extend execution of its presence is very important from the perspective of the
the user action by arbitrary routines that can add additional back-end framework.
logic. Still, that doesn't influence the way that the templates See figure 3 for a general model.
are being created and all of the routines for handling None of the PCA agents produce the presentation as
templates are implemented in Javascript. such. Instead the response is sent to a Response Buffer where
Here is an example of a piece of HTML code which each agent caches the data it produces. The Response Printer
serves as a template to display user avatars: is a lazy component which just produces a representation of
the data when the full request has been performed (when
<img params="userId url offsetX offsetY" Printer asks for it). The Response component allows greater
class="avatar" src="" alt="" control over re-usability of responses across the hierarchy in
onclick="Tuenti.Modules.Avatar.onClickEvent(this);"/> a request, allowing reuse of the agent response throughout
the lifetime of a request. At the end of processing, the Printer
With this code sample the Template Engine is capable of component can accept any printing strategy to produce
implicitly performing a very flexible conditional statement output in desired format.
where it is possible to show the element basing on the The complexity of each agent is dramatically reduced as
presence of the avatar in the data, repeat it if the avatar is an the framework does not produce any views. The Abstraction
array, and inject data into the DOM element basing on the layer of an agent will access the Domain layer, which is part
information contained in the params attribute. of the backend framework, to fetch the requested data. The
If no matching with the data can be found the DOM Controller contains all the actions an agent can perform and
element will be left unprocessed. The data centric approach it may instantiate multiple Abstraction objects to fetch data
of the framework means that the Template Engine will to build its output. The structure of controllers provides them
identify elements in the structure by iterating through the with a lot of flexibility. A Controller can delegate tasks to
data, and matching them in the DOM structure that is being other agents or fetch their responses and then perform the
dynamically scoped. When iterating into nested structures, requested action. Additionally, the controllers are capable of
the Template Engine will now search only within the accessing responses of other agents through the response
corresponding context in the DOM. If certain DOM elements buffer.
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.
IV. 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
35
V. CONCLUSION AND FUTURE WORK This successful PoC shows that highly complex and
The new design improves the project organization feature rich applications can be developed with the proposed
performance by reducing inter-team dependencies and framework. Server-side code complexity is greatly reduced
abbreviating communication to its initial analysis stage. through the usage of the PCA framework. Preliminary results
Apart from that it reduces amount of work that is required to show that response time is almost a third when compared to
prepare the front-end code for the rich UI clients. Teams are the existing MVC framework. Templates can now be
able to focus more on their core activities and technologies visualized directly in the browser, raw template sizes are at
reducing friction and optimizing the communication paths. least 30% smaller, and there are no conditional or iterative
Upcoming visual redesign projects can be done primarly by a flows.
design team rather involving significant work from client- Cost of producing rendered HTML is now moved to the
side developers to support iterative changes to views, client browser's which might now become a challenge that
templates and controllers. Simple and pure HTML templates has to be faced before rolling out the system into live
improve the throughput of designers who may now work in a environment. However, the overall response time observed
WYSIWYG way, able to use their tools directly on the by the user is still lower than in the current implementation
templates. and will be subject to further optimizations.
36