Such terms as ”web app”, ”front-end Fort Lauderdale 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:
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 of choice.
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.
