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.
--
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.
