When should I use RequestFactory vs GWT-RPC?

Question

I am trying to figure out if I should migrate my gwt-rpc calls to the new GWT2.1 RequestFactory cals.

Google documentation vaguely mentions that RequestFactory is a better client-server communication method for "data-oriented services"

What I can distill from the documentation is that there is a new Proxy class that simplifies the communication (you don't pass back and forth the actual entity but just the proxy, so it is lighter weight and easier to manage)

Is that the whole point or am I missing something else in the big picture?

Answer 1

The big difference between GWT RPC and RequestFactory is that the RPC system is "RPC-by-concrete-type" while RequestFactory is "RPC-by-interface".

RPC is more convenient to get started with, because you write fewer lines of code and use the same class on both the client and the server. You might create a Person class with a bunch of getters and setters and maybe some simple business logic for further slicing-and-dicing of the data in the Person object. This works quite well until you wind up wanting to have server-specific, non-GWT-compatible, code inside your class. Because the RPC system is based on having the same concrete type on both the client and the server, you can hit a complexity wall based on the capabilities of your GWT client.

To get around the use of incompatible code, many users wind up creating a peer PersonDTO that shadows the real Person object used on the server. The PersonDTO just has a subset of the getters and setters of the server-side, "domain", Person object. Now you have to write code that marshalls data between the Person and PersonDTO object and all other object types that you want to pass to the client.

RequestFactory starts off by assuming that your domain objects aren't going to be GWT-compatible. You simply declare the properties that should be read and written by the client code in a Proxy interface, and the RequestFactory server components take care of marshaling the data and invoking your service methods. For applications that have a well-defined concept of "Entities" or "Objects with identity and version", the EntityProxy type is used to expose the persistent identity semantics of your data to the client code. Simple objects are mapped using the ValueProxy type.

With RequestFactory, you pay an up-front startup cost to accommodate more complicated systems than GWT RPC easily supports. RequestFactory's ServiceLayer provides significantly more hooks to customize its behavior by adding ServiceLayerDecorator instances.

Answer 2

I went through a transition from RPC to RF. First I have to say my experience is limited in that, I used as many EntityProxies as 0.

Advantages of GWT RPC:

• It's very easy to set-up, understand and to LEARN!
• Same class-based objects are used on the client and on the server.
• This approach saves tons of code.
• Ideal, when the same model objects (and POJOS) are used on either client and server, POJOs == MODEL OBJECTs == DTOs
• Easy to move stuff from the server to client.
• Easy to share implementation of common logic between client and server (this can turn out as a critical disadvantage when you need a different logic).

Disadvatages of GWT RPC:

• Impossible to have different implementation of some methods for server and client, e.g. you might need to use different logging framework on client and server, or different equals method.
• REALLY BAD implementation that is not further extensible: most of the server functionality is implemented as static methods on a RPC class. THAT REALLY SUCKS.
• e.g. It is impossible to add server-side errors obfuscation
• Some security XSS concerns that are not quite elegantly solvable, see docs (I am not sure whether this is more elegant for RequestFactory)

Disadvantages of RequestFactory:

• REALLY HARD to understand from the official doc, what's the merit of it! It starts right at completely misleading term PROXIES - these are actually DTOs of RF that are created by RF automatically. Proxies are defined by interfaces, e.g. @ProxyFor(Journal.class). IDE checks if there exists corresponding methods on Journal. So much for the mapping.
• RF will not do much for you in terms of commonalities of client and server because
• On the client you need to convert "PROXIES" to your client domain objects and vice-versa. This is completely ridiculous. It could be done in few lines of code declaratively, but there's NO SUPPORT FOR THAT! If only we could map our domain objects to proxies more elegantly, something like JavaScript method JSON.stringify(..,,) is MISSING in RF toolbox.
• Don't forget you are also responsible for setting transferable properties of your domain objects to proxies, and so on recursively.
• POOR ERROR HANDLING on the server and - Stack-traces are omitted by default on the server and you re getting empty useless exceptions on the client. Even when I set custom error handler, I was not able to get to low-level stack traces! Terrible.
• Some minor bugs in IDE support and elsewhere. I filed two bug requests that were accepted. Not an Einstein was needed to figure out that those were actually bugs.
• DOCUMENTATION SUCKS. As I mentioned proxies should be better explained, the term is MISLEADING. For the basic common problems, that I was solving, DOCS IS USELESS. Another example of misunderstanding from the DOC is connection of JPA annotations to RF. It looks from the succinct docs that they kinda play together, and yes, there is a corresponding question on StackOverflow. I recommend to forget any JPA 'connection' before understanding RF.

Advantages of RequestFactory

• Excellent forum support.
• IDE support is pretty good (but is not an advantage in contrast with RPC)
• Flexibility of your client and server implementation (loose coupling)
• Fancy stuff, connected to EntityProxies, beyond simple DTOs - caching, partial updates, very useful for mobile.
• You can use ValueProxies as the simplest replacement for DTOs (but you have to do all not so fancy conversions yourself).
• Support for Bean Validations JSR-303.

Considering other disadvantages of GWT in general:

• Impossible to run integration tests (GWT client code + remote server) with provided JUnit support <= all JSNI has to be mocked (e.g. localStorage), SOP is an issue.

• No support for testing setup - headless browser + remote server <= no simple headless testing for GWT, SOP.

• Yes, it is possible to run selenium integration tests (but that's not what I want)

• JSNI is very powerful, but at those shiny talks they give at conferences they do not talk much about that writing JSNI codes has some also some rules. Again, figuring out how to write a simple callback was a task worth of true researcher.

In summary, transition from GWT RPC to RequestFactory is far from WIN-WIN situation, when RPC mostly fits your needs. You end up writing tons conversions from client domain objects to proxies and vice-versa. But you get some flexibility and robustness of your solution. And support on the forum is excellent, on Saturday as well!

Considering all advantages and disadvantages I just mentioned, it pays really well to think in advance whether any of these approaches actually brings improvement to your solution and to your development set-up without big trade-offs.