GWT-RPC vs HTTP Call - which is better??

Question

I am evaluating if there is a performance variation between calls made using GWT-RPC and HTTP Call.

My appln services are hosted as Java servlets and I am currently using HTTPProxy connections to fetch data from them. I am looking to convert them to GWT-RPC calls if that brings in performance improvement.

I would like to know about pros/cons of each...

Also any suggestions on tools to measure performance of Async calls...

[A good article on various Server communication strategies which can be employed with GWT.]

Answer 1

GWT-RPC is generally preferred when the backend is also written in Java because it means not having to encode and decode the object at each end -- you can just transmit a regular Java object to the client, and use it there.

JSON (using RequestBuilder) is generally used when the backend is written in some other language, and requires the server to JSON-encode the response object and the client to JSON-decode it into a JavaScriptObject for use in the GWT code.

If I had to guess I'd say that GWT-RPC also results in smaller transport objects because the GWT team optimizes for this case, but either will work, and JSON can still be pretty small. It just comes down to a matter of developer convenience in most cases.

As for tools to measure request time, you can either use Chrome/Webkit's developer tools, or Firefox's Firebug extension, or measure request time in your app and send that metrics data back to your server in a deferred request for collection and analysis.

Answer 2

In general I agree with Jason - if your server side uses Java, go with GWT-RPC. You'll be able to reuse the POJOs, validation logic, etc. RPC also tends to "play" better with MVP and code-splitting.

However, if your server side uses anything else use JSON - but don't fret, with JavaScript Overlay Types using JSON is a breeze. You won't be able to reuse the code from client side on the server, though (YMMV).

From a performance point of view - I'd say that JSON has the edge here. Modern browsers have some seriously good methods for fast encoding/decoding for JSON. I'm not sure what GWT-RPC is "behind the scenes", but I doubt it can beat JSON when it comes to speed. As for the payload - that depends on the developer (the names of the objects in JSON, etc), but I'd say that in general JSON is also (marginably) smaller. Enable compression on your server (for example, mod_deflate on Apache HTTP) to squeeze the bits even more ;)

Answer 3

Just an addition to the other answers, there's one point to consider which could influence your decision towards JSON, even if you're using Java on the back-end:

Maybe sometime in the future, you want to allow non-GWT clients to talk to your server. Many modern sites offer some kind of API access, and if you're using JSON, you basically already have a comparatively open API.

Answer 4

I wrote that article mentioned in the question (thanks for the link!).

As always, the answer is 'it depends'. I've used both GWT-RPC and JSON.

As outlined above, GWT-RPC allows for some serious productivity in shipping java objects (with some limits) over the wire. Some logic can be shared, and GWT takes care of marshalling/unmarshalling your object.

JSON allows for cross domain access and consumption by other, non GWT clients. You can get by with overlay types, but no behavior (like validation) can be shared. JSON can also be easily compressed and cached, unlike GWT-RPC (last time I looked).

Since we have no idea what the payload is, performance recommendations are hard to give. I'd recommend (again, as someone does above) testing yourself.