The impact of the Web application architecture on investment volumes, product life cycle and user positive emotions
Recently it has become fashionable to use the terms "Web-application", "front-end-architecture", "Web 2.0", "HTML5-applications". But, unfortunately, in most cases the context of using these terms is not always true, because it does not take into account all the specifics of the implementation and use of the architecture of a Web application. Today we will talk about architecture.
The impetus for writing this article was the blog post http://blog.pamelafox.org/2013/05/frontend-architectures-server-side-html.html . It is worth noting that it is quite compressed and does not take into account the possibility of converting HTML5 / Mobile. Here we tried to consider the architecture in more detail, taking into account the latest trends in the Web and some key points for the customer of the application (such as security).
To begin with, we will look at the most common architectures for Web applications, their advantages and disadvantages from three points of view: customer, developer, and user. Other options are possible, but they are still subtypes of the considered architectures and come down to the main three.
')
Let's start by defining the Web application as such. Wikipedia will give us the following definition: a client-server application in which the client is a browser, and the server is a web server. The web application logic is distributed between the server and the client, data is stored primarily on the server, and information is exchanged over the network.
Here begins the confusion associated directly with the architecture with which the Web application is implemented. The fact is that the logic of the application can be located both on the server and on the client. Different architectures distribute the logic between client and server in different ways.
Unfortunately, it is impossible to objectively evaluate completely different architectures. We will use the following criteria for evaluation:
User:
Responsiveness / usability: updating data on the page and switching between pages (response time). The richness and convenience of the interface, its intuitiveness.
Linkability: the ability to save bookmarks and links to different sections of the site.
Offline: the ability to run the application without a network.
Developer:
Development speed : the speed of adding a new functional, refactoring, paralleling the development process between developers and layout designers, etc.
Performance: the fastest possible response from the server with minimal computational power.
Scalability: the ability to increase computing power or disk space due to the increasing amount of information or the number of users. In the case of using a distributed scalable system, data consistency, availability and separation resistance should be ensured (CAP-theorem). It should be noted that the number of features / screenshots of the application with increasing customer requirements (on the client side) does not apply to this definition - it rather depends not on the type of Web architecture, but on the framework used and execution.
Testability: the ability and ease of testing (modular auto-testing).
Customer:
Functional extensibility: the ability to increase functionality with minimal time and money costs.
SEO: users should be able to find the application using any search engine.
Support: the cost of maintaining the infrastructure of the application - the cost of hardware, network infrastructure, staff needed to maintain the application.
Security: The customer of the application must be confident in the safety of business data and the inaccessibility of data about other users. As the main security criterion, we will consider only the possibility of changing the functionality of the application's behavior on the client, as well as the associated risks. Standard threats (for example, analyzed in https://www.owasp.org/index.php/Main_Page ) are the same for all compared architectures. We do not take security into account on the server-client data transfer area due to the fact that all the architectures in question are equally susceptible to hacking — the data transfer channel may be the same.
Conversion: site - mobile or desktop application: the ability to publish the application on mobile markets, or wrap it in a desktop application with minimal additional cost.
Perhaps some of the criteria or our estimates may seem incorrect to you; but the purpose of this article is not to show “what is good and what is bad”, but to make a more detailed review and show the possibility of choice.
Let's try to highlight the main types of Web applications, depending on the roles performed by the server and browser (client).
Type 1: Server-side HTML
The most common at the moment architecture. The reason is that the server generates HTML content and sends it to the client as a full HTML page.
Sometimes this architecture is called “Web 1.0”, due to the fact that it appeared first, and is currently dominant in the Web.
Responsiveness / usability: 1/5. The least optimal of the considered architectures. This is due to the fact that between the server and the client, it is necessary to transfer a huge amount of data that is responsible not only for the business data itself, but also for their design. The user has to wait for the page to reload in response to trivial actions, for example, updating only a small part of the page. UI templates on the client depend directly on the frameworks used on the server. Due to the limited mobile Internet and large amounts of data sent, this architecture is practically not operational in the mobile segment. There is no way to deliver instant data updates or changes in real time. If we consider the possibility of changes in real time by generating on the server side and updating the client (via AJAX, WebSockets) in the form of ready-made pieces of content, plus design with the replacement of part of the page, then we will go beyond the boundaries of the architecture under consideration.
Linkability: 5/5. Of the architectures in question, linkability is the easiest to implement in this. This is due to the fact that on the server by default a specific HTML content is assigned to one URL.
SEO: 5/5. It is implemented quite simply, similarly to the previous point - the page content is known in advance.
Development speed: 5/5. The oldest architecture, so it is possible to choose any server language and framework for specific needs.
Scalability : 4/5. If we consider the generation of HTML, then with increasing load in the end there is a moment when it is necessary to implement balancing for load distribution. The situation with database scaling is much more complicated, but this task is the same and typical for all three architectures under consideration.
Productivity: 3/5. Closely related to responsiveness and scaling in terms of traffic, speed, etc. The performance is low because it requires the transfer of the largest amount of data that contains HTML, design, as well as the business data itself. Thus, it is necessary to generate data for the entire page (and not only for the changed business data), as well as all related information (for example, design).
Testability: 4/5. The positive aspect of this architecture is that, in general, special tools that support the interpretation of JavaScript are not needed for testing the front-end (since the content of the pages is static).
Security: 4/5. "You can not break what is not" - all the logic of the application is on the server. At the same time, data is sent in open form, so a secure channel is recommended if necessary (as a matter of fact, for any architecture associated with the server). All security functionality falls on the server side.
Conversion: site - mobile or desktop application: 0/5. In most cases, this is simply not possible. The exception (or rather, exotic) are rare cases: for example, if you have a server implemented on node.js, and there are no large databases; or if you use third-party web services to retrieve data (but this is already a more advanced version of the architecture). Thus, you will wrap your application using node-webkit or analogs.
Offline: 2/5. It is implemented using a server manifest entered in the HTML5 specification. If the browser supports this specification, all pages of the application will be cached, and if the user is disconnected from the network, the cached page will be displayed to the user.
Type 2: JS generation widgets (AJAX)
The development of architecture of the first type. The difference is that the page displayed in the browser consists of widgets (functionally independent blocks). The data in these widgets are loaded by an AJAX request from the server: or a full piece of HTML; either in the form of JSON, and already with the help of JavaScript-template making / binding are converted into page content. The option of loading pieces of HTML eliminates the need to use JavaScript-MV * frameworks on the client side, and in this case it is possible to get by with something simpler, for example, jQuery. By reducing interactivity, we accelerate development speed and make the functionality cheaper and more reliable.
The main advantage is that only data is sent from the server to update the part of the page that the client is requesting to update. It is also good that the widgets are functionally separated, and changing the functionality of the part of the page for which a particular widget is responsible will not affect all of it.
Responsiveness / usability : 3/5. The amount of data sent to update only part of the page is much smaller than for the entire page, so there is more responsiveness. But due to the fact that the page is a set of widgets, the UI templates used in the Web application are limited to the UI framework used. It is worth mentioning that the “cold start” (first full download) of such a web page will be a little longer. Fully generated and cached content on the server can be instantly displayed on the client; here, time is spent on getting data for the widget and, as a rule, on templating. Thus, when you first enter the site will not open very quickly, but then it will be much nicer to work when compared with the first type of architecture. It is also worth mentioning the possibility of implementing the download "in parts" (as it is done at http://www.yahoo.com/ ).
Linkability : 2/5. Special tools and mechanisms are needed. Usually, a hash-bang mechanism is used.
SEO : 2/5. There are special mechanisms for these tasks. For example, to promote sites of a given architecture, it is possible to determine in advance the list of pages being promoted and make static URLs for them, without parameters and modifiers.
Development speed: 3/5. It requires not only the knowledge of server side technologies, but also the use of JavaScript frameworks on the client side. An implementation of server-side web services similarity is also required.
Productivity: 4/5. The time and resources spent on generating HTML content are relatively small compared to the time the application spends extracting data from the database and processing it before templating. Using the extended type of this architecture (when data is transmitted as JSON), although it reduces traffic between the client and the server, it adds an additional level of abstraction to the application: extraction from the database -> data processing, serialization in JSON -> API: JSON -> parsing JSON -> binding the data object on the client to HTML.
Scalability: similar to the first type of architecture.
Testability: 1/5. Required testing server side, client code and web service, which returns the data to update the widgets.
Security: 4/5. Part of the logic is rendered into client-side JavaScript, which can be easily modified by an attacker.
Conversion: site - mobile or desktop application: similar to the first type of architecture.
Offline: 1/5. The manifest mechanism also works in this case, but the problem occurs when updating or caching the data displayed on the widget. This functionality must be implemented additionally, since in the manifest, you can specify only the names of files that will be cached from the server. The organization of the relationship between the name of the widget's template file cached in the manifest and the logic of page behavior requires additional work.
Type 3: Service-oriented single-page Web apps (Web 2.0, HTML5 apps)
Here I want to make a small remark that the term “Web 2.0” is not entirely correct to use here. It was introduced for the first time by Tim O'Reilly as “a technique for designing systems that, by taking into account network interactions, become better, the more people use them.” And the feature of Web 2.0 is the principle of attracting users to the content and repeated reconciliation of information material. In essence, the term “Web 2.0” refers to projects and services that are actively developed and improved by the users themselves: blogs, wikis, social networks, etc. From this it follows that Web 2.0 is not tied to any single technology or set of technologies.
The essence of the architecture under consideration is that an HTML page is loaded from the server, which is a container for JavaScript code that, when accessing a specific web service, receives only business data from it. From which, in turn, the JavaScript application generates the HTML content of the page. In essence, the third type of architecture is the development of the previous type and bringing it to the full-fledged level of independent, fairly complex JavaScript application by transferring some of the functionality to the client side. The architecture of the second type usually cannot boast of a very large number of interrelated, structured functions.
It should also be noted that JavaScript-based applications that work completely offline are now practically not made (with rare exceptions: http://www.wakanda.org/ , http://html.adobe.com/edge/code/ , http: / /cdn.sencha.io/touch/sencha-touch-2.2.1/examples/kitchensink/index.html , http://rad-js.com/ ), this approach allows you to perform an easy reverse conversion - publish an existing application in web
Responsiveness / usability: 5/5. The amount of data sent to update the information is minimal, so the maximum responsiveness. The UI is generated using JavaScript, it is possible to implement any necessary options. A subtle point is the issue of multithreading in JavaScript: in the case we are considering, processing large volumes of business data must be brought to the side of the web service)
Linkability: 1/5. Not only special tools and mechanisms are needed, but also frameworks that can use, for example, the Hash-Bang mechanism.
SEO: 1/5. The most difficult to promote architecture. If the whole application is being promoted directly, there are no problems: the application container may be promoted. If rotation of parts of the application is necessary, then of all the mechanisms at the moment there are only similar to the following: http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html and http: // seodacha .ru / news / yandeks-predlagaet-reshenie-dlya-indeksacii-ajax-saytov . Each more or less large search engine offers its own methods of standardization of this process.
Development speed: 2/5. It requires the development of a web service and the use of more specialized (building the application architecture) JavaScript frameworks. It is worth mentioning that due to the novelty of the architecture, so far there are few specialists who can make a really high-quality website / system with this approach; few developed and developed tools, frameworks and approaches.
Productivity: 5/5. With this architecture, this characteristic has the least impact from the server side, since the server is only required to send the JS application to the browser. On the client side, performance and type of browser is most important.
Scalability: 5/5. All Web-logic is placed on the client side, no load is generated on the server for generating content. As the number of users increases, only web services that provide business data are scaled.
Testability: 3/5. Testing of web services and client-side JavaScript code is required.
Security: 0/5. All logic is rendered into client-side JavaScript, which can be easily modified by an attacker. Therefore, for secure systems, it is necessary to develop a preventive architecture that takes into account the peculiarities of the organization of open-source applications http://aosabook.org/en/index.html — for example, a variant with a third-party key distribution channel.
Conversion: site - mobile or desktop application: 5/5. The site quietly turns into an application using platforms such as http://phonegap.com/ , https://github.com/rogerwang/node-webkit , https://code.google.com/p/chromiumembedded/ and others similar
Offline: 5/5. This architecture is a complete application; it is possible to save both individual data and parts of the application itself using any storage (for example, localstorage). Another plus is that you can completely switch the storage and management of data to offline mode; while the two previous architectures are only partially functional offline. Here, the missing data can be replaced with plugs, you can show warning windows or use data from the local storage, leaving the synchronization for later.
- , , — . , «», , , , - .
, , — . , -.
; .
The impetus for writing this article was the blog post http://blog.pamelafox.org/2013/05/frontend-architectures-server-side-html.html . It is worth noting that it is quite compressed and does not take into account the possibility of converting HTML5 / Mobile. Here we tried to consider the architecture in more detail, taking into account the latest trends in the Web and some key points for the customer of the application (such as security).
To begin with, we will look at the most common architectures for Web applications, their advantages and disadvantages from three points of view: customer, developer, and user. Other options are possible, but they are still subtypes of the considered architectures and come down to the main three.
')
Let's start by defining the Web application as such. Wikipedia will give us the following definition: a client-server application in which the client is a browser, and the server is a web server. The web application logic is distributed between the server and the client, data is stored primarily on the server, and information is exchanged over the network.
Here begins the confusion associated directly with the architecture with which the Web application is implemented. The fact is that the logic of the application can be located both on the server and on the client. Different architectures distribute the logic between client and server in different ways.
Unfortunately, it is impossible to objectively evaluate completely different architectures. We will use the following criteria for evaluation:
User:
Responsiveness / usability: updating data on the page and switching between pages (response time). The richness and convenience of the interface, its intuitiveness.
Linkability: the ability to save bookmarks and links to different sections of the site.
Offline: the ability to run the application without a network.
Developer:
Development speed : the speed of adding a new functional, refactoring, paralleling the development process between developers and layout designers, etc.
Performance: the fastest possible response from the server with minimal computational power.
Scalability: the ability to increase computing power or disk space due to the increasing amount of information or the number of users. In the case of using a distributed scalable system, data consistency, availability and separation resistance should be ensured (CAP-theorem). It should be noted that the number of features / screenshots of the application with increasing customer requirements (on the client side) does not apply to this definition - it rather depends not on the type of Web architecture, but on the framework used and execution.
Testability: the ability and ease of testing (modular auto-testing).
Customer:
Functional extensibility: the ability to increase functionality with minimal time and money costs.
SEO: users should be able to find the application using any search engine.
Support: the cost of maintaining the infrastructure of the application - the cost of hardware, network infrastructure, staff needed to maintain the application.
Security: The customer of the application must be confident in the safety of business data and the inaccessibility of data about other users. As the main security criterion, we will consider only the possibility of changing the functionality of the application's behavior on the client, as well as the associated risks. Standard threats (for example, analyzed in https://www.owasp.org/index.php/Main_Page ) are the same for all compared architectures. We do not take security into account on the server-client data transfer area due to the fact that all the architectures in question are equally susceptible to hacking — the data transfer channel may be the same.
Conversion: site - mobile or desktop application: the ability to publish the application on mobile markets, or wrap it in a desktop application with minimal additional cost.
Perhaps some of the criteria or our estimates may seem incorrect to you; but the purpose of this article is not to show “what is good and what is bad”, but to make a more detailed review and show the possibility of choice.
Let's try to highlight the main types of Web applications, depending on the roles performed by the server and browser (client).
Type 1: Server-side HTML
The most common at the moment architecture. The reason is that the server generates HTML content and sends it to the client as a full HTML page.
Sometimes this architecture is called “Web 1.0”, due to the fact that it appeared first, and is currently dominant in the Web.
Responsiveness / usability: 1/5. The least optimal of the considered architectures. This is due to the fact that between the server and the client, it is necessary to transfer a huge amount of data that is responsible not only for the business data itself, but also for their design. The user has to wait for the page to reload in response to trivial actions, for example, updating only a small part of the page. UI templates on the client depend directly on the frameworks used on the server. Due to the limited mobile Internet and large amounts of data sent, this architecture is practically not operational in the mobile segment. There is no way to deliver instant data updates or changes in real time. If we consider the possibility of changes in real time by generating on the server side and updating the client (via AJAX, WebSockets) in the form of ready-made pieces of content, plus design with the replacement of part of the page, then we will go beyond the boundaries of the architecture under consideration.
Linkability: 5/5. Of the architectures in question, linkability is the easiest to implement in this. This is due to the fact that on the server by default a specific HTML content is assigned to one URL.
SEO: 5/5. It is implemented quite simply, similarly to the previous point - the page content is known in advance.
Development speed: 5/5. The oldest architecture, so it is possible to choose any server language and framework for specific needs.
Scalability : 4/5. If we consider the generation of HTML, then with increasing load in the end there is a moment when it is necessary to implement balancing for load distribution. The situation with database scaling is much more complicated, but this task is the same and typical for all three architectures under consideration.
Productivity: 3/5. Closely related to responsiveness and scaling in terms of traffic, speed, etc. The performance is low because it requires the transfer of the largest amount of data that contains HTML, design, as well as the business data itself. Thus, it is necessary to generate data for the entire page (and not only for the changed business data), as well as all related information (for example, design).
Testability: 4/5. The positive aspect of this architecture is that, in general, special tools that support the interpretation of JavaScript are not needed for testing the front-end (since the content of the pages is static).
Security: 4/5. "You can not break what is not" - all the logic of the application is on the server. At the same time, data is sent in open form, so a secure channel is recommended if necessary (as a matter of fact, for any architecture associated with the server). All security functionality falls on the server side.
Conversion: site - mobile or desktop application: 0/5. In most cases, this is simply not possible. The exception (or rather, exotic) are rare cases: for example, if you have a server implemented on node.js, and there are no large databases; or if you use third-party web services to retrieve data (but this is already a more advanced version of the architecture). Thus, you will wrap your application using node-webkit or analogs.
Offline: 2/5. It is implemented using a server manifest entered in the HTML5 specification. If the browser supports this specification, all pages of the application will be cached, and if the user is disconnected from the network, the cached page will be displayed to the user.
Type 2: JS generation widgets (AJAX)
The development of architecture of the first type. The difference is that the page displayed in the browser consists of widgets (functionally independent blocks). The data in these widgets are loaded by an AJAX request from the server: or a full piece of HTML; either in the form of JSON, and already with the help of JavaScript-template making / binding are converted into page content. The option of loading pieces of HTML eliminates the need to use JavaScript-MV * frameworks on the client side, and in this case it is possible to get by with something simpler, for example, jQuery. By reducing interactivity, we accelerate development speed and make the functionality cheaper and more reliable.
The main advantage is that only data is sent from the server to update the part of the page that the client is requesting to update. It is also good that the widgets are functionally separated, and changing the functionality of the part of the page for which a particular widget is responsible will not affect all of it.
Responsiveness / usability : 3/5. The amount of data sent to update only part of the page is much smaller than for the entire page, so there is more responsiveness. But due to the fact that the page is a set of widgets, the UI templates used in the Web application are limited to the UI framework used. It is worth mentioning that the “cold start” (first full download) of such a web page will be a little longer. Fully generated and cached content on the server can be instantly displayed on the client; here, time is spent on getting data for the widget and, as a rule, on templating. Thus, when you first enter the site will not open very quickly, but then it will be much nicer to work when compared with the first type of architecture. It is also worth mentioning the possibility of implementing the download "in parts" (as it is done at http://www.yahoo.com/ ).
Linkability : 2/5. Special tools and mechanisms are needed. Usually, a hash-bang mechanism is used.
SEO : 2/5. There are special mechanisms for these tasks. For example, to promote sites of a given architecture, it is possible to determine in advance the list of pages being promoted and make static URLs for them, without parameters and modifiers.
Development speed: 3/5. It requires not only the knowledge of server side technologies, but also the use of JavaScript frameworks on the client side. An implementation of server-side web services similarity is also required.
Productivity: 4/5. The time and resources spent on generating HTML content are relatively small compared to the time the application spends extracting data from the database and processing it before templating. Using the extended type of this architecture (when data is transmitted as JSON), although it reduces traffic between the client and the server, it adds an additional level of abstraction to the application: extraction from the database -> data processing, serialization in JSON -> API: JSON -> parsing JSON -> binding the data object on the client to HTML.
Scalability: similar to the first type of architecture.
Testability: 1/5. Required testing server side, client code and web service, which returns the data to update the widgets.
Security: 4/5. Part of the logic is rendered into client-side JavaScript, which can be easily modified by an attacker.
Conversion: site - mobile or desktop application: similar to the first type of architecture.
Offline: 1/5. The manifest mechanism also works in this case, but the problem occurs when updating or caching the data displayed on the widget. This functionality must be implemented additionally, since in the manifest, you can specify only the names of files that will be cached from the server. The organization of the relationship between the name of the widget's template file cached in the manifest and the logic of page behavior requires additional work.
Type 3: Service-oriented single-page Web apps (Web 2.0, HTML5 apps)
Here I want to make a small remark that the term “Web 2.0” is not entirely correct to use here. It was introduced for the first time by Tim O'Reilly as “a technique for designing systems that, by taking into account network interactions, become better, the more people use them.” And the feature of Web 2.0 is the principle of attracting users to the content and repeated reconciliation of information material. In essence, the term “Web 2.0” refers to projects and services that are actively developed and improved by the users themselves: blogs, wikis, social networks, etc. From this it follows that Web 2.0 is not tied to any single technology or set of technologies.
The essence of the architecture under consideration is that an HTML page is loaded from the server, which is a container for JavaScript code that, when accessing a specific web service, receives only business data from it. From which, in turn, the JavaScript application generates the HTML content of the page. In essence, the third type of architecture is the development of the previous type and bringing it to the full-fledged level of independent, fairly complex JavaScript application by transferring some of the functionality to the client side. The architecture of the second type usually cannot boast of a very large number of interrelated, structured functions.
It should also be noted that JavaScript-based applications that work completely offline are now practically not made (with rare exceptions: http://www.wakanda.org/ , http://html.adobe.com/edge/code/ , http: / /cdn.sencha.io/touch/sencha-touch-2.2.1/examples/kitchensink/index.html , http://rad-js.com/ ), this approach allows you to perform an easy reverse conversion - publish an existing application in web
Responsiveness / usability: 5/5. The amount of data sent to update the information is minimal, so the maximum responsiveness. The UI is generated using JavaScript, it is possible to implement any necessary options. A subtle point is the issue of multithreading in JavaScript: in the case we are considering, processing large volumes of business data must be brought to the side of the web service)
Linkability: 1/5. Not only special tools and mechanisms are needed, but also frameworks that can use, for example, the Hash-Bang mechanism.
SEO: 1/5. The most difficult to promote architecture. If the whole application is being promoted directly, there are no problems: the application container may be promoted. If rotation of parts of the application is necessary, then of all the mechanisms at the moment there are only similar to the following: http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html and http: // seodacha .ru / news / yandeks-predlagaet-reshenie-dlya-indeksacii-ajax-saytov . Each more or less large search engine offers its own methods of standardization of this process.
Development speed: 2/5. It requires the development of a web service and the use of more specialized (building the application architecture) JavaScript frameworks. It is worth mentioning that due to the novelty of the architecture, so far there are few specialists who can make a really high-quality website / system with this approach; few developed and developed tools, frameworks and approaches.
Productivity: 5/5. With this architecture, this characteristic has the least impact from the server side, since the server is only required to send the JS application to the browser. On the client side, performance and type of browser is most important.
Scalability: 5/5. All Web-logic is placed on the client side, no load is generated on the server for generating content. As the number of users increases, only web services that provide business data are scaled.
Testability: 3/5. Testing of web services and client-side JavaScript code is required.
Security: 0/5. All logic is rendered into client-side JavaScript, which can be easily modified by an attacker. Therefore, for secure systems, it is necessary to develop a preventive architecture that takes into account the peculiarities of the organization of open-source applications http://aosabook.org/en/index.html — for example, a variant with a third-party key distribution channel.
Conversion: site - mobile or desktop application: 5/5. The site quietly turns into an application using platforms such as http://phonegap.com/ , https://github.com/rogerwang/node-webkit , https://code.google.com/p/chromiumembedded/ and others similar
Offline: 5/5. This architecture is a complete application; it is possible to save both individual data and parts of the application itself using any storage (for example, localstorage). Another plus is that you can completely switch the storage and management of data to offline mode; while the two previous architectures are only partially functional offline. Here, the missing data can be replaced with plugs, you can show warning windows or use data from the local storage, leaving the synchronization for later.
- , , — . , «», , , , - .
, , — . , -.
; .
Source: https://habr.com/ru/post/195548/
All Articles