N/A BONIAS
THE NETHERLANDS
The need to separate data, business logic and presentation
Many companies of any size are using browser based applications to provide access to the often enormous amount of data that they have in their possession. A browser based application offers many advantages to someone wishing to integrate back-end systems that are often technically incompatible. The virtual integration provided by a browser based application is, in many cases, an extremely useful solution that suits the needs of many companies of any size around the world.
Browser based applications have their own unique problems. In this article I will try to centre on what I consider the most important problem of all -- bad performance.
Performance makes or breaks a browser based application
Performance is absolutely essential for many types of applications. Performance for a browser based application is a factor of even more crucial importance since, in most cases, it decides the acceptance or rejection of an application.
Browser based applications suffer disproportionately from bad performance. Developers and maintenance engineers often provide many reasons why a browser based application shows bad performance but, in my experience, two figure most prominently: hardware performance and network bandwidth.
I believe that, in most cases, these are nothing more than urban myths.
Some might consider this a bold statement but, after several years of working in large corporations where resources for better hardware and networks with extremely high capacity are never scarce, I have come to firmly believe that, mostly, the problem must lie with something else.
If hardware performance and network capacity where the two most important factors for the bad performance of browser based applications, today there would almost no application with bad performance. Powerful hardware that can be cheaply purchased and cheap network bandwidth would have solved the problems of most companies.
Bad architecture provides bad performance
Browser based applications are often structured in a monolithic and technology oriented manner.
In simple words, this essentially means that, if one takes away the bells and whistles, most browser based applications are a collection of online queries containing a good amount of business logic that collect all sorts of data from a number of databases or data tables and present it on-screen according to some pre-determined layout.
This is, in my opinion, a very technology oriented manner of structuring a browser based application. It serves the needs of the developer more than the needs of the user. It provides the developer with a simple framework where development can take place and takes away many of the challenges that would accompany a more complex structure.
The biggest problem with this approach is that it is very treacherous.
It is treacherous because it does work in the beginning and can provide results with relatively small resources. When the first performance problems appear, the developer can address the problem with optimizing queries, writing better code, using more advanced components and so on.
What started with a technology oriented approach slowly develops into a technology oriented vicious circle. More time and resources are needed to optimize queries, and, as the queries become more efficient, an ever decreasing performance gain can be achieved.
Initially, this is an approach that pleases both the business owners of the application and its developers.
The business owners are satisfied because they have managed to establish a browser based application from nothing with a reasonable amount of resources.
The developers are satisfied because they can show their capability and because they are in the familiar field of technology where they can fight their familiar battles.
Eventually, however, this approach will inevitably result in massive problems with users and business owners complaining about bad performance.
Separate data, business logic and presentation
After years of experience, I have to the conclusion that browser based applications must have a modular design that must separate data storage, the business logic that is necessary to process the data and the presentation of the data to the user.
These three components of a browser based application must be constructed in independent layers that can function independently from each other.
Let us start from the presentation layer.
The presentation layer must ideally have only one purpose to display data to the user in an effective and quick manner. The presentation layer must be simple and should contain no business logic or other intelligence that have an impact on performance. All data that is displayed through the presentation layer must be pre-processed as much as possible and ready for display without any further processing. Data must be contained in flat, de-normalized tables. The structure of these tables must reflect the structure of the pages that are displayed to the user.
Data warehousing can be a solution to such an arrangement.
We now come to the second layer, the business logic layer.
This must be the layer where all the processing takes place so that the data can be sent to the presentation layer for displaying to the user. Please note that the processes taking place in this layer are background processes that do not interact directly with the user. This makes maintenance of these processes easier and more efficient.
A monitoring mechanism must be created in order to monitor these processes.
Finally, the data layer is where the data in raw form is being stored. Data can originate with the system itself through interaction with the users or with other external systems and databases through system interaction.
Advantages and disadvantages
This approach has some advantages and disadvantages as, of course, any other approach.
Among the advantages are very good performance, flexibility in maintenance, scalability and robustness.
Among the disadvantages are latency in data between the presentation and the data layers and a more complex data model that requires more maintenance.
The decision whether to adopt such an approach is a decision that must be made if the requirements for a specific browser based application do not contradict one of the basic assumptions of this approach such as the existence of latency between the presentation and data layers.
In my experience, such an approach can be adopted in the majority of cases and can solve the really destructive performance issue that troubles many browser based applications.