The next evaluation of web-based applications leads straight to AJAX, and more generally, rich internet applications. In this article we will discuss various AJAX patterns in modern web applications. We will expect that you have a basic understanding of AJAX technology concepts.
As per those concepts, AJAX is a tricky way to call a Web Server application and smart way to process response data returned by the web server. This style leads to a partial rendering mechanism. As we know, AJAX requests are generated from the client side and for that we would like to discuss various categories of client-side applications.
We can categorize the client part into the following three categories.
Thin HTML client
This is the greenest ground for AJAX based solutions. We know that there are various ways to raise an AJAX request, it might use a classic XMLHttp object or by using some JavaScript library like jQuery, angular.js, backbone.js and many more or by using an AJAX toolkit in an ASP.NET environment.
However, the best solution and recommendation is to use a JavaScript library to make an AJAX call and process the returned data and DOM manipulations using JavaScript.
Mess client
For example, ASPX or Rozer view in the MVC architecture. We can see both HTML and C# code in the client part. Though the client is not as heavy as a traditional Web Form.
Anyway, a messy client is also somewhat okay for implementing an AJAX based solution. The advantage of this style is that we can use the beauty of a client-side scripting language and the power of a server-side language (like session management, data passing and so on).
Fat Client
It's not recommended at all to implement a fat client application, but in the current situation many applications are running in this design methodology.
We will now discuss a few popular AJAX patterns.
Browser-side Tinplating
This pattern suggests using templates that will be fleshed out dynamically with data retrieved from HTTP endpoints, instead of regenerating the HTML layout from the data on the fly and on a per-request basis. The pattern suggests setting up your own tinplating layer.
Cross-Domain Proxy
The pattern operates a server-to-server connection to a reachable and publicly exposed service and carries data back to the client. From the client browser, an AJAX application is not allowed to connect to any URL outside the domain of the page (It's a browser policy).
However, a local proxy located in the same domain can easily grab data from anywhere and flow it back to the caller. We can implement it using enabled cross-domain resource sharing in service-based applications.
JSONP is another solution to share data across domains.
Heartbeat Signaling
Since an AJAX operation may perform much data processing in the client part, at the same time the server is not aware of that. This pattern ensures that the client will periodically update the heartbeat signal (data) to the server, to indicate it's presence.
The same is true in reverse. The server can also send a signal to the client to indicate to process a completion percentage.
HTML Message
Generally a HTTP endpoint returns data in JSON format and we process data to update the DOM. But if needed we can return a complete HTML structure to the client if the business logic is very complex or to improve performance.
Predictive Fetch
The pattern suggests anticipating the most likely user actions and fetching the required data beforehand. Implementation of this pattern comes at a cost: it's ultimately a guess, and you may be wrong. Whereas effective for increasing perceived performance, this pattern may also result in a loss of performance if poorly implemented or implemented in a less than ideal scenario due to heavy server bandwidth consumption.
Period refresh/push
It's a very much common scenario where a user's interface is needed to be refreshed over a certain time period. Performance suffers in this pattern, when the data is not updated frequently and the data updating time is at a regular interval.
The modern and smart solution is to push the data from the server. In Microsoft's stack we can use SignalR to push data from the server or in HTML5 we can use socket io.
Timeout
In the case of heavyweight operations conducted from the client, such as streaming or periodic refresh, there's the problem of ensuring that each connected client is really using the application. This pattern suggests that you time out the heavy operation and resume only if the user explicitly requires that.
Virtual Workspace
The server needs to respond to requests as quickly as possible, but it can't necessarily return all of the data available for bandwidth reasons. This pattern suggests that you build a virtual user interface that transmits the idea that all the data is available while only a small fraction of it is really on the client. It is the application's responsibility to download data on demand and cache it locally.
Conclusion
In this article we discussed various design and best practices in client-side application development. Those practices may improve the performance and maintainability of an application.