SPA-architecture for CRM-systems: part 1
Introduction
Recently had a chance to encounter a project to refine the once written by CRM. The purpose of the revision was to increase the speed of the system when interacting with the user and add a bit of new functionality, as well as to defeat JavaScript memory found by previous developers and not defeated, in which the entire user interface was implemented.
Having started to engage in the project, having rummaged in the depths of a huge number of libraries and frameworks that are not very well interacting with each other, after conducting a series of experiments, we came to the unexpected conclusion that the cause was ... SPA architecture.
A couple of words about the SPA-architecture
')
Speaking of modern Web, you can hear more and more about the technology of Single Page Application (SPA), although to be precise, SPA is a collective name for a set of technologies that allow you to implement a WEB application executed by a WEB browser as one WEB page, as For example, the Gmail service from Google is implemented. From the user's point of view, this technology primarily attracts quick response to actions in the user interface, as it does not require a full or even partial reloading of the WEB page from the server, and all visual elements are constructed directly in the browser using JavaScript by manipulating DOM document structure.
Thus, WEB-applications become very similar to regular applications for workstations that download information from the Internet, only the execution environment for them is not the operating system, but the browser, which as a result has to bear all the load associated with the execution of third-party code , namely, memory management, providing a safe environment, providing functionality for working with system functions and hardware environment, etc.
The central place of the SPA-architecture is occupied by the view (View) - what the user sees and with what interacts. The result of the presentation is the most common HTML displayed by the browser. Unlike the “transitional” “WEB 2.0” applications that actively work with the DOM structure of the document, for example, using jQuery or underscore, the SPA application uses the DOM only to record changes, but not to read, that is, not to store data . For data storage, one more component of the SPA-architecture is now used - the model (Model).
A model is a collection of data, functions for manipulating data and events. All data models are fully stored in memory. In order for the data in the model and the data displayed by the view to maintain integrity, the view subscribes to the events of the model, thus tracking changes in the data in the model. In turn, the model also responds to presentation notifications and provides an inseparable connection between the WEB application and the server, fulfilling requests for receiving or sending data (in particular, using the REST methodology).
But back to the submission. Presentation is the most important and most difficult part of modern SPA. Typically, the presentation is built around the so-called templates - blanks that are converted to HTML. The view also updates the resulting HTML when the model is changed and vice versa — notifies the model of the user's actions with the view, for example, a mouse click, keyboard input or device rotation, with the result that the model can perform data manipulations and then re-notify the data change view for for the presentation to update or generate new HTML.
The work of the classic WEB-application (or WEB-site) is completely built on top of data caching: on the server, on the proxy server and on the client. If the data and the state of the application are updated very often, the advantage of using caching is almost negated. Theoretically, a one-page application should exploit the cache less, since the data is loaded once during the page life cycle, but in practice this is not always the case, and we'll talk about it below.
CRM features that do not fit into the SPA implementation
Let's see how we can use the SPA technology to implement a simple customer relationship management system, or CRM. First of all, we are interested in the operational and analytical levels of information processing.
Take for example a strongly simplified set of sections of simple CRM:
• Desktop (Dashboard) - a summary of all system data that makes sense for a specific user.
• Events — view the collaborative actions of users in marketing, sales, and production departments.
• Clients - management of client base, contacts and companies.
• Projects and deals - customer relationship management.
• Tasks - implementation workflow management.
• Reports - view and manage analytical reports on the accumulated information.
• Profile - user profile management.
In each section, the user works with samples of frequently changing data. One of the critical requirements for CRM at the operational level is high speed when interacting with the user when performing such operations as frequent access to the registry of information, active use of complex filtering and sorting of a large volume of results. Also at the analytical level, it is required to quickly receive reports, statistics, analysis and forecasting for various metrics and indicators.
In the one-page application, instead of the pages, we operate with “screens”. Each screen is part of a subsystem with its own set of patterns, modules, controllers, route and model. When the user navigates to another section of the application, the data, templates, and modules required for the operation of this section are loaded, while it is important that the user is on the same page, and the current state during the loading of the new screen is saved.
The overall model of the entire system is integrated, consisting of independent models for each screen. Switching between screens causes the current layer of the presentation to be cleared and a new layer is generated, which is quite often implemented in such a way that the previous layer simply becomes invisible and a new one is displayed instead, that is, the process of switching between screens is arranged in such a way that the ready-made views after the initial loading further simply hidden and displayed.
This is very different from the classic way of working with a WEB-application, where links to links cause full page load, which automatically causes the release of resources and update data, and the user can expect that the data is always relevant. In conditions of rapidly changing data in CRM, in order to confirm user expectations during the SPA implementation, in the process of switching between screens, there is also a need to reload all data from the server, which negates the advantage of storing all data on the client, and, therefore, using SPA architecture.
Emerging issues when using SPA in CRM
The SPA technology forces the developer to write code with extreme caution, as any mistake or oversight can lead to memory leaks, and as a result - to the “brakes” of the entire system.
Why is memory flowing?
A huge amount of data accumulated on the client during long-term work, very quickly become irrelevant. But meanwhile, this data is saved in the model, and the views are saved in the DOM structure of the document, if you don’t pursue the task of cleaning. In order to keep the model and the DOM “clean”, it is necessary to do periodic “garbage collection”, since you should not rely on the JIT garbage collector, because references to objects, as a rule, remain achievable, therefore, previously created and objects that are no longer needed are still in memory. It is also necessary to take into account that in JavaScript there is always the risk of losing all links, but the data will not be cleared.
Why does everything slow down?
The page slowdown is mainly caused by memory leaks and a complex model with a large number of event handlers. When switching from screen to screen, when opening each new form, data is loaded into the browser process, as well as executable code (in the case of AMD), which is not uncommonly implemented using eval () constructs. Modular frameworks for building SPA also have their own infrastructure with their own costs. The most common cause is a developer’s errors and flaws, which are very easy to make and extremely difficult to track. Profiling and debugging complex SPAs is an expensive pleasure: although today the debugging tools are already quite advanced, the complexity of debugging increases with the complexity of the application exponentially. As a result, the problem is solved only by modular debugging and testing, which in turn increases development costs.
How are these problems reflected in the development of CRM?
When developing CRM, a large number of screens and forms, differing logic depending on the type of user, his rights and permissions, very quickly outdated data, the need for periodic updating of the state of the entire system are the main factors complicating the development of CRM on SPA technologies. In addition, during operation, as the data grows, the model grows, and, consequently, the time for data processing increases, as a result, the system begins to slow down even where the tests behaved acceptable.
The problem of "multiple screens"
Users of tabbed browsers, being on the same page, often open separate pages by links in separate tabs of the browser, combining them with link clicks within one tab. I would like to have a similar opportunity when working with a WEB application: for example, to open a project page in a separate tab and keep it “on the pulse”. In the case of the SPA, this is also possible, but in this case, the development overhead increases dramatically - where there was a saving in the case of loading pages, an overrun is now obtained, since in each tab the application will load all the code it needs to work; the meaning of the SPA as a one-page application is lost, because for the Internet user it is obvious that when working in the browser, the link should open a new page, and not behave like a normal application.
Thus, when developing a CRM system, the SPA architecture is, in our opinion, less preferable than the classical architecture of a multi-page application with active use of AJAX for updating data.
The statement of the problem turned out to be quite extensive, so we will leave the story of its solution for a separate material. Thank you all, who read, follow the publications.
Recently had a chance to encounter a project to refine the once written by CRM. The purpose of the revision was to increase the speed of the system when interacting with the user and add a bit of new functionality, as well as to defeat JavaScript memory found by previous developers and not defeated, in which the entire user interface was implemented.
Having started to engage in the project, having rummaged in the depths of a huge number of libraries and frameworks that are not very well interacting with each other, after conducting a series of experiments, we came to the unexpected conclusion that the cause was ... SPA architecture.
A couple of words about the SPA-architecture
')
Speaking of modern Web, you can hear more and more about the technology of Single Page Application (SPA), although to be precise, SPA is a collective name for a set of technologies that allow you to implement a WEB application executed by a WEB browser as one WEB page, as For example, the Gmail service from Google is implemented. From the user's point of view, this technology primarily attracts quick response to actions in the user interface, as it does not require a full or even partial reloading of the WEB page from the server, and all visual elements are constructed directly in the browser using JavaScript by manipulating DOM document structure.
Thus, WEB-applications become very similar to regular applications for workstations that download information from the Internet, only the execution environment for them is not the operating system, but the browser, which as a result has to bear all the load associated with the execution of third-party code , namely, memory management, providing a safe environment, providing functionality for working with system functions and hardware environment, etc.
The central place of the SPA-architecture is occupied by the view (View) - what the user sees and with what interacts. The result of the presentation is the most common HTML displayed by the browser. Unlike the “transitional” “WEB 2.0” applications that actively work with the DOM structure of the document, for example, using jQuery or underscore, the SPA application uses the DOM only to record changes, but not to read, that is, not to store data . For data storage, one more component of the SPA-architecture is now used - the model (Model).
A model is a collection of data, functions for manipulating data and events. All data models are fully stored in memory. In order for the data in the model and the data displayed by the view to maintain integrity, the view subscribes to the events of the model, thus tracking changes in the data in the model. In turn, the model also responds to presentation notifications and provides an inseparable connection between the WEB application and the server, fulfilling requests for receiving or sending data (in particular, using the REST methodology).
But back to the submission. Presentation is the most important and most difficult part of modern SPA. Typically, the presentation is built around the so-called templates - blanks that are converted to HTML. The view also updates the resulting HTML when the model is changed and vice versa — notifies the model of the user's actions with the view, for example, a mouse click, keyboard input or device rotation, with the result that the model can perform data manipulations and then re-notify the data change view for for the presentation to update or generate new HTML.
The work of the classic WEB-application (or WEB-site) is completely built on top of data caching: on the server, on the proxy server and on the client. If the data and the state of the application are updated very often, the advantage of using caching is almost negated. Theoretically, a one-page application should exploit the cache less, since the data is loaded once during the page life cycle, but in practice this is not always the case, and we'll talk about it below.
CRM features that do not fit into the SPA implementation
Let's see how we can use the SPA technology to implement a simple customer relationship management system, or CRM. First of all, we are interested in the operational and analytical levels of information processing.
Take for example a strongly simplified set of sections of simple CRM:
• Desktop (Dashboard) - a summary of all system data that makes sense for a specific user.
• Events — view the collaborative actions of users in marketing, sales, and production departments.
• Clients - management of client base, contacts and companies.
• Projects and deals - customer relationship management.
• Tasks - implementation workflow management.
• Reports - view and manage analytical reports on the accumulated information.
• Profile - user profile management.
In each section, the user works with samples of frequently changing data. One of the critical requirements for CRM at the operational level is high speed when interacting with the user when performing such operations as frequent access to the registry of information, active use of complex filtering and sorting of a large volume of results. Also at the analytical level, it is required to quickly receive reports, statistics, analysis and forecasting for various metrics and indicators.
In the one-page application, instead of the pages, we operate with “screens”. Each screen is part of a subsystem with its own set of patterns, modules, controllers, route and model. When the user navigates to another section of the application, the data, templates, and modules required for the operation of this section are loaded, while it is important that the user is on the same page, and the current state during the loading of the new screen is saved.
The overall model of the entire system is integrated, consisting of independent models for each screen. Switching between screens causes the current layer of the presentation to be cleared and a new layer is generated, which is quite often implemented in such a way that the previous layer simply becomes invisible and a new one is displayed instead, that is, the process of switching between screens is arranged in such a way that the ready-made views after the initial loading further simply hidden and displayed.
This is very different from the classic way of working with a WEB-application, where links to links cause full page load, which automatically causes the release of resources and update data, and the user can expect that the data is always relevant. In conditions of rapidly changing data in CRM, in order to confirm user expectations during the SPA implementation, in the process of switching between screens, there is also a need to reload all data from the server, which negates the advantage of storing all data on the client, and, therefore, using SPA architecture.
Emerging issues when using SPA in CRM
The SPA technology forces the developer to write code with extreme caution, as any mistake or oversight can lead to memory leaks, and as a result - to the “brakes” of the entire system.
Why is memory flowing?
A huge amount of data accumulated on the client during long-term work, very quickly become irrelevant. But meanwhile, this data is saved in the model, and the views are saved in the DOM structure of the document, if you don’t pursue the task of cleaning. In order to keep the model and the DOM “clean”, it is necessary to do periodic “garbage collection”, since you should not rely on the JIT garbage collector, because references to objects, as a rule, remain achievable, therefore, previously created and objects that are no longer needed are still in memory. It is also necessary to take into account that in JavaScript there is always the risk of losing all links, but the data will not be cleared.
Why does everything slow down?
The page slowdown is mainly caused by memory leaks and a complex model with a large number of event handlers. When switching from screen to screen, when opening each new form, data is loaded into the browser process, as well as executable code (in the case of AMD), which is not uncommonly implemented using eval () constructs. Modular frameworks for building SPA also have their own infrastructure with their own costs. The most common cause is a developer’s errors and flaws, which are very easy to make and extremely difficult to track. Profiling and debugging complex SPAs is an expensive pleasure: although today the debugging tools are already quite advanced, the complexity of debugging increases with the complexity of the application exponentially. As a result, the problem is solved only by modular debugging and testing, which in turn increases development costs.
How are these problems reflected in the development of CRM?
When developing CRM, a large number of screens and forms, differing logic depending on the type of user, his rights and permissions, very quickly outdated data, the need for periodic updating of the state of the entire system are the main factors complicating the development of CRM on SPA technologies. In addition, during operation, as the data grows, the model grows, and, consequently, the time for data processing increases, as a result, the system begins to slow down even where the tests behaved acceptable.
The problem of "multiple screens"
Users of tabbed browsers, being on the same page, often open separate pages by links in separate tabs of the browser, combining them with link clicks within one tab. I would like to have a similar opportunity when working with a WEB application: for example, to open a project page in a separate tab and keep it “on the pulse”. In the case of the SPA, this is also possible, but in this case, the development overhead increases dramatically - where there was a saving in the case of loading pages, an overrun is now obtained, since in each tab the application will load all the code it needs to work; the meaning of the SPA as a one-page application is lost, because for the Internet user it is obvious that when working in the browser, the link should open a new page, and not behave like a normal application.
Thus, when developing a CRM system, the SPA architecture is, in our opinion, less preferable than the classical architecture of a multi-page application with active use of AJAX for updating data.
The statement of the problem turned out to be quite extensive, so we will leave the story of its solution for a separate material. Thank you all, who read, follow the publications.
Source: https://habr.com/ru/post/243545/
All Articles