The main challenge with using the Backbase Client Framework to develop web applications is to balance the client-side logic with server-side logic. Rich Internet Applications (RIAs) require more logic on the client, but putting too much logic on the client-side can be a disaster for performance.
There are many reasons for performance issues. This chapter aims at finding these reasons and providing some hints and tips to avoid overloading the client. These performance tuning methods are categorized into four stages, each represents one of four basic steps during the web application development life cycle: architecture, implementation, deployment and server-side optimization. The performance testing is then addressed, followed by a conclusion and reference information.
Architecture and Design
Performance issues should be pointed out at the very early stages of building an Ajax application. In the architecture stage, the goal is to reduce logic at the client-side. This is because Backbase Client Framework uses the Model View Controller (MVC) model and it will create three types of nodes instead of one for every normal Backbase element (some elements may not have all three nodes):
- HTML DOM nodes in view space
- Model nodes in model space
- Controllers as JavaScript objects that match elements in view space
The benefit of having two extra nodes is that this adds object-oriented features and thus improves separation of concern, reusability and extendability of the project. On the other hand, these additional nodes require more time to parse and execute, which takes up more browser resources.
1. Balance out the amount of client-side business logic
The basic rule of client-side Ajax is not to replace all the business logic in server-side. Rather, only common business logic requires that such form validation should be placed on the client. This is a common mistake when developing Ajax RIAs.
Important: Do not do things on the client that the server can do equally well, without losing usability (end user friendliness). For security reasons, all validation should be repeated at the server.
2. Divide client-side architecture into a direct shown part and a logic part
At the client-side, a web page can be divided into a direct visual part and a functional part. The direct visual part can be shown immediately when the page starts to load and the functional part can be shown later. In this way, the perceived performance enhancement helps to improve the user experience.
3. Set up architecture design with separation of concerns
Although this concept has no direct impact on performance, it aids to pinpoint problem areas. Moreover, it allows you to refactor and optimize components and routines more easily, since this can be done and tested in isolation.
4. Create custom container widgets and contained widgets as one
Model nodes with controllers that are present at the client-side are very nice for object-oriented encapsulation. On the other hand, these could be expensive, as they need more space and require more interpretation. As a result, the amount of model controllers should be minimized. For instance, when creating a menu with sub-menus, the usual approach is to create model nodes and controllers for each menu and each sub-menus involving mouse event capturing.
A better way is to create only one model node with a controller for the whole menu bar and catch bubbled events from there. More details are available on Event Order and Event Delegation.
See other chapters:
Performance Tuning - Checklist
Performance Tuning - Chapter 1: Architecture and Design
Performance Tuning - Chapter 2: Implementation
Performance Tuning - Chapter 3: Deployment
Performance Tuning - Chapter 4: Server-side Optimization
Performance Tuning - Chapter 5: Testing
Performance Tuning - Chapter 6: Conclusion
| Attachment | Size |
|---|---|
| performanceOp_examples.zip | 8.89 KB |
