The multiton pattern on client side

A while ago, I wrote a post about the multiton pattern on server side that utilizes a fixed amount of computation resource to serve a large number of concurrent requests for the same representation that needs to be generated on demand. The pattern helps to avoid racing condition that the concurrent request processing could lead to.

Each resource instance in the registry or map works like a proxy. The proxy's interface is the same for the consumers no matter it arrives early or late. Inside the proxy, the representation is produced on demand, or retrieved from a cache or a persistent copy.

A client side multition can reduce not only client side load but also the server side load and the traffic between client and server. Consider a client side JS component that depends on a remote resource. When loading, the component will issue an AJAX call to the remote resource and render when the resource representation is available. A problem arises when there are many such component instances on a page targeting the same remote resource. The server side will see multiple concurrent requests of the same resource representation when the client loads such a page. That will make backend services busy for a while. While a server side multition can help, a client side multition will further reduce the client side load on a page and also reduce the connection numbers and network traffic to the server.

Forcing clients to reload on new application releases

Many Web application clients get data via Ajax. The resources including the CSS and JavaScript files  are never reloaded once loaded in this way. However, some new features require the clients to retrieve the updated resources from the server. This can be achieved by maintaining a service generated release number on the client, and compare that number with the current release number on the server via Ajax. If the release number is updated, then run

window.location.reload(true);

You will need to either disable the the cache for the resource of release number, or set cache to false of the Ajax GET request.

201 or 303

Post/Redirect/Get is a common pattern to create a new resource and then load the representation of the new resource in browser. An advantage of this pattern is to prevent duplicate form submission when a user clicks the browser refresh button after the Post request. The response code of the Post request is 303 if the request is successful. The browser will always redirect to the Location link in the 303 response header.

Unfortunately, this behavior can be confusing when the Post request is sent via AJAX. That means JavaScript will see response code 200 directly instead of 303 when the Post is successful. The AJAX engine inside a browser has no way to stop at the 303 and prevent the redirection. Furthermore, JavaScript will normally see the HTML representation of the new resource in the response. This can be confusing when you want to control what the page to do when the new resource is created and load the JSON representation of the new resource. In this case, 201 is obviously better than 303, because the JavaScript can decide how to notify the user and also furthermore how to load the new resource into the current page or redirect.