Apps

3 Types Of Web Application Architecture

Such terms as ”web app”, ”front-end architecture”, ”Web 2.0”, and ”HTML5 apps” have recently become trendy. Unfortunately, these terms are often used in a misleading context that doesn’t consider the full specificity of implementation and usage of web app architecture. Today we’ll try to find out more about the types of web application architecture in the light of the latest web trends and key issues that matter to software owners.

We’ll outline 3 main types of web architecture and discuss their advantages and drawbacks from three points of view: software owner, software contractor (developer), and end-user. There can be other types, but they basically come down to these three as their subtypes.

Apps

First, we’ll define a web application: a client-server application – there is a browser (the client) and a web server. The logic of a web application is distributed among the server and the client, there’s a channel for information exchange, and the data is stored mainly on the server. Further details depend on the architecture: different ones distribute the logic in different ways. It can be placed on the server as well as on the client-side.

It’s near too impossible to evaluate these completely different architectures impartially. But we’ll try to, using several criteria of evaluation:

User:

Responsiveness/Usability. Updates of data on pages, switching between pages (response time). Such qualities of user interface as richness and intuitiveness in use.
Linkability. Ability to save bookmarks and links to various sections of the website.
Offline work. Speaks for itself.

Developer:

The speed of development. The addition of new functional features, refactoring, parallelizing the development process between developers, layout designers, etc. Performance. The maximum speed of response from the server with minimum consumption of computation power.
Scalability. Ability to increase computation power or disc space under increases in amounts of information and/or several users. If the allocated scalable system is used, one must provide data consistency, availability, and partition tolerance (CAP theorem). It’s also worth noting that when the number of features/screens of the client app is increased at the software owner’s request depends on the framework and implementation rather than the type of web architecture.
Testability. Possibility and easiness of automated unit testing.

Software owner:

Read More Articles :

Functional extendability. Adding functionality to minimal time and budget.
SEO. Users must be able to find the application through any search engine.
Support. Expenses on app infrastructure – hardware, network infrastructure, maintenance staff.
Security. The software owner must be sure that both business data and information about users are kept secure. As the main security criterion, we’ll consider the possibility of changes in the functionality of app behavior on the client-side and all associated risks. Standard dangers are the same for the compared architectures. We do not consider security on the ‘server-client channel because all these architectures are equally exposed to break-ins – this channel can be the same.
Conversion: site – mobile or desktop application. Possibility to publish the application on mobile markets or make a desktop application out of it with minimal additional costs.Architecture

Some of these criteria might seem inaccurate, but the article’s purpose is not to show what’s good and what’s bad. It’s more of a detailed review that shows the possible options of choice.

Let’s outline three main types of web applications according to the roles performed by the server and the client browser.

Type 1: Server-side HTML

The most widespread architecture. The server generates HTML content and sends it to the client as a full-fledged HTML page. Sometimes this architecture is called ”Web 1.0” since it was the first to appear and currently dominates the web.

Responsiveness/Usability: 1/5. The least optimal value among these architectures. It’s so because there is a great amount of data transferred between the server and the client. The user has to wait until the whole page reloads, responding to trivial actions, for example, when only a part of the page needs to be reloaded. UI templates on the client depend directly on the frameworks applied on the server. Due to the limitations of mobile internet and huge amounts of transferred data, this architecture is hardly applicable in the mobile segment. There are no means of sending instant data updates or changes in real-time. If we consider the possibility of real-time updates via generation of ready chunks of content on the server-side and updates of the client (through AJAX, WebSockets), plus design with partial changes of a page, we’ll go beyond this architecture.

Linkability: 5/5. The highest of the three since it’s the easiest implementable. It’s because by default, one URL receives particular HTML content on the server.

SEO: 5/5. Rather easily implemented, similarly to the previous criterion – the content is known beforehand.
Speed of development: 5/5. This is the oldest architecture, so it’s possible to choose any server language and framework for particular needs.

Scalability: 4/5. If we look at the generation of HTML, under the increasing load comes the moment when load balance will be needed. There’s a much more complicated situation with scaling databases, but this task is the same for these three architectures.

Performance: 3/5. Tightly bound to responsiveness and scalability in terms of traffic, speed, etc. Performance is relatively low because many data must be transferred, containing HTML, design, and business data. Therefore it’s necessary to generate data for the whole page (not only for the changed business data) and all the accompanying information (such as design).

Testability: 4/5. The positive thing is that there’s no need for special tools, which support JavaScript interpretation, to test the front-end, and the content is static.

Security: 4/5. The application behavior logic is on the server-side. However, data are transferred overtly, so a protected channel may be needed (basically a story of any architecture that concerns the server). All the security functionality is on the server-side.

Conversion: site – mobile or desktop application: 0/5. In most cases, it’s simply impossible. Rarely there’s an exception (more of exotics): for example, if the server is realized upon node.js, and there are no large databases; or if one utilizes third-party web services for data acquisition (however, it’s a more sophisticated variant of architecture). Thus one can wrap the application in node-WebKit or analogous means.

Offline work: 2/5. Implemented with a manifest on the server, which is entered to HTML5 specifications. If the browser supports such a specification, all pages of the application will be cached: if the connection is off, the user will see a cached page.

Type 2: JS generation widgets (AJAX)

The evolved architecture of the first type. The difference is that the page displayed in the browser consists of widgets (functionally independent units). Data are uploaded to these widgets through AJAX query from the server: either as a full-fledged chunk of HTML or as JSON and transforms (through JavaScript-templating/binding) into the page’s content. The option of uploading chunks of HTML excludes the necessity of using JavaScript-MV*-frameworks on the client side; in this case, something simpler can be used – for example, jQuery. By lowering interactivity, we boost the development speed and make functionality cheaper and more reliable.Architecture

The foremost advantage is that updates from the server arrive only for the part of the page requested by the client. It’s also good that widgets are separated functionally. A particular widget is in charge of a part of the page; changes will not affect the whole page.

Responsiveness/Usability: 3/5. The volume of transferred data for a part of a page is smaller than for the whole page; that’s why responsiveness is higher. But since a page is a set of widgets, the applicable UI templates in a web application are limited by the chosen UI framework. Cold start (the first full loading) of such a page will take a little longer. The content, which is fully generated and cached on the server, can be instantly displayed on the client; here, time is spent on getting the data for the widget and, as a rule, on templating. On the first visit, the website will not be that quick to load, but it will be much more pleasant in use if compared to sites based on the architecture of the first type. Also, it’s worth mentioning the possibility of implementing ”partial” loading (like it’s done on yahoo.com).

Linkability: 2/5. Here special tools and mechanisms are needed. As a rule, the Hash-Bang mechanism is applied.
SEO: 2/5. There are special mechanisms for these tasks. For example, for promoting websites based on this architecture, it’s possible to predefine the list of promoted pages and make static URLs without parameters and modificators.

Speed of development: 3/5. Not only does one need to know the server-side technologies, but also to use JavaScript frameworks on the client-side. It’s also required to implement web services on the server-side.

Performance: 4/5. The time and resources spent on the generation of HTML-content, are relatively minor compared to the time spent by the app on retrieving data from the databases and on their processing before templating. The extended type of this architecture (when data are transferred as JSON) lowers the traffic between the client and the server. Still, it adds an abstraction level to the application: retrieval from database -> data processing, serialization in JSON -> API: JSON -> parsing of JSON -> binding of the data object on the client to HTML.

Scalability: 4/5. Same as for the first type of architecture.

Testability: 1/5. It’s required to test the server-side, the client code, and the web service which returns the data to update widgets.

Security: 4/5. Part of the logic is shifted to the client JavaScript, which an intruder can modify.

Conversion: site – mobile or desktop application: 0/5. Same as for the first type of architecture.

Offline work: 1/5. The manifest mechanism works in this case, but there’s a problem with updating or caching the data displayed on the widget. This functionality has to be implemented additionally: in the manifest, only names of the files will be cached from the server. Correlation between the widget template file cached in the manifest and the logic of page behavior requires extra labor efforts.

Type 3: Service-oriented single-page Web apps (Web 2.0, HTML5 apps)

Here we’d like to say that the term ”Web 2.0” isn’t quite correct here. One of the peculiarities of Web 2.0 is the principle of involving users in the filling and repeated adjustments of content. Basically, the term ”Web 2.0” means projects and services actively developed and improved by users themselves: blogs, wikis, social networks. This means Web 2.0 isn’t bound to one technology or a set of technologies.

Let’s figure out the essence of this architecture. An HTML page is downloaded from the server. This page is a container for JavaScript code. This code addresses a particular web service and retrieves business data only. The data are used by the JavaScript application, which generates the HTML content of the page. This type of architecture is the evolution of the previous type, which actually is a self-sufficient and rather complex JavaScript application, where part of the functionality is shifted to the client-side. To compare, the architecture of the second type cannot show a high number of interrelated and structured functions.

It’s also worth noting that nowadays rarely do JavaScript apps that work fully offline (with few exceptions, e.g., rad-js.com). This approach allows an easily made reverse conversion: publish an existing application on the web.

Responsiveness/Usability: 5/5. The volume of data transferred for updates is minimal. That’s why responsiveness is at the highest level. UI is generated via JavaScript; it’s possible to implement any necessary variants. There is an issue with multithreading in JavaScript: in this particular case, processing of big volumes of business, data should be shifted to the web service.

Linkability: 1/5. One will need special tools and mechanisms and frameworks that can use, for example, the Hash-Bang mechanism.

Read More Articles :

SEO: 1/5. The hardest architecture to promote. If the whole app is promoted directly, there’s no problem: it’s possible to promote the application container. If needed for a part of the application, a special mechanism will be needed for that purpose. Each more or less big search engine offers its own methods of standardization for this process.

Speed of development: 2/5. It’s required to develop a web service and apply more specialized JavaScript frameworks which build the app architecture. Since the architecture is relatively new, there aren’t many specialists who can create a high-quality site/system based on this approach. There aren’t many time-tested tools, frameworks, and approaches.

Performance: 5/5. Under this architecture, this criterion has the lowest influence from the server-side. The server only has to give the JavaScript application to the browser. On the client side, performance and browser type are of the greatest importance.

Scalability: 5/5. All the web logic is on the client-side; there is no content generation on the server. When there’s an increase in the number of users, it’s required to scale only the web services that give the business data.

Testability: 3/5. It’s required to test web services and the client’s JavaScript code.

Security: 0/5. All the logic is shifted to the client JavaScript, which an intruder can easily modify. For protected systems, it’s required to develop a preventive architecture, which considers the peculiarities of open-source applications.

Conversion: site – mobile or desktop application: 5/5. A website becomes an application with the help of such a platform as PhoneGap or similar ones.

Offline work: 5/5. This architecture is a full-fledged application; it’s possible to save separate data and parts of the application using any storage (for example, local storage). One more advantage is the possibility to switch data storage and management to the offline mode. To compare, the two aforementioned architectures are only partially functional offline. Here the missing data can be replaced with mocks; it’s possible to show alert windows or use data from the local storage, while synchronization may be left for later.