RestyGWT is one of the options. Another less mentioned is the low level RequestBuilder. We moved to RB due to the large number of fields we are managing (400+) and use json on the client to consume the requests.
Ed On Fri, Feb 5, 2016 at 5:44 AM, Vassilis Virvilis <[email protected]> wrote: > I have successfully ported a medium API (~30 methods) from GWT-RPC to > Resty-GWT. While everybody's case is unique it went surprisingly well for > me (as far as transitions go). > > 1) The big advantage is that although you can use RestyGWT with a > procedural SOAP logic (like GWT-RPC) you can start familiarize yourself > with the new API design of the Restful tomorrow word. > > 2) Another advantage for me was that I had already a WS stack (CXF) and > thus with GWT-RPC I was either reimplementing my CXF services or I was > proxying them. > > 3) By ditching GWT-RPC I was able to free myself from server side code. > > 4) It is now easier to work with standard json and json inspection tools > like console.log(object_received) and with browser's network inspection > tools > > 5) RestyGWT has a async interface in order to keep your familiar GWT-RPC > handlers so the changes in the code are minimal. What takes more work is to > ensure that all your object's are transmitted correctly over the wire. This > is not walk in the park but for simple objects it just works. For more > complex cases you may need to implement a Provider or something. > > 6) I don't know about your special @annotations that somehow remove the > need to specify interface + async_interface but for me this is a major > plus. The client code does not need to link to server definitions and for > me API is something that changes with great difficulty and rarely. So wher > API breaks I am editing both files - I don't mind. > > Vassilis > > > On Fri, Feb 5, 2016 at 4:16 AM, <[email protected]> wrote: > >> I understand that the future of GWT RPC does not seem bright in 3.0+ but >> I want to express my opinion that this is a HUGE mistake. GWT RPC is one of >> the most important things in GWT as it truly ties things together in large >> apps. Sure, it its raw form it is a bit cumbersome to use but it enables >> true code reuse with no extra coding. This is what sets GWT apart from the >> run-of-the-mill frameworks out there. Creating custom requests and >> responses is not maintainable and scalable in a large app that depends on >> extensibility and polymorphism. Ability to communicate almost any Java >> object graph without having to specifically annotate or declare anything, >> while preserving singletons is a huge advantage. >> >> Sure, it lacks a lot of things. We used it with out proprietary wrapper >> framework in a way that allows us to simply annotate sever-side methods we >> want to expose to the client and everything else is automagically handled - >> the client gains the visibility into relevant server classes and methods >> with same signatures other than getting results asynchronously. One can >> pass results of some method call as an argument of another all without >> leaving the sever and without having to wire boilerplate/weird code.For >> example, if we had the following code on the server >> >> public class Foo { >> public static Bar getBar() { >> return new Bar(); >> } >> public static String someText() { >> return "Blah: " + System.currentTimeMillis(); >> } >> } >> public class Bar { >> public String twice(String text) { >> return text + text; >> } >> } >> >> >> >> .... with our annotations on the server (not shown) the following client >> code would be possible: >> >> Foo.getBar().twice(Foo.someText(), new AsyncCallback<String>() { >> ... >> public void onSuccess(String result) { >> ... >> } >> } >> >> ... no need for creating server + async interfaces, etc. >> >> With every other alternative we lose on simplicity and ability to >> communicate. All others require us to create more client-server >> communication code which we have been able to avoid. >> >> Needless to say, we'd be stuck in pre-3.0 land as we have a large code >> investment in GWT RPC - we could not accept losing it... but we do want to >> go to the newest GWT at any time. It would be greatly disappointing if we >> couldn't do this. >> >> I do not see the advantages of losing RPC. It does what it does better >> than anything else out there and is irreplaceable. >> >> Please do not get rid of it. Enhance it. It is what makes GWT better than >> the rest. It is what, together with the rest, allows seamless and uniform >> language use across the client and the server. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "GWT Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/google-web-toolkit. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Vassilis Virvilis > > -- > You received this message because you are subscribed to the Google Groups > "GWT Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/google-web-toolkit. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
