GWT 2.4: RequestFactory versus GWT-RPC

[Michel Jonker]

Hi,
This is a cross post from the AppEngine group, but since I got no
response there, I want to try this group.

I am trying to figure out the best practise to consume my App Engine
services from both Android and GWT.
Since the services are not that data oriented, I first considered GWT-
RPC.
But given the fact that the GPE 2.4 sample project voor Android comes
with
RequestFactory, I am leaning towards this approach.
I was hoping someone could validate this 'best practise' :
When you have both Android and GWT consumers of your App Engine
service,
apply the RequestFactory pattern.

TIA

Michel Jonker

[Juan Pablo Gardella]

If you use GWT-RPC and JPA (with Hibernate provider) you will have serialization problems. To solution this, you have this alternatives:

1) Use DTO
2) Use Gilead
3) Use a Filter. You can read this too and here you have a sample implementation with GWT 2.3.0.

With RF you will no have this problem and is efficient. But as you said, is oriented to data services and (to me) is more complicated. GWT-RPC is more general and you will write less code.

Hope helps to decide.

2011/7/14 Michel Jonker <michel...@e-office.com>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

With ValueProxy, you can with RequestFactory do everything you would with GWT-RPC (well, with the major exception of polymorphism –though this will be fixed soon– and "transportable types" –which don't include java.util.Map for instance, though once again will be fixed in due time–).

GWT-RPC can also be a real pain (particularly with non-web apps) as the client and server must be compiled from the exact same code or they won't be able to deserialize what the other end point sent. And I can assure you'll likely hit those even while developing your app! RF on the other hand makes migrations easier (no serialization policy files, to begin with).

But honestly, if you want to build an Android app, I wonder why you hesitate: support for GWT-RPC from Java is not official, and likely to break with a future version of GWT, whereas Android is officially a target plaform for RF. Just use ValueProxy all over the place if you don't need EntityProxy, it'll be just like RPC.

[Jens]

If your services are not that data oriented pure JSON may be enough? 

Using Google's AutoBeans you could easily define bean-like interfaces to transport some information between client and server. AutoBeans are internally used by RequestFactory and if you use them directly you won't have that data oriented feel of RequestFactory. AutoBeans are just an easy way to serialize/deserialize bean-like interfaces (you even do not have to implement them) to/from JSON. 

Your server part could then be something like simple REST web services and if you ever want to use a third front end beside Android/GWT you just have to deal with simple JSON.

-- J.

[Aidan O'Kelly]

I'm using RequestFactory for a 'non-data-orientated' app and its works
very nicely.

Chained method invocation:

MyServiceRC serviceRequest = appRequestFactory.MyServiceRC();
serviceRequest.giveMeAString().to(stringReceiver);
if (needPojo == true)
serviceRequest.giveMeAPojo().to(pojoReceiver); // Pojo would be a
ValueProxy for example.

// Now fire both methods in one RPC request, and do whatever
processing we want once both completed.
serviceRequest.fire(processStringAndPojoReceiver);

A pretty nice way to call server side methods. You are certainly not
restricted just to persisting and retrieving datastore objects with
RequestFactory.

[David Chandler]

FYI, bobv updated the RF developer guide yesterday with a separate section on "transportable types", discussion of polymorphic type-mapping rules, and slight re-wording of the Overview section.

http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html

/dmc

--
David Chandler
Developer Programs Engineer, GWT+GAE
w: http://code.google.com/

b: http://turbomanage.wordpress.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

[Thomas Broyer]

Hmm, shouldn't it have been for "trunk"? I believe @ExtraTypes and polymorphism support are not in 2.3, only in the upcoming 2.4.

[Elhanan Maayan]

considering it's talking about requestfactory-server.jar hmm, pretty much yea:)  (is 2.4 THAT close?)

On Fri, Jul 15, 2011 at 11:38 AM, Thomas Broyer <t.br...@gmail.com> wrote:

Hmm, shouldn't it have been for "trunk"? I believe @ExtraTypes and polymorphism support are not in 2.3, only in the upcoming 2.4.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/AClSV62TkrQJ.

[David Chandler]

We jumped the gun a bit, but 2.4 is pretty close to becoming "latest" :-)

/dmc

On Friday, July 15, 2011, Thomas Broyer wrote:

Hmm, shouldn't it have been for "trunk"? I believe @ExtraTypes and polymorphism support are not in 2.3, only in the upcoming 2.4.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/AClSV62TkrQJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Elhanan Maayan]

woo hoo! mabye i'll get to convince our CTO to use RF, he wants to avoid that becouse he says if the client will be in sliverlight, that won't work.

[Michel Jonker]

Hi,

Thanks for this encouragement.
I am a newby at GWT/App Engine and want to start creating applications
that follow Google's philiosofy.
Later (when I am more comfortable) I probably can add my own patterns
and stuff.

The main lesson I learned from this discussion is that GWT-RPC comes
with serialization 'challenges'. Which is not such a problem when you
work with web applications but is a much bigger issue when you have
distributed apps (like Android connected to App Engine).

Thanks for all the replies

Michel

[Elhanan Maayan]

i think google should clarify it's own philosophy in a special article in the developer guide, because as of right now , there way too many "black holes" on the subject of transports and frameworks that use them

GWT-RPC
JSON
RequestFactory
AutoBeans
XML.

i know that autobeans and rtf both uses json under, but that would only clarify the situation.

an FAQ and a  table matrix should  be created specifying  how each technology is based used AND it's future directions (like for example the use GWT-RPC in android, possible break in future version of java etc... , and other platforms compared to other technologies) also some basic benchmarks would be usedfull.

[Michel Jonker]

+1

On Jul 18, 9:25 am, Elhanan Maayan <elh.mailg...@gmail.com> wrote:
> i think google should clarify it's own philosophy in a special article in
> the developer guide, because as of right now , there way too many "black
> holes" on the subject of transports and frameworks that use them
>
> GWT-RPC
> JSON
> RequestFactory
> AutoBeans
> XML.
>
> i know that autobeans and rtf both uses json under, but that would only
> clarify the situation.
>
> an FAQ and a  table matrix should  be created specifying  how each
> technology is based used AND it's future directions (like for example the
> use GWT-RPC in android, possible break in future version of java etc... ,
> and other platforms compared to other technologies) also some basic
> benchmarks would be usedfull.
>
> On Mon, Jul 18, 2011 at 10:08 AM, Michel Jonker

> <michel.jon...@e-office.com>wrote: