Last week a colleague and I gave a talk about scalable architecture and where my colleague talked about databases and application layer scaling, I talked about scaling websites. More precisely, we talked about the upcoming ZYB/Vodafone project. 

Since there’s still a lot of secrecy about the project, we managed to keep the concepts general. General or not, I’d like to share some thoughts on a different way of scaling websites.

Load balancing

Larger websites are often hosted on multiple web servers under a load balancer that distributes the requests evenly among the servers. This is an old technique for scaling out websites and has been widely used as the de facto scaling mechanism for years.  It’s good, it works and it’s cheap. It’s cheap because web servers often don’t have to be the biggest machines in contrast to e.g. database servers.

So, a load balanced web server setup provides good and cheap scaling possibilities.

Reversed load balancing

Any website, load balanced or not, can also use the vast untapped resources in the visitor’s browsers. Think about it. Quad core CPU’s and 4GB memory is almost standard today – even on laptops. Why not utilize the machine power behind the browsers to do some of the scaling for us?

Traditionally, this is done using browser plug-ins like applets, Flash and Silverlight, but many more sites use JavaScript. Modern browsers process JavaScript very fast and efficient which makes it possible to use JavaScript for scaling purposes.

To utilize the browsers memory we can cache data in JavaScript so we can eliminate chatty communication with the web server. An example would be to load all the data needed behind the scenes after the page is loaded and store it in JavaScript variables.  To utilize the CPU we can make calculations, dynamic rendering and other logic in JavaScript as well.

By pushing some of the load to the browser we are able to scale even more than just using regular load balancing.

It’s not for everyone

There are some problems with this approach that makes it a bad choice for some websites. If enough of the visitors are using old browsers like IE6 then they will get a worse experience because JavaScript runs too slow. There’s also the case where a website just doesn’t have any data to cache like a personal website.

For other types of websites it makes perfect sense. If your visitors have modern browsers and your website is heavily data driven, then it’s a possible candidate. The tests we have done at ZYB shows huge benefits by loading data behind the scenes - both the performance and scalability improves significantly. The load on the web servers dropped drastically with this technique. I hope to be able to show you some real numbers later.

At ZYB we have been doing cross domain JavaScript calls for quite some time now. Whenever we tell that to people, many don’t believe it is possible with standard security settings in any modern browser. This surprised me a bit since it has always been possible with a simple little trick.

The problem

Say you have a website (site A) with an iframe wherein you host another website (site B). In old and unsecure browsers it was possible to do a JavaScript call from site B to site A like this:

window.parent.doSomething();

Here the doSomething function is living on site A and is called by site B through its parent window. For security reasons, this simple way of cross iframe communication was disabled years ago by all browser vendors.

The solution

There are different scenarios with possible solutions:

1: Site B is a sub domain under/beside Site A

Let’s say that:

• Site A is located at example.com or sitea.example.com
• Site B is located at siteb.example.com

All you need to do is to add this line of JavaScript to both site A and B:

document.domain = 'example.com'

That tells the browser that both site A and B belongs to the app located at example.com and are therefore allowed to communicate using JavaScript. It could be by calling window.parent.doSomething(); Now Same Origin Policy principle has been enabled on both sites.

2: Site B is on a different top domain than site A

This is more tricky, because we need to let the browser think both site A and B are under the same top domain.  When it does, we can implement the trick from solution 1 above.

Let’s say that:

• Site A is located at example.com or sitea.example.com
• Site B is located at foobar.com

To make this work, you need to create a sub domain called e.g. siteb.example.com. Then point the new sub domain to the IP address of foobar.com. Now both site A and B is located under example.com and you can start to implement solution 1.

There is no security risk going on here because you can only implement solution 1 if both site A and B participate in the trick.

Other solutions

If you can't use either solution 1 or 2 the game isn't over. Here are some other techniques to use:

• JSONP
• Iframe proxying

Though not as simple as the document.domain trick, these are well documented and proven techniques.