As I noted multiple times before, such as here (didn't search more): https://gwtcon.userecho.com/communities/1/topics/3-gwt-30#comment-66
RPC is intergral to the value of GWT (or any similar solution). This should not be confused with public APIs - it isn't good for that and should not be targeting that use case. What is it best for (as in - there is *nothing* better) is linking the parts of otherwise the same application that are separated by the network. Original GWT had/has a lot of problems. From what I've seen, those who hate it focused on either these or misused it for a public API - which it isn't for. The problems themselves aren't unsolvable and the benefits are great. I know this is largely preaching to the choir, but here it is again - try to find another approach that ticks *all* of the following boxes (there are quite a few that don't tick all): 1. Can use the same language (and code) on both sides of the network divide. 2. Do not need to have separate implementations of "DTOs" on each side. Common objects can be communicated in either direction and use the same code. DTOs *are* an antipattern in at least this case (and I would argue most others). Typical arguments revolve around controlling what is exposed (this may be a public API and security concern but could be addressed with custom/filtering serializers and, if enhanced, annotations; the caller could also specify how much is needed using something like projection specifications, JPA entity graphs, etc) and about "forcing one to think hard about what is communicated, for performance reasons" (thinking is always required, if you don't use it in one approach, then don't in another either). DTOs create a huge issue with code duplication, having to code, recode, code again and then some copying of object graphs to/from DTOs where other approaches (such as mentioned) would actually do better. DTOs also cause a loss of logic - methods in main classes that could and should work everywhere - or cause duplication of these. 3. Natural support for preserving instance cardinality - referencing a single object multiple times will not yield multiple instances of it "on the other side". Cyclic references supported. 4. Does not *require* "decorating" the code with anything for it to work. This translates to the ability to use 3rd party code/libraries and communicate their objects that are already marked for (Java) serialization. Step away from this and you enter the world where you cannot easily use two libraries that depend on different (non-Java) serialization. In other words, the only reliable standard is "Java serialization". 5. Compact payloads. 6. Protocol details hidden away, abstracted, so that it can evolve and be enhanced over time without having to redo any of the client or server code. I don't care what is "in" vs not in terms of hype. We use things that have merit and get the job done. If we get it, use will follow. Maybe "RPC" as a term isn't popular any more. I personally don't care about it, but one easy way around this is to break away from that name and use a different one that better aligns with intended purpose. Brainstorming seed terms: application/network bridge, (Java) *O*bject *G*raph transporter/*R*eplicator (OGRe <https://en.wikipedia.org/wiki/Ogre>? :) ), *S*plit *A*pplication *L*inking *T*ransporter (SALT?) - you may not think much of salt but try going without it at all... -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/26d78688-3779-4c2d-b2ab-1a46c193fb09%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
