Mootools: I want to implement an architecture similar to Big pipe on Facebook

Question

I am developing an application in mootools. I used the Reqeust class to pipeline it. I want to develop an excellent method for processing client server requests. I mentioned the following article to understand how the big tube works on facebook.

http://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919

On facebook, the javascript function is called upon the arrival of any server response to update the user's data screen. (see screenshot)

http://img815.imageshack.us/img815/5154/facebookna.jpg

If I get a basic model of such an architecture, I can start building the application using the code.

Can anyone suggest me such a basic model?

So far, I have developed an architecture in which response_data is stored in a global variable, and then a function called to update the data on the user's screen. (Using a synchronous request here), which is very slow.

so which method is superior to "synchronous or asynchronous"?

Answer 1

First, thanks for reading, it was a very interesting blog post.

You might want to explore this library , which was inspired by Facebook BigPipe. Note. I do not approve of this, as I have never used it, but its creation is not trivial.

As for how synchronous and asynchronous is better, it depends. Synchronization is simpler - the dependencies are obvious and there is no overhead. Asynchronous is only an advantage if your resources are not fully utilized and your processing can be easily broken into independent blocks. I can’t say what you are trying to do, so you need to decide for yourself where the performance bottleneck is, and whether archiving your application so that several partitions can be loaded, processed and displayed in parallel will actually provide an advantage.

As an example, if you load one massive array of data that will be displayed as a table in the browser, then splitting this data into several parallel downloads will increase productivity - at the cost of creating some queuing system, dealing with out-of-order answers. On the other hand, although technically slower, batch loading into synchronous blocks, so that one block is loaded and displayed before the next request, will still do wonders for perceived performance and is a much simpler alternative.