RPC vs. RequestFactory vs. RestyGWT

[Ralf Klemmer]

I've used RPC, RequestFactory and now RestyGWT in some GWT projects.

In my opinion RequestFactory development should be canceled and replaced by RestyGWT (or something like that).

My key arguments for that drastic opinion:

RPC

+ easy to learn

- proprietary

- problems when trying to send hierarchical entities over the wire

- mostly leads to DTOs, which leads to boilerplate code for mapping DTOs and entities, which leads to hardly maintainable code if you have to deal with hierarchical objects (e.g. entity A contains entity B which contains list of entity C)

RequestFactory

- proprietary

- high learning curve

- bad documentation (almost every is very old)

- development is slow (compared to other techniques)

-  boilerplate code

+ "standard" GWT communication

+ integration with Editor framework

+ transfer of data delta between client and server

RestyGWT

- no official part of the GWT framework and the potential risk of development cancelation

+ really, really easy

+ Java standard

+ great documentation (client side on RestyGWT site, server side on RestyGWT and every other REST documentation)

+ out-of-the-box accessible by any other device that can handle rest services

+ nearly no boilerplate code

What's your opinion about that? Is RequestFactory the "right" way or not? What are your experiences?

I'm looking forward to your answers,

Ralf

[Vassilis Virvilis]

I am using RestyGWT although I am still using it in a RPC type of way and not in a RESTful way.

The main reason is that I can split the project to server part and client part more easily. The server part goes with all of my other services without gwt jars where it can share code etc...

     Vassilis

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

Vassilis Virvilis

[Ümit Seren]

I have been using RequestFactory extensively for a project and I must say that although it is pretty well engineered, the learning curve is quite high. 
If you have a CRUD heacy application where you send and receive lots of data, it might be a good solution (because it only sends deltas). 

However there are also some pain points: For example on the server side it uses Reflection to initialize the server instances which is slower than if the code would be generated. 

Also currently there is no real further development ongoing (apart from some bugfixes). 

Another downside is that there is really strong coupling between backend and frontend with RF. 

In many cases you might need a public API to access the data from non GWT clients, so you might end up implementing two endpoints (RF and REST). 

If I would start again I probably would choose REST over RF just because it clearly separates frontend from backend. 

[Thomas Broyer]

On Thursday, October 16, 2014 3:22:47 PM UTC+2, Ümit Seren wrote:

I have been using RequestFactory extensively for a project and I must say that although it is pretty well engineered, the learning curve is quite high. 

+1

 

If you have a CRUD heacy application where you send and receive lots of data, it might be a good solution (because it only sends deltas). 

Well, RF is good at RPC too (using ValueProxy).

I think Google is using it mostly that way, with the JSON-RPC dialect (I don't think they use the "native" dialect, that allows batching, etc.).

However there are also some pain points: For example on the server side it uses Reflection to initialize the server instances which is slower than if the code would be generated. 

I was thinking about generating code for the server (or JVM clients), but the current use of ServiceLayers is likely to greatly limit the gains in performance…

Still, walking the object hierarchies might benefit from such codegen.

 

Also currently there is no real further development ongoing (apart from some bugfixes). 

…but I never found the time and energy to actually work on the codegen.

 

Another downside is that there is really strong coupling between backend and frontend with RF. 

Though less strong that with GWT-RPC, because the client and server have to use "compatible" versions of the proxies (compatible in a way similar to how ProtoBufs are compatible with one another), not necessarily the exact same class as in GWT-RPC (well, there are solutions I believe for GWT-RPC, by having several serialization policies at once on the server).

 

In many cases you might need a public API to access the data from non GWT clients, so you might end up implementing two endpoints (RF and REST).

Well, RF has a well-defined (though not well-documented) protocol, and it's capable of using JSON-RPC (though only on client-side), so you could use a single endpoint.

But I otherwise agree with your point.

[Jonathan Franchesco Torres Baca]

Hi, I share resources to reduce online learning. 

good luck!

MOOC: https://holamundodev.appspot.com/preview

Post: http://www.enjava2.com/2014/07/devol.html

CRUD in GitHub:

Dailypoor - code : https://github.com/chescot2302/dailypoor

Link App: https://dailypoor.appspot.com/

APP in GitHub:

Devol - code : https://github.com/chescot2302/devol

Link App: https://devolpay.appspot.com/#X

--

[Ralf Klemmer]

First, thanks for all your replies! 

If I understand Thomas right, it is possible to use RF as a single endpoint for GWT-Clients and Rest-Clients. Well that's great to know. Are there any plans to increase the documentation coverage in RF?

Also my questions wasn't exclusively meant to be technical.

A GWT beginner does the following learning steps (of course not complete):

1. learn RPC

2. application and objects grow and you look for alternatives: RequestFactory to the rescue!

3. highly motivated you start learning

4. two weeks later you might ask yourself if this was a good idea, of course you made it work, but you had to struggle a lot. And your gut feeling stays: Is this really the best solution?

That was partly my personal experience. Then I found RestyGWT and after 4 hours all worked as expected and I had removed hundreds lines of code - great feeling for me!

If RestyGWT is not an option to replace RF, then RF has to provide dead simple and understandable official tutorials, sample projects and good documentation! If no one knows what RF can do for you, then it's like being non existent.

And in the context of the myth that "GWT is dead", GWT should as easy and fun to learn as it was years ago. That should be one of the main goals for the steering committee. If you look at the official site and see articles from 2009, that's not what you would expect from a modern framework! Help the GWT community to grow by bringing the learning and programming fun back.

What are your thoughts?

[Thomas Broyer]

On Friday, October 17, 2014 11:59:02 AM UTC+2, Ralf Klemmer wrote:

First, thanks for all your replies! 

If I understand Thomas right, it is possible to use RF as a single endpoint for GWT-Clients and Rest-Clients. Well that's great to know.

All you need is to use RequestFactorySource.create() instead of GWT.create(), and provide a RequestTransport (there's a UrlRequestTransport using java.net.URL and HttpURLConnection but it's not really meant to be used in production (you'd prefer using Apache HttpClient or OkHttp).

 

Are there any plans to increase the documentation coverage in RF?

Not really actually.

If you want something to be documented (or better documented), feel free to file requests in the issue tracker; or even better contribute a patch to the documentation.

 

Also my questions wasn't exclusively meant to be technical.

A GWT beginner does the following learning steps (of course not complete):

1. learn RPC

2. application and objects grow and you look for alternatives: RequestFactory to the rescue!

3. highly motivated you start learning

4. two weeks later you might ask yourself if this was a good idea, of course you made it work, but you had to struggle a lot. And your gut feeling stays: Is this really the best solution?

It's not.

It has many benefits over GWT-RPC, but it's clearly not the "best solution" out there.

We're still searching for the "best solution", and we'd like to have something better in a future version of GWT that could replace both GWT-RPC and RequestFactory, hopefully next year.

 

That was partly my personal experience. Then I found RestyGWT and after 4 hours all worked as expected and I had removed hundreds lines of code - great feeling for me!

If RestyGWT is not an option to replace RF, then RF has to provide dead simple and understandable official tutorials, sample projects and good documentation! If no one knows what RF can do for you, then it's like being non existent.

And in the context of the myth that "GWT is dead", GWT should as easy and fun to learn as it was years ago. That should be one of the main goals for the steering committee. If you look at the official site and see articles from 2009, that's not what you would expect from a modern framework! Help the GWT community to grow by bringing the learning and programming fun back.

What are your thoughts?

With 2.7 and SDM, we're focusing on the "programming fun" ;-)

and would be glad to receive contributions to the docs from the community. People who need the doc are in the best position to improve it when they had to look things up elsewhere. When you know something really well, you can answer questions, but it's hard to know upfront what people need to know and how to teach them. So don't be shy and head to Gerrit or the issue tracker ;-)