3 Types Of Web Application Architecture
From EjWiki
Such terms as" web app"," front-end architecture"," Web 2.0", and" HTML5 apps" have just recently become trendy. Unfortunately these terms are frequently utilized in a misleading context which doesn't think about the complete uniqueness of execution and use of web app architecture. Today we'll search for out more about the kinds of web application architecture in the light of the most current web trends and key concerns that matter to software application owners.
We'll outline 3 main kinds of web architecture and discuss their advantages and drawbacks for three viewpoints: software owner, software application contractor (developer) and end user. There can be other types however they basically come down to these three as their subtypes.
First we'll specify a web application: it's a client-server application - there is a web browser (the client) and a web server. The reasoning of a web application is dispersed among the client and the server, there's a channel for details exchange, and the data is saved generally on the server. More information depend on the architecture: different ones distribute the logic in different ways. It can be put on the server along with on the customer side.
It's near to impossible to assess these completely various architectures impartially. But we'll attempt to, utilizing a number of requirements of evaluation:
User:
Responsiveness/Usability. Updates of information 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 different sections of the site.
Offline work. Speaks for itself.
Developer:
Speed of development. Maximum speed of response from the server with minimum usage of computation power.
In case the designated scalable system is utilized, one need to offer data consistence, availability and partition tolerance (CAP theorem). It's likewise worth keeping in mind that the case, when the number of features/screens of the customer app is increased at the software owner's request, depends on the structure and application rather than the type of web architecture.
Testability. Possibility and easiness of automatic system testing.
Software application owner:
Practical extendability. Including functionality within very little time and budget plan.
SEO. Users need to be able to discover the application through any online search engine.
Support. Costs on app infrastructure - hardware, network facilities, maintenance personnel.
Security. The software owner must make certain that both business information and details about users are kept safe. As the primary security requirement we'll think about the possibility of modifications in performance of app behavior on the client side, and all associated risks. Standard risks are the very same for the compared architectures. We do rule out security on the 'server-client' channel, because all these architectures are similarly exposed to burglaries - this channel can be the very same.
Conversion: site - mobile or desktop application. Possibility to release the application on mobile markets or to make a desktop application out of it with very little additional costs.
Some of these requirements might appear inaccurate, but the function of the article is not to reveal what's great and what's bad. It's more of a detailed evaluation that shows the possible options of choice.
Let's lay out three main types of web applications according to the functions carried out by the client and the server browser.
Type 1: Server-side HTML
The most widespread architecture. The server produces HTML-content and sends it to the client as a full-fledged HTML-page. Often this architecture is called" Web 1.0", given that it was the first to appear and currently controls the web.
The least ideal worth among these architectures. Due to the constraints of mobile internet and huge amounts of moved information, this home architecture design app is hardly suitable in the mobile section. If we think about the possibility of real-time updates through generation of prepared pieces 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 3, given that it's the easiest implementable. It's due to the truth that by default one URL gets specific HTML-content on the server.
SEO: 5/5. Rather easily executed, likewise to the previous requirement - the material is known ahead of time.
Speed of advancement: 5/5. This is the earliest architecture, so it's possible to select any server language and framework for particular needs.
Scalability: 4/5. Under the increasing load comes the moment when load balance will be required if we take a look at the generation of HTML. There's a far more complicated situation with scaling databases, however this job is the very same for these 3 architectures.
Performance is relatively low due to the fact that a huge amount of data should be transferred, containing HTML, style, and company data. It's essential to create information for the whole page (not only for the altered organisation data), and all the accompanying info (such as style).
Testability: 4/5. The positive thing is that there's no need in unique tools, which support JavaScript analysis, to evaluate the front-end, and the material is fixed.
The application behavior logic is on the server side. Data are transferred overtly, so a protected channel might be needed (which is essentially a story of any architecture that worries the server).
Conversion: website - mobile or desktop application: 0/5. It's merely impossible. Rarely there's an exception (more of exotics): for instance, if the server is understood upon node.js, and there are no big databases; or if one utilizes third-party web services for data acquisition (however, it's a more sophisticated version of architecture). Therefore one can cover the application in node-webkit or analogous means.
Offline work: 2/5. Executed with a manifest on the server, which is entered to HTML5 specs. If the browser supports such a requirements, 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).
Evolved architecture of the very first type. The difference is that the page, which is displayed in the web browser, consists of widgets (functionally independent systems). Information are published to these widgets through AJAX inquiry from the server: either as a full-fledged portion of HTML, or as JSON, and changes (through JavaScript-templating/binding) into the content of the page. The choice of submitting portions of HTML leaves out the requirement of using JavaScript-MV *- frameworks on the client side; in this case something simpler can be used - for example, jQuery. By reducing interactivity we enhance the advancement speed and make functionality more affordable and more reliable.
The primary advantage is that updates from the server arrive only for the part of the page asked for by the customer. It's also excellent that widgets are separated functionally. A particular widget is in charge of a part of the page; changes in a part will not impact the entire page.
Because a page is a set of widgets, the relevant UI templates in a web application are restricted by the picked UI structure. The material, which is fully created and cached on the server, can be instantly shown on the client; here time is invested on getting the information for the widget and, as a rule, on templating. At the very first visit the site will not be that fast to load, however even more it will be much more enjoyable in usage, if compared to websites based on the architecture of the first type.
Linkability: 2/5. Here special tools and systems are required. As a guideline, Hash-Bang mechanism is applied.
SEO: 2/5. There are unique systems for these tasks. For instance, for promo of sites based upon this architecture it's possible to predefine the list of promoted pages and make fixed URLs for them, without modificators and parameters.
Speed of development: 3/5. Not only does one need to understand the server-side innovations, but also to use JavaScript structures on the client side. It's likewise required to execute web services on the server side.
Such terms as" web app"," front-end architecture"," Web 2.0", and" HTML5 apps" have actually just recently ended up being trendy. Today we'll attempt to find out more about the types of web application architecture in the light of the most current web trends and key problems that matter to software application owners.
It's also worth noting that the case, when the number of features/screens of the customer app is increased at the software owner's demand, depends on the structure and implementation rather than the type of web architecture.
In some cases this architecture is called" Web 1.0", considering that it was the very first to appear and presently controls the web.
Hardly ever 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 makes use of third-party web services for information acquisition (nevertheless, it's a more advanced version of architecture).
