What is client-side GWT architecture of Wave

Question

I am wondering if some of you are aware of the architectural approaches taken by the Wave team to build its GWT web client? Since i am trying to optimize performance of one GWT app designed for mobiles, it is hard not to admire its speedy credentials :)

• Is Wave not using GWT-RPC to get regular updates from server? Firefox tracks some JSON communication going over the wire but nothing like RPC stuff.

• How do they proceed when, for instance a new wavelet is sent. Is there a view object for every wave DTO, or they use some other pattern?

• How is GUI updated after a response with, say, a new Wave arrives. Would the whole area with wavelets being rerendered or the use some smart techniques to ensure that only particular element is touched?

Thanks

Answer 1

This is probably information overload, but since Google Wave is open source you can actually look at how they set things up here.

If you look at WaveView.java, for example, you can see that they are using a client-side event bus like Ray Ryan mentioned in this talk at Google IO 2009. I seem to remember seeing another video where they talked about these aspects of Google Wave:

• They use an event system to fire off events when something happens on the client side. The event system manages communication with the server, passing event information up to the server, getting events back from the server, and publishing those events that come back. The event bus uses a kind of buffer so that if a bunch of events are fired off in rapid succession, they can send them all in one batch. For example, when a new Wave arrives, an event with the wave information would get fired, and any portions of the UI that are actively listening for that event would be notified, so that they could determine whether they needed to change themselves accordingly.
• They used seam points (or some such; I can't remember the name) to make it so that GWT could break the code up into modules, and only load up the portions that actually need to be used. Since the wave ui javascript file was originally over 1MB (minified and compressed), that was pretty important.
• Since only certain waves and wavelets would be visible at a time, they actually used some complex techniques to reuse the same DOM elements. So as you scroll down through your list of waves, it's actually taking the DOM element representing the wave at the top of your inbox, changing the information inside, and moving it to the bottom of your scroll area, leaving a blank space in the part of the scroll area that you're not seeing anymore.

Additionally, I'm pretty sure they use something like Comet with JSONP to maintain continuous communication with the server, so they're not polling the server constantly for new updates, but rather there's a dynamically-generated javascript file that's being loaded in incrementally from the server, which contains instructions to fire whatever events the server has decided need to be fired.