Such terms as ”web app”, ”front-end Palm Springs architects”, ”Web 2.0”, and ”HTML5 apps” have recently become trendy. Unfortunately these terms are often used in a misleading context which 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 for 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.
First we’ll define a web application: it’s 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 to 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:
Speed of development. Addition of new functional features, refactoring, parallelizing the development process between developers, layout designers, etc.
Performance. 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 number of users. In case the allocated scalable system is used, one must provide data consistence, 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 architecture.
Testability. Possibility and easiness of automated unit testing.
Software owner:
Functional extendability. Adding functionality within 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 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 to make a desktop application out of it with minimal additional costs.
