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? Am Donnerstag, 16. Oktober 2014 17:22:08 UTC+2 schrieb 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. > > -- 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-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
