Efficient GWT Client-Server Communication methodology

74 views
Skip to first unread message

Anne

unread,
Jun 11, 2010, 3:27:18 AM6/11/10
to Google Web Toolkit
Hello,

In my project, I need efficient transfer of bulk data from the server
to the client. The data will be containing thousands of rows of a
database. And I require to populate them very quickly. The project
will be implemented in areas with very slow internet connection.

I read about the Clinet-Server communication in GWT. What is the most
efficient way to use?
Either GWT-RPC or GWT-XML/JSON?

If somebody have already done some projects with this requirement,
could you please share your experience/suggestions so that I can
follow the best methodology to get better performance.


Thanks in advance.

bill braasch

unread,
Jun 11, 2010, 1:58:09 PM6/11/10
to Google Web Toolkit
Check out the Itemscript libraries. http://code.google.com/p/itemscript/
Itemscript includes a JSON RPC with cross platform Java / GWT
libraries.

There's also an in memory database you might find useful for managing
the client side.

Bill

Sky

unread,
Jun 12, 2010, 10:46:44 PM6/12/10
to Google Web Toolkit
I don't know anything about the Itemscript libraries that bill posted
about, but I took a quick glance and it looks worthwhile
investigating. Personally, I suspect that GWT-RPC does not have more
bandwidth overhead but there would be a tad bit more processing
overhead on both the client and server, so sticking with GWT-XML/JSON
is the most lightweight, however I think your design and
implementation for this is the most critical.

I have three major suggestions.

First, IF the data is not dependent on later rows and you merely want
to display the data or make calculations for individual rows or
certain groups then I highly suggest you break it up into numerous
async calls for the data. Get the first 100 rows and then the next
100, continuously. If you can't use any of the data until it's all
there... well it might still be worth breaking it up because an async
call can fail or be interrupted partway through... if the 100th call
fails for some obscure reason you can just repeat the call
indefinitely to continue... thus you won't have lost the first 99
calls of data.

Second, I seriously suggest using compression if the data is mostly
text. It's not hard at all to write a good lossless compression
program using Huffman coding in any language... I'm sure it would be
possible to do it in JavaScript (or GWT) and I'm sure the code would
not be large. I wrote a simple Huffman compression app a couple years
ago in University, it was easy and small. Then you can compress the
data on the server, send it and uncompress it on the client. That
would be awesome! Text can be compressed anywhere from 30%-60%+. That
will directly translate into speed!

Third, whatever you do, don't be sending any kind of html, css or
other UI bits along with that data! (This is assuming you are
displaying some of the contents of the database) You can use logic to
build the UI instead of repeatedly sending data that is surrounded
with html tags.

Goodluck!

Anne

unread,
Jun 13, 2010, 12:40:16 AM6/13/10
to Google Web Toolkit
Thank you Bill and Sky.

In the case of XML, it requires XML parsing. Won't that be an overhead
over GWT-RPC?

The tips by Sky, about sending multiple async calls will be greatly
useful.

Thanks.

Chris Lercher

unread,
Jun 13, 2010, 5:09:31 AM6/13/10
to Google Web Toolkit
@Sky: Yeah, compression is very important. Note, that you don't have
to do it yourself: Most servers and browsers support HTTP gzip Content-
Encoding (usually just a switch in the server config to turn it on).

Chris

Stefan Bachert

unread,
Jun 13, 2010, 6:09:24 AM6/13/10
to Google Web Toolkit
Hi Anne,

the transport mechanism is not really important.
It is import how many rows you transfer.
Consider, that a user in general never see more than, let say, 20
rows.
So we are talking to transfer a few rows from let say 20000000 rows of
a data table.

Maybe you want to check the new data widgets (cell...) coming up with
2.1m1. They offer such a functionality. However, I did not try it yet.

To send all data across the network at once is simple, but will fail
on greater data sets (performance, memory). When you expecting more
then 100 rows strongly consider an incremental load.

Stefan Bachert
http://gwtworld.de
Reply all
Reply to author
Forward
0 new messages