GWT.create EU 2013: Comparing GWT Transport Mechanisms

GWT.create EU 2013: Comparing GWT Transport Mechanisms
Presented by Leif Åstrand (Vaadin).

By defining a Java type which will be used for client – server communication in GWT, Leif showed us how to send or receive this type in each GWT transport mechanism, which helped to resume the good point and the bad point. And for each of them, he also presented a statistic of how many developers are using it.

AJAX – RequestBuilder
A low level API, a lot of code to write, real world usage is 11%. The most complex part in this mechanism is to realize object string serialization and deserialization.

1. In the client-side:

  • Object string conversion, a direct way but has poor maintainability;
  • XML conversion is standard and has many java libraries in server side. But verbose data for transport, verbose code for developing, not type safe;
  • JSON conversion, web standard format, but JSONObject API in client side is not completely typesafe, JSONValue parsing code is verbose;
  • JavaScriptObject, very efficient, little boilerplate code, but must use strange syntax “/*-{…}-*/”, and can’t share code with server side.

2. In server-side for JSON type data:
Using Jackson will require the client-side to install an additional module “gwt-jackson” for ensuring the serialized object string is compatible with Jackson. We can also use AutoBean API, but we can’t use class in it, only interface is accepted.

Allows GWT incompatible entities, combines RPC and entity management and can handle automatically requests. But it is a little complex to setup, and has heavy coupling with the server. Real world usage is 7%.

Default solution, simple to use and powerful. But it needs concrete class type, and when we pass an object instance, the entire object graph will be included in client – server communication.  53% real world usage, this is the most popular one.

It has 6% real world usage. It put the server in control to use state synchronization concept, all state changes will be reacted as an event which will be sent back to client side by server push. But this made Vaadin application requires a stateful server.

Errai CDI events
Hide completely the transport. Developers don’t need to distinguish local or remote, client or server. It supports different protocols and server push. The transparent communication could be good but also evil.

To conclude

A very helpful conference, with all these resumes and comparisons in difference transport mechanisms.



Leave a Reply

Your email address will not be published. Required fields are marked *