Saturday, June 16, 2007

Why asynchronous sounds so good

While the rain is porring down outside, I have got some time to think about, why my latest discovery of AJAX buzzwords, "Asynchronous", is important.

The first thing that springs to mind is bandwidth, and I'm not talking about connection speed (eg. whatever your ISP is providing you). No, it's the wireless world, that we live in, that makes it significant. More often than not, my laptop switches hotspot, when I'm on the move, whilst entering a page. Or the machine is running out of juice, consequently the wireless range decreases, resulting in very poor bandwidth. With a plane old HTML page (POH instead of POX?:-) this is not a problem but c'mon when is the last time you viewed that?!? Today, many sites (especially those savvy Web2.0 sites) make use of AJAX/AJAH, img statistics, XSS (Cross-site scripting - mental note*1) etc..

Slow as a it goes
While the most popular assumption about AJAX is that because it's asynchronous by nature, the server-side is also asynchronous. This is not the case. If you, as most people like me, make use of a Javascript library, you work through a proxy that is responsible for connecting to your server-side. Usually that implies that the connection will time-out within a fixed period. Users of EXT will know that its time-out period is 30 seconds (3000 milliseconds) per default.

In my raining day conundrum I thought about img statistics. If I view a page that has statistics imgs, the download starts when the browser requests the page but it doesn't stop until the server finish its process. The image is empty and no bytes are downloaded but the browser still hangs, waiting for an HTTP OK to fire. Most browsers doesn't render before they have a certain amount of data to display. While the browser is waiting for the statistic logic to finish, it just does nothing. At the same time my laptop feels it's necessary to try every hotspot it can suck up. Talk about a method to learn patients!

Setup and sit ups
My favorite setup right now is to use ASP.NET Web Services (Atlas enhanced - mental note*2U) and connect to them though the EXT adapter proxy. Basically XHRs (XMLHttpRequest). At the time of writing, there is no simple way of making an
asynchronous connection all the way through. When the server receives a request, that thread is bounded to that process no matter how deep it goes. So the response is not coming until the server is 100% finished, which makes it very unscalable. Of course you can put the different web services on different servers, but if one service is heavily used, and you can't mirror it, you have little choice, but to throw more hardware at it. Which is why, one of my software philosophies is: "develop the server-side to be as thin as possible".

What about those imgs, that our mail marketing company so heavily relay on to feed our customers CRM?*3 It's possible to overcome the shortcomings of XHR but it might look a bit more grim for empty imgs. Where as in XHR situations you could push data to the client and therefore not make them depending of server speed (in XHR situations it's not that bad, you can create an empty client shell that pulls data when the document is ready eg. downloaded). There needs to be a mechanism to cut the connection from the server when the data is collected in those pesky imgs situations. One that comes to mind is the classic (in MS circles) response end. Collect the data. Issue an HTML OK, copy the thread to another and save the data in the db or do whatever process. If Firebug is correct, I've seen connections lasting up to 13 seconds! But that's when my laptop goes loco.

Will it help? I dunno but it stopped raining outside...

mental note*1 - one day I must write why XSS is not a security vulnerability. Key word: server-farms
mental note*2U - the official name is ASP.NET AJAX but Atlas sounds much more grunge - like MochiKit (Y)
*3 - mental slap. Desktop email clients already have everything downloaded

No comments: