GWT RPC in GWT 3.0+

[gwtar...@gmail.com]

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. 

[David]

I always had a love/hate relation with GWT-RPC. I loved it that indeed it allowed you to quickly add remote calls.

But in bigger applications many of its restrictions started to have a big impact.

For example it was a pain to do proper integration or performance testing with GWT-RPC services since they can change with any build. The serialisation cost was another issue for me. GWT-RPC gave the impression that any java serialisable object tree can be serialised, but in reality you better avoid sending deeply nested graphs because the performance was terrible. So in the end I had to start optimising the object structure and do some reconstruction at the client side.

I moved to RestGWT now. This is really easy to use as well, even easier. I just annotate JAXRS services on the server and the client can consume this without any code replication. I don't need an async api. By using pure REST api's I can now easily integrate different clients with the same interface.

 

--
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 google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Vassilis Virvilis]

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

--

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 google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

Vassilis Virvilis

[Ed]

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

[Ramesh Selvaraj]

Dear All,

 Please any one let me know Where can I download GWT-3.0 package

Ramesh

[David]

Will the RequestBuilder API remain ?

[Thomas Broyer]

There's no reason it couldn't: does not use generator nor JSNI.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.

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 google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.

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 google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.

[Alain Ekambi]

Does not it rely on xmlhttp request which uses jsni ?

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 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 google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.

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 google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.

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 google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.

[Thomas Broyer]

Yes, but XMLHttpRequest is a thin wrapper that can easily be replaced with JsInterop.

(it also uses a Timer, which uses JSNI, that can also easily be replaced with JsInterop)

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.

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 google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.

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 google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.

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 google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.

[Tom Davies]

I'm not actively using GWt at present, unfortunately, but I second the importance of GWT-RPC.

For me the ability to statically type the interfaces is very important, and the tooling support that Intellij IDEA provides makes it easy to use.

Are there any statically typed alternatives? It's a shame that grpc doesn't have browser support.

[Vassilis Virvilis]

While I agree that static typing is of great importance I fail to see how this is a unique feature of GWT-RPC. I believe all alternatives suggested by people in this thread are statically typed.

--

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 google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.

Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

Vassilis Virvilis

[Tom Davies]

I didn't realise that RestyGWT did the server side too -- thanks for getting me to look at it again!

[Vassilis Virvilis]

AFAIK RestyGWT does not include a server component. You have to rely on another jax-rs server-side stack in order to serve RestyGWT requests.

Here is a list of java implementations although nobody forces to stay on java server side https://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services

On Sun, Feb 7, 2016 at 4:02 AM, Tom Davies <tgda...@gmail.com> wrote:

I didn't realise that RestyGWT did the server side too -- thanks for getting me to look at it again!

--

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 google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

Vassilis Virvilis

[Tom Davies]

On Sunday, 7 February 2016 18:07:12 UTC+11, Vassilis Virvilis wrote:

AFAIK RestyGWT does not include a server component. You have to rely on another jax-rs server-side stack in order to serve RestyGWT requests.

Here is a list of java implementations although nobody forces to stay on java server side https://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services

I mean that it allows the same interface to be used to specify the client and the server -- see "Reusing server interfaces" at the bottom of this page: https://resty-gwt.github.io/documentation/restygwt-user-guide.html

When I say that I want an RPC implementation to be statically typed, I mean that the Java type system must enforce that the GWT client matches the server implementation, and that if I change either I will get compile time errors. This can be done either via Java or via some intermediate specification language, I don't mind.

[Philippe Gonze]

Totally agree. GWT 3.0 without RPC would be GWT 3.dead for many of the current GWT developpers,

For me GWT is "Web development based on Java expertise, with practically no other technology implications". Extremely powerful and pleasant. Seems that GWT 3.0 is announced as "no more GWT":

Our plan will probably to stay with 2.8... But will 2.8 ever be released ??? Developers have been waiting for it for so long... GWT's communication is very strange and paradoyal.

[Thomas Broyer]

On Thursday, July 7, 2016 at 11:54:11 AM UTC+2, Philippe Gonze wrote:

Totally agree. GWT 3.0 without RPC would be GWT 3.dead for many of the current GWT developpers,

For me GWT is "Web development based on Java expertise, with practically no other technology implications". Extremely powerful and pleasant. Seems that GWT 3.0 is announced as "no more GWT":

From http://www.gwtproject.org/makinggwtbetter.html: “GWT’s mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser.”

Also pay attention to what GWT is NOT about.

GWT 3.0 as described in this thread would still follow this mission statement.

Providing tools to do RPC, even if differently than today, would still follow the design axioms. But RPC in itself is about making compromises on AJAX use ("obscure" payload, asymmetrical payload because they were not meant to be parsed by the same tools and in the same environments, everything sent to the URLs, etc. all of this make it impractical at best to use RPC along with, for example, service workers), and that will eventually degrade the web experience for users. Moving away from RPC is actually trading development "convenience" for a better user experience.

 

Our plan will probably to stay with 2.8...

And this is exactly why GWT 2.x and GWT 3 are expected to coexist for a while.

[Velusamy Velu]

I have developed a few GWT applications but never used the RPC. I didn't feel comfortable using RemoveService, RemoteServiceServlet, and ServiceDef; it reminded me the days of CORBA and IDL. I have been staying with extending the RequestCallback.

[Gilberto]

When I first used GWT, I started using GWT RPC as the main communication channel with the server. Years later, when I first needed a native mobile application, and when I needed to expose API endpoints to partners to integrate data with my services, I realized I should have gone RESTful from day 1 - migrating from GWT RPC to a RESTful architecture was painful and slow.

GWT RPC is easy to implement and close to other Java communication technologies (like RMI), but in my experience can create several problems in the long term.

Having said that, I'm always ok with options. GWT won't support GWT RPC in the future, but nothing stops anyone from porting the current GWT RPC mechanism to GWT 3. Of course several stuff would need to change (because of the generators), but I'd imagine it's totally doable.

[Mark Erikson]

I built an app using GWT and GWT-RPC in 2011-2012, but am currently working on a clean-slate rewrite of the client using modern JS (ES6, React, Webpack, etc).  I've opted to leave the existing client codebase entirely as-is, and have exposed my existing backend APIs over JSON-RPC as well.  This is allowing me to make some pretty good progress on the new client without having to make significant changes to the backend or the existing client.  It's also very nice to finally be able to examine my network calls in a browser debugger, and since JSON-RPC is language-independent, would also make it feasible to call those APIs in other contexts if I ever wanted to.

[Hristo Stoyanov]

Gwt-rpc had siMilar fate as RMI in java - it was cute idea at first, but we wish it was not in modern java...

[Chad Vincent]

Hey, speak for yourself.  ;)

RMI is awesome for prototyping or when the networking aspects are a secondary feature where performance isn't an issue.  Maybe better off as a library, but still useful.

[Kay Pac]

Will the gwt serialization mechanism used in GWT-RPC remain? GWT object serialization has been plugged into the atmosphere (realtime communication/websockets) GWT extension. It would be useful to know if we should migrate away from the GWT serialization and towards JSON.

[Paul Robinson]

On 13 Jul 2016 9:17 a.m., "Kay Pac" <kmjs...@fastmail.fm> wrote:
>
> Will the gwt serialization mechanism used in GWT-RPC remain? GWT object serialization has been plugged into the atmosphere (realtime communication/websockets) GWT extension. It would be useful to know if we should migrate away from the GWT serialization and towards JSON.

It's the serialisation that's the problem, so it will be gone in 3.0. JSON is a good choice. (I'm moving that way)

Paul

[Thomas Broyer]

The actual problem is not serialization per se, it is that the RPC generator scans the whole classpath for subclasses of transferred classes to generate their specific ser/deser code (taking into account their CustomFieldSerializer if one exists).

RPC (thus probably Atmosphere) could be made to work (as annotation processors) if they use another mechanism to determine what can be transferred (e.g. annotations similar to RequestFactory's @ExtraTypes).

I believe Daniel Kurka said something along those lines a year ago when first talking about those changes. The logical next question is: is there anyone willing to make those changes and continue to maintain GWT-RPC? The answer seemed to be (have been?) "at least that won't be Google", and this is why people start to "panic". That does not mean RPC will be gone (that doesn't mean it'll still be there either).

But let's concentrate on 2.8 for now.

[Vassilis Virvilis]

just a side note on this

Although GWT-RPC is the easy low threshold for someone coming from the java world SOAP, RMI (like me) two things that didn't fly well were:

1) GWT-RPC favors overspecifying the collection type. So it is better to say ArrayList > List > Collection in your interfaces.

2) It was difficult to share server side code without including GWT specific jars. So I had to create proxies for my SOAP services which was problematic. With Resty-GWT at least my server code can have multiple types of clients js, java, GWT etc.

   Vassilis

--

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 google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

Vassilis Virvilis

[JonL]

While I agree that it could theoretically work with annotations, annotations require access to code, so for things you have no control over, you either would need to implement custom serialization anyways, or use the GWT serialization.

I personally think there are optimizations to be had in the serialization policy generator that would prevent that whole classpath rescan issue, but I haven't had a chance to look into the code.

If we were to use annotations, I think it would be better to use annotations on the RPC mechanism.

[Daniel Kurka]

I summed up what I think about GWT RPC and it's future here:

http://blog.daniel-kurka.de/2016/07/gwt-rpcs-future.html

--

[Ali Jalal]

Thanks Daniel for detailed post about GWT-RPC.

[clou...@gmail.com]

We've been using GWT-RPC for a while now as well, and the alternatives seemed less desirable the last time I poked around at them.  Reading over some of the cited poor choices GWT-RPC, they seem to me to be more like "features" and "trade-offs" instead of simply being bad choices.

Version skew is a good example. It's cited as a negative, but in other contexts is actually a positive.  The client has outdated information regarding the service/model objects? It SHOULD blow up. Old/new clients/servers communicating with each other I'm sure is commonplace at Google and in it's related applications, however this is absolutely unheard of in a static deployment environment, such as in consumer or enterprise deployments.  Version skew actually catches deployment errors during testing in those situations.

The compile time argument has me scratching my head. I've listened to many presentations from Ray/Daniel regarding GWT (big fan, btw). The compiler is often cited as what separates GWT from those other JS lib technologies. I especially liked Daniel's dig at Angular via Singular, but it was a good demonstration of how powerful compile time analytics can trump a runtime library. To paraphrase: we have a powerful compiler, let it do work for you, you can't get that from <insert latest JS lib here>.

To cite GWT-RPC as requiring the compiler time-hit that it does strikes me as a choice/trade-off, not a negative.  For some applications, it may be a "good thing" (tm), but a "bad thing" (tm) in others (see version skew above).  To me, this feels like GWT is a little self-conflicted. We have this compiler, it could do a lot of work for us, but we don't want it to do too much work for us because we want it to be lightning fast!  Maybe I'm just old-fashioned, but I'm ok with compilers taking extra time if it serves some value/purpose.

While I know there is this great "quest" to speed up GWT compiles such that developing in GWT has very little overhead as compared to just regular JS development, I would implore that a "carrot" approach is taken over the "stick."  If, as a developer, I'm willing take a compile time hit for a feature (GWT-RPC or otherwise), seems like having the option would be a "good thing", while on the other hand the GWT compilation speed can still be lightning fast when we ask less of the compiler by not using such features.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.

[Thomas Broyer]

>
The compile time argument has me scratching my head.

I can't find any such argument in Daniel's blog post. The problem certainly is not compile time vs runtime, it's about global knowledge, scanning the whole compile classpath (which is slow) and assuming it'll be similar to the runtime classpath: add a JAR to the classpath and see your compiled size blow up. Having an @ExtraTypes-like annotation to act as a whitelist would solve this and likely allow RPC to be done as an annotation processor.

[clou...@gmail.com]

>
The compile time argument has me scratching my head.

I can't find any such argument in Daniel's blog post.

"Slow compiles due to global analysis" section. Specifically talks about the global knowledge vs incremental compile issue.

[Thomas Broyer]

That section doesn't touch on "To paraphrase: we have a powerful compiler, let it do work for you, you can't get that from <insert latest JS lib here>." It talks about the fact the mere presence of a class in the compile classpath changes the output, and the difficulty of tracking dependencies: add an "implements X" to a class and a totally different part of the application could "need" to be recompiled (re-generated), just because it references "X" (but not the class that was changed). This is not about *whether* to use the compiler but rather how to use it efficiently.

[clou...@gmail.com]

I was contrasting the blog post to the presentations Ray/Daniel have given in the past, hence the Singular example preceding what you are quoting.  These are on youtube and I've also attended their presentations in person.

I'm not trying to argue the compilation efficiency of GWT-RPC or get an explanation of why it is so slow or say there aren't alternatives.  If I am giving off those impressions, I apologize.

I am attempting to point out (poorly I suppose) that the value of the feature largely stems from one's perspective or point of view.  When one uses GWT-RPC, one trades the compile-hit for the functionality.  Similarly with SOYC reports or massive numbers of permutations, you can generate them, however they incur a time/space cost.  These are choices, they have costs, and my point has largely been to let the users decide if the trade-offs fit their needs or not. (Please don't explain how SOYC/Perms don't impact incremental compile!)

Most of the GWT-RPC criticism here (and in the blog post) are purely technical detail about some of its shortcomings and its impact on incremental compile.  From the detailed technical point of view, Daniel/Thomas make accurate observations and there is not much to discuss.  However, at the feature level of GWT-RPC, given its flaws/quirks, many folks would still opt to use it in at least some situations with the cost it incurs.

[JonL]

Agreed, it's all a matter of perspective.  I use GWT-RPC alot, I actually don't see anything wrong with the underlying mechanisms, except for the SerializationPolicy and its generator.  It's the SerializationPolicy generation that is the main culprit for the deficiencies perceived in GWT-RPC.  However, I think that they don't have to be part and parcel and in GWT 3.0, I would personally like to see them separated and the SerializationPolicy made pluggable, instead of ripping out GWT-RPC.  IMO, if the Serialization policy generation were made pluggable, then we could have different solutions that provide different tradeoffs and GWT devs could choose the solution that best suits them.

[gwtar...@gmail.com]

A bit of a long pause but I was busy...

Re:

>> ... But RPC in itself is about making compromises on AJAX use ("obscure" payload, asymmetrical payload because they were not meant to be parsed by the same tools and in the same environments, everything sent to the URLs, etc. all of this make it impractical at best to use RPC along with, for example, service workers), and that will eventually degrade the web experience for users. Moving away from RPC is actually trading development "convenience" for a better user experience.

Development convenience = better developer experience. End-user experience has nothing to do with obscure or asymmetrical payloads. That is an implementation detail. It is also something that can be changed, improved if it needs to be.

Re all recommendations for other frameworks:

Thanks, but many of us are aware of them and they do not solve the problem. It is important to note that there are differences in the problems being solved by these. One kinds deals with exposing network-accessible APIs to 3rd part clients. The other kind is *strictly* intended for internal communication.

The first generally dictates the API definition first, in some way that can be used across versions and with different languages and other technologies. None of this is important in the second case. What is important is the efficiency of making calls between two parts of the same product (client, server). That *very* much so includes developer convenience, because they will have more time to work on what matters. Furthermore, by focusing on the same language on both ends of the connection it becomes possible to actually share code and avoid pitfalls that many make when attempting to create their own approaches (even if it means using ready-made frameworks - one would have to map language features). 

Examples of where GWT RPC *COULD* excel and others fail miserably:

 i)    Development convenience - speed of development, more time left for what matters.

 

 ii)   Development convenience - less risk of defect due to forgotten configuration or otherwise.

 

 iii)  Development convenience - less to learn, quicker to start. No need to learn anything new re how to configure/annotate anything to make the class serializable.

 

 iv)   Development convenience - shared code - same code can be used everywhere, no separation into client and server.

 

 v)    Support for cyclic graphs - Object "A" can reference "B" and "B" can reference "A". If you send both, you still have two objects to deal with, not four or infinity. This *is* important.

 

 vi)   Runtime performance (yes!) - because of (v).

 

 vii)  Runtime performance (yes!) - because developers can rely on highly optimized framework implementation that "knows" exactly what is under the hood and is not overly generic. It can directly reference generated JavaScript code (as obfuscated) as needed and, thus, shorten both payloads and execution time.

  

 viii) Works out of box

 

 ix)   Does not need any extra frameworks to be brought in, version matched, etc.

 

 x)    Can follow (Java) language improvements in step with GWT.

 

 xi)   Emulates more of Java - specifically "Serializable".

 

 xii)  "I can use 3rd party code that does NOT have to know anything about the framework I am using and I don't have to teach it anything either". 

 

 xiii) Works with private fields too.

 

Note:

 1. Yes, GWT compiler has to analyze a lot to figure out serialization. But so would any other framework that would attempt to do as much. At the same time, being a part of the compiler, GWT RPC processing can actually cache a lot and significantly shorten the compilation time - base Java and GWT libraries do NOT change within the scope of use of a single GWT SDK and third party libraries change rarely. Furthermore, it seems to me based on observations, that GWT goes over the analysis multiple times (i.e. does not cache stuff even in memory, at least in part).

 

 2. Yes, GWT RPC is downright NASTY to apply as it is today. But this can be improved greatly. We wrapped it to address that, inside GWT this would be easier. For us it is enough to annotate a method of a server class with a single annotation to make it appear on the client side, as *that* method, in *that* class, without having to (hand-) create any interfaces. We can also combine and batch calls - in fact they all go through one single GWT RPC method of a single service. For example, if there was a "Server" class in the server and it had methods "log(Object)" and "getRandomNumberGenerator()", one *could* invoke Server.log(Server.getRandomNumberGenerator().generateRandomNumber()) by writing exactly that line of code, client or server. Disclaimer: in this case the client would not be aware of the end result/success of that. Passing an additional AsyncCallback argument to the Server.log(...) call would allow for that too - it does in our implementation. Note that this approach mostly utilizes the serialization ability of GWT RPC and it only uses a single method for all communication. All this is done by a set of base classes (that are entirely generic) and annotation-triggered code generation (based on server-side code annotations). Client code or common code (serializable classes) do not need to be annotated at all.

 

 3. As "clou...gmail.com" suggests, version skew is NOT a negative in this context ... and this is a huge context. It is actually positive. At the same time, this is not unsolvable at all.

 

 

[juan ronquillo]

gRPC has now browser support https://github.com/grpc/grpc-web , Any news about GWT-gRPC integration