Wednesday, 28 October InnMind hosts an online webinar from MobiDev tech specialists about indispensable ML and MVP application in shortcuts startup development at half cost.More
3 Types Of Web Application Architecture
Disclaimer: a lot of time passed since this post. Now it’s time to share a new technical article—revealing the web application development principles — which is relevant as of 2019.
In web development, such terms as ”web app”, ”front-end architecture”, ”Web 2.0”, and ”HTML5 apps” are often used in a misleading context which doesn’t consider the full specifics of implementation and usage of web architectures. Today we’ll find out more about the web application architecture types in the light of the latest web trends and key issues that matter to software product owners.
We can outline 3 main web application architecture types and discuss their advantages and drawbacks. We can evaluate them according to three points of view: software owner, software developer (member of the dedicated team allocated to the project) and end user. Other possible examples basically come down to these three as subtypes.
First let’s define a web application: it’s a client-server application, where there’s 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 place and distribute the logic in different ways.
It’s hard to compare completely different architectures impartially. But we’ll try to, using several evaluation criteria.
Updates of data on pages, switching between pages (response time). Such qualities of user interface as richness and intuitivity.
Ability to save bookmarks and links to various sections of the website.
- Offline work
Well, this one speaks for itself.
- Speed of development
Introduction of new features, refactoring, parallelization of the software development process.
Maximum speed of response from the server with minimum consumption of computation power.
Ability to increase computation power or disc space under increases in amounts of information and/or number of users. If an allocated scalable system is used, one must provide data consistency, availability and partition tolerance (CAP theorem). It’s also worth noting that the case, 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 application architecture.
Possibility and ease of automated unit testing.
Software product owner’s criteria
- Functional extendability
New functionality within minimal time and budget.
Users must be able to find the application through any search engine.
Besides software development proper, there are additional expenses: hardware, network infrastructure, maintenance.
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 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: website – mobile or desktop application
Conversion into a mobile or desktop application with minimal additional costs.
Some of these criteria might seem inaccurate, but the purpose of the article is not to show what’s good and what’s bad. It’s more of a detailed review that shows the possible options.
Let’s outline three main web-based application types according to the roles performed by the server and the client browser.
Type 1: server-side HTML web application
The most widespread web application 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 sphere of web development.
Responsiveness/Usability: 1/5. The least optimal value among these architecture examples. A huge amount of data is 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 within a page, we’ll go beyond this architecture.
Linkability: 5/5. The highest of the three, since it’s the easiest implementable. It’s due to the fact that 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 in web development, so it’s possible to choose any server language and framework for particular needs.
Scalability: 4/5. If we take a 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 examples of software architecture.
Performance: 3/5. Tightly bound to responsiveness and scalability. Performance is relatively low because a big amount of 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).
Security: 4/5. The application behavior logic is on the server side. However, data are transferred overtly, so a protected channel may be needed (which is basically a story of any architecture that concerns the server). All the security functionality is on the server side.
Conversion: website – 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: in case the connection is off, the user will see a cached page.
Type 2: JS generation widgets (AJAX)
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; partial 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. At the first visit the website will not be that quick to load, but further it will be much more pleasant in use, if compared to sites based on the architecture of the first type. Also it’s worth to mention the possibility of implementation of ”partial” loading (like it’s done on yahoo.com).
Linkability: 2/5. Here special tools and mechanisms are needed. As a rule, Hash-Bang mechanism is applied.
SEO: 2/5. There are special mechanisms for these tasks. For example, for promotion of websites based on this architecture it’s possible to predefine the list of promoted pages and make static URLs for them, without parameters and modifiers.
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.
Conversion: website – 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 one can indicate only names of the files that will be cached from the server. Correlation between the widget template file, cached in the manifest, and the page behavior logic requires extra effort.
Type 3: service-oriented single-page web apps (Web 2.0, HTML5 apps)
The term ”Web 2.0” isn’t quite correct here. One of peculiarities of Web 2.0 is the principle of involving users into filling and repeated adjustments of content. Basically the term ”Web 2.0” means projects and services which are 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.
Linkability: 1/5. One will need special tools and mechanisms, as well as frameworks which can use, for example, Hash-Bang mechanism.
SEO: 1/5. The hardest one to promote. If the entire app is promoted directly, there’s no problem: it’s possible to promote the application container. If it’s 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 standartization for this process.
Scalability: 5/5. 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.
Conversion: website – mobile or desktop application: 5/5. A website becomes an application with the help of PhoneGap or a similar platform.
Offline work: 5/5. This architecture is a full-fledged application; it’s possible to save separate data, as well as 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 in the offline mode. 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.
Thus we can see that there’s no perfect architecture. The optimal choice depends on tasks and priorities. If any criterion wasn’t mentioned here, it doesn’t mean it was ignored. It’s just the fact that for each particular software project every criterion has different importance. For every real software development project one of these examples may be defining. It’s also possible to optimize the architecture of the app or implement a hybrid architecture which will meet the specific business requirements.
For a good example of our work, check our recent Web development case study, dedicated to GrowthHackers, a platform built for a community of marketers and growth professionals.