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 google-web-toolkit+unsubscribe@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.
No comments:
Post a Comment