RestyGWT vs RequestFactory

Question

I'm thinking on migrating my current service layer based on GWT-RPC to something else. It is about 10 service interfaces with 5 methods each, and involving about 20 different domain entities, so you have an idea of the amount of work that would require to change the whole thing, which obviously I would like to minimize. I'm also using Gilead and a Guice based centralized Servlet to handle all the RPC requests.

The main reasons for the change are:

• TypeSerializers are consuming the most big part of the size of the app code.
• Serialization/deserialization on client side is SLOW specially on dev mode, which seems to be a common fact with GWT-RPC.
• Obviously I would like to minimize the on-wire payload, but is not a hard requirement.

The options that I'm thinking about are:

• RequestFactory, which is promoted as a faster beast. But I'm afraid that it would be a lot of work to replace all references in client code of domain objects to their proxy counterparts, and also I'm lazy to actually build all the the proxies.

• A full JSON/REST approach using RestyGWT, which looks like it would let me still use the domain objects, but I'm afraid that it would end up with an even slower deserialization? I'm not based on any fact, but couldn't find any kind of benchmark. It is just an impression.

I really would like to get suggestions.

Thanks!

Answer 1

Although we are currently working with RequestFactory, I'm recommending REST. These are the 3 main reasons why:

1. client and server implementations don't have to be dependent (if you ever plan on native apps for a non android device than forget about requestfactory).
2. new api changes in requestfactory break old client code (this has devastating results on production)
3. the REST eco system and communities are larger and it is easier to tackle issues in code, and allow other apps to communicate with yours in the future.