By Lux

January 24, 2005

Since the launch of Google's Gmail service, Amazon's A9.com, and Flickr.com (among other "next-generation" web-based applications which aim to be more interactive and more responsive to users), there has been a lot of buzz amonst web developers over the idea of client-side remote procedure calling (RPC) using JavaScript to talk to your server-side scripts behind the scenes. Several implementations of this have existed for quite some time, some using hidden HTML iframe tags and some using the XMLHttpRequest object, but it is only recently that this technique is seeing much attention in mainstream circles (mostly thanks to its prominent use in applications such as Gmail).

Sitellite has offered an implementation of this technique for some time, in the form of the js/rpc.js client library and the saf.Misc.RPC package on the server end of things. This article aims to introduce Sitellite developers to these handy tools, which can help them take advantage of this exciting new technique for web application interaction.

To start with, we'll go over the basic process of an RPC request, so everyone is up to speed on what is actually going on in the example below. An RPC request starts with the end user viewing a given screen in your web-based application. The end user makes a selection (via a link or a form), and behind the scenes the event is captured by some JavaScript running in the client's browser. Through one RPC technique or another, and without the end user being aware that the browser is talking to the server again (read: no page reload), the event is shuttled off to some server-side action. The server-side action then handles the actual task requested by the end user (ie. a database search, new data entry, or some calculation), and responds to the end user's browser. The browser, still acting like nothing secretive is going on, uses some additional JavaScript to dynamically update the web page that the end user is currently viewing with the data received from the server. To the end user, the action seems to have taken place without the usual round-trip to the server.

This technique has the obvious benefit of making your web application seem more responsive, and more like a "real" application instead of a series of web pages, but it also does something else that's beneficial for the site the application is running on: RPC requests cut down on an entire page reload, causing less processing on the server to occur (especially with dynamic applications), and less data (read: bandwidth) to be used up. This can mean that with a few strategic RPC calls, your web applications can not only run faster and appear more useful to your end users, but they can also let you get more performance out of your server, and also cut down on your bandwidth usage.

Page 1: Since the launch of Google's Gma...
Page 2: The End User Interface
Page 3: The Server-Side Handler
Page 4: Further Thoughts

Home   More Applications Stories