3 types of web application architecture

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

We outline 3 main types of web architecture and discuss their advantages and disadvantages for three points of view: software owner, software entrepreneur (developer) and end user. There may be other types, but they basically come down to these three as their subtypes.

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

It is almost impossible to evaluate these completely different architectures impartially. But we will try to use several criteria for evaluation:

user:

Responsiveness / usability. Updates of data on pages, switching between pages (response time). Such user interface features as richness and intuitive use.

Linkability. Ability to save bookmarks and links to different sections of the site.

Offline work. Speaking for himself.

Developer:

Speed ​​of development. Adding new functional features, refactoring, parallelizing the development process between developers, layout designers, etc.

Performance. Maximum response speed from the server with minimum computational power consumption.

Scalability. Ability to increase computational power or disk space during increases in volumes of information and / or number of users. If the assigned scalable system is used, data consistency, availability, and partition tolerance (CAP theorem) must be provided. It is also worth noting that the case when the number of features / screens in the client app increases at the request of the software owner depends on the framework and implementation rather than the type of web architecture.

Testability. Possibility and ease of automatic unit testing.

Software Owner:

Functional expandability. Adding functionality within minimal time and budget.

SEO. Users must be able to find the application through any search engine.

Support. App infrastructure costs – hardware, network infrastructure, maintenance staff.

Security. The software owner must be sure that both business data and user information are kept secure. As the most important security criterion, we consider the possibility of changes in the functionality of client-side app behavior and all associated risks. Standard hazards are the same for the compared architectures. We do not consider security on the ‘server-client’ channel because all these architectures are equally vulnerable to intrusion – this channel may be the same.

Conversion: site – mobile or desktop application. Ability to publish the application in mobile markets or make a desktop application out of it with minimal additional cost.

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

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

Type 1: HTML on the server side

The most prevalent architecture. The server generates HTML content and sends it to the client as a complete HTML page. Sometimes this architecture is called ” Web 1.0 ” as it was the first to appear and currently dominate the Internet.

Responsiveness / Ease of Use: 1/5. The least optimal value among these architectures. This is so because there is a large amount of data transferred between the server and the client. The user has to wait until the whole page reloads and responds to trivial actions, e.g. When only part of the page needs to be loaded. Client UI templates depend directly on the framework used on the server. Due to the limitations of the mobile Internet and huge amounts of data transmitted, this architecture is hardly applicable in the mobile segment. There is no way to send instant data updates or real-time changes. If we consider the possibility of real-time updates through the generation of finished parts of server-side content and client updates (through AJAX, WebSockets), plus design with partial changes to a page, we go beyond this architecture.

Compatibility: 5/5. The highest of the three as it is the easiest implementable. This is because by default, a URL receives specific HTML content on the server.

SEO: 5/5. Pretty easily implemented in a similar way to the previous criterion – the content is known in advance.

Development rate: 5/5. This is the oldest architecture, so it is possible to choose any server language and framework for special needs.

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

Performance: 3/5. Tightly tied to responsiveness and scalability in terms of traffic, speed, etc. Performance is relatively low because a large amount of data needs to be transmitted containing HTML, design and business data. Therefore, it is necessary to generate data for the entire page (not just for the changed business data) and all the accompanying information (such as design).

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

Security: 4/5. The application behavior logic is on the server side. However, data is openly transmitted, so a protected channel may be needed (which is basically a story of any architecture that relates to the server). All security functionality is on the server side.

Conversion: site – mobile or desktop application: 0/5. In most cases, this is simply impossible. There is rarely an exception (more exotic): if the server e.g. Realized on node.js and there are no large databases; or if you use third-party web services for data collection (it is a more sophisticated variant of architecture, though). Thus, the application can be wrapped in node webkits or in analogous ways.

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

Type 2: JS Generation Widgets (AJAX)

Developed architecture of the first type. The difference is that the page displayed in the browser consists of widgets (functionally independent devices). Data is uploaded to these widgets via AJAX query from the server: either as a full-fledged HTML or as JSON and converted (through JavaScript templating / binding) to the page content. The ability to upload piles of HTML precludes the need to use client-side JavaScript MV * frames; in this case, something simpler can be used – for example jQuery. By lowering the interactivity, we increase the speed of development and make the functionality cheaper and more reliable.

The main advantage is that updates from the server only arrive at the part of the page requested by the client. It is also good that widgets are functionally separated. A particular widget is responsible for part of the page; changes in one part do not affect the whole page.

Responsiveness / user friendliness: 3/5. The amount of data transferred for part of a page is smaller than for the entire page, which is why the responsiveness is higher. However, since a page is a set of widgets, the relevant UI templates in a web application are limited by the selected UI framework. Cold start (the first full load) on such a page will take a little longer. The content that is fully generated and cached on the server can be instantly displayed on the client; here it is time to retrieve the data for the widget and usually for templating. At the first visit, the site will not be as fast to load, but further it will be much more comfortable to use, compared to sites based on the architecture of the first type. It is also worth mentioning the possibility of implementing ” partial ” loading (as done on yahoo.com).

Compatibility: 2/5. Here special tools and mechanisms are needed. As a rule, the Hash-Bang mechanism is used.

SEO: 2/5. There are special mechanisms for these tasks. For example, for promoting websites based on this architecture, Possible to pre-define the list of promoted pages and create static URLs for them without parameters and modifiers.

Development rate: 3/5. Not only do you need to know server-side technologies, but also to use client-side JavaScript frameworks. Server side web services are also required to be implemented.

Performance: 4/5. The time and resources spent on generating HTML content is relatively small, compared to the app’s time in retrieving data from the databases and their processing before templating. Using the extended type of this architecture (when data is transferred as JSON) slows down traffic between the client and the server, but adds an abstraction level to the application: retrieval from database -> data processing, serialization in JSON -> API: JSON -> parsing of JSON – > binding of data object on client to HTML.

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

Testability: 1/5. It is required to test the server side, the client code, and the web service that returns the data to update widgets.

Security: 4/5. Part of the logic is moved to the client’s JavaScript, which can be changed by an intruder.

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 is a problem updating or caching the data displayed on the widget. This functionality needs to be implemented further: in the manifest only names of the files that will be cached from the server can be specified. Correlation between the widget template file stored in the manifest and the logic of page behavior requires extra work.

Type 3: Service-Oriented Single Page Web Apps (Web 2.0, HTML5 Apps)

Here we would like to say that the term ” Web 2.0 ” is not right here. One of the peculiarities of Web 2.0 is the principle of involving users in filling and repeating content adjustments. Basically, the term ” Web 2.0 ” means projects and services that are actively developed and enhanced by users themselves: blogs, wikis, social networks. This means that Web 2.0 is not tied to one technology or set of technologies.

Let’s find out the essence of this architecture. An HTML page is downloaded from the server. This page is a JavaScript code container. This code addresses a specific web service and retrieves only business data. The data is used by the JavaScript application that generates the HTML content of the page. This type of architecture is the development of the previous type, which is actually a self-sufficient and rather complex JavaScript application where some of the functionality is moved to the client side. For comparison, the architecture of the second type cannot show a large number of interrelated and structured functions.

It’s also worth noting that nowadays JavaScript apps that work fully offline (with few exceptions, such as rad-js.com) are rarely featured. This approach allows for easy reverse conversion: publish an existing application online.

Responsiveness / user friendliness: 5/5. The amount of data transmitted for updates is minimal. Therefore, responsiveness is at the highest level. UI is generated via JavaScript, it is possible to implement all necessary variants. There is a problem with JavaScript multithreading: in this particular case, processing large amounts of business data should be moved to the web service.

Compatibility: 1/5. Special tools and mechanisms are needed as well as a framework that can use, for example, the Hash-Bang mechanism.

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

Development rate: 2/5. It is required to develop a web service and use more specialized JavaScript frameworks that build the app architecture. As the architecture is relatively new, not many specialists are able to create a high quality site / system based on this approach. There are not many time-tested tools, frameworks and approaches.

Performance: 5/5. Under this architecture, this criterion has the lowest server side influence. The server should only provide the JavaScript application to the browser. On the client side, performance and browser type are paramount.

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

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

Security: 0/5. All the logic moves to the client’s JavaScript, which can be changed relatively easily by an intruder. For protected systems, it is required to develop a preventive architecture that takes into account the peculiarities of open source applications.

Conversion: site – mobile or desktop application: 5/5. A website becomes an application using such a platform as PhoneGap or similar.

Offline work: 5/5. This architecture is a full-fledged application; it is possible to store separate data as well as parts of the application using any storage (eg local storage). A further advantage is the ability to switch data storage and management to offline mode. In comparison, the two architects mentioned above are only partially functional offline. Here, the missing data can be replaced with mocks, it is possible to display warning windows or use data from the local repository, while synchronization may be back for later.

Thus, we can see that there is no perfect architecture – the optimal choice depends on tasks and priorities. If no criterion was mentioned here, that doesn’t mean it was ignored – it’s just the fact that for each software project, every criterion has a different meaning. Each project needs to be discussed separately so that the software owner will be able to make a choice. For each real project, one of these criteria can be defined. It is also possible to optimize the architecture of the app or implement a hybrid architecture that perfectly meets the business requirements.