Thomas and Paul, Thanks for all the info, I will certainly look into these alternatives. The only problem is that somehow GWT should include a fast generic RPC mechanism. I hate having to depend on 3rd party alternatives that are often writen by one individual to solve his own issue and never maintained. I am writing banking software and we have some strict requirements on what products we are allowed to use since we have some very tight end-user licenses that requires us to fix issues very quickly. But somehow RPC is fundamental to AJAX apps build on GWT and it is a shame that we have almost no support for JSON-REST kind of APIs since that is what most people seem to be using. David
On Wednesday, February 6, 2013 5:17:33 PM UTC+1, Thomas Broyer wrote: > > > On Wednesday, February 6, 2013 4:37:35 PM UTC+1, stuckagain wrote: >> >> Hi, >> >> Not sure where to ask this question, but I was wondering if the GWT devs >> every plan to fix the inefficient GWT-RPC ? >> The problem happens mostly on IE (all versions), although I assume other >> browsers might benefit as well since a lot of cpu cycles are wasted on >> things that should be trivial for a browser. >> >> I had to improve multiple GWT apps that all stumble on these 3 problems: >> - deserialisation is terribly inefficient - it can take many seconds to >> serialize small sets of data, >> - on IE I can get slow script warnings >> - I sometimes get stack over flows with deeply nested structures. >> >> For example when I send over a tree of 10000 nodes (takes 20ms to >> create), it takes 5 seconds or more to deserialize. (I can give you a demo >> app that shows the problem) >> >> I only get 2 seconds to impress my users, and I need to do quite a lot of >> operations besides sending the RPC. >> >> I've heared the reactions multiple times: don't send soo much data over, >> but bytewise this is not soo much. It is highly compressible (just a few K >> in fact) data. We want to process complex data structures in the client, we >> don't want to create intermediate data structures to bypass the RPC >> inefficiencies. >> >> There have been multiple attempts from google to write something better >> (DeRPC whichi is now deprecated, and RequestFactory which is very badly >> documented so I don't even know if I could reuse this one for generic RPC >> calls). >> > > Indeed RequestFactory can be used for "generic RPC". > Have a look at http://tbroyer.posterous.com/gwt-211-requestfactory and > http://tbroyer.posterous.com/gwt-211-requestfactory-part-ii > It's rather old and might be inaccurate in a few places (hasn't been > updated for GWT 2.4's use of annotation-processing at compile-time, for > instance). > > >> >> Is it not time to start using json as the base format for GWT RPC ? I >> would even like to help out to get this working! It is really a pitty that >> somehow RPC is a selling point for GWT but in reality it often becomes the >> bottleneck of your application. >> > >> Can't we maybe put GWT RPC on the framework for request factory ? >> >> One issue I also have with GWT RPC (but less pressing as the >> performanceissue) is the fact that it is not very friendly for mixing >> different client technologies. If it were a simple json REST payload >> (without obfuscation and lots of secret numbers) then we could easily reuse >> it everwhere, it would also make it soo much easier for loadtesting. Not a >> lot of tools support GWT RPC easily. >> > > RequestFactory can easily be used in-process within tests, and ships with > a pure-Java client (usable on Android for instance). It comes with 2 > "dialects" under the same API: its own RequestFactory protocol (JSON-based) > that deals with batching of method calls and sending only diffs for > entities, and JSON-RPC. The server-side component only supports the former > dialect though, the latter is only about using existing JSON-RPC services > (such as Google APIs) from a Java or GWT app. > > That said, I doubt RequestFactory would perform better for your 10000 > nodes use-case (I think we can even say it will perform much worse than > RPC; this can probably be improved by doing more codegen at compile-time > and less reflection at runtime, but I'm not sure it'd even be better than > RPC; this is mostly about the server-side though, and possibly DevMode too; > it should be an all different story if you use the JSON-RPC dialect). > > An alternative to RPC and RF, using (a slightly modified) JSON-RPC > protocol with an RPC-like API is gwt-json-rpc, used by Gerrit: > https://gerrit.googlesource.com/gwtjsonrpc/ You'll find the JAR in a > Maven repo at https://gerrit-maven-repository.googlecode.com/svn/ (Gerrit > itself references https://gerrit-maven.commondatastorage.googleapis.comso I > think the googlecode repo is an old one; the > commondatastorage.googleapis one is not browsable though so it's hard to > tell which artifacts are in there). Look at the README file for details. > > Finally, it's a bit old (almost 4 years old) but it should still apply as > you're talking about IE: Flickr ditched JSON for a custom format for better > performances, maybe you could do something similar: > http://code.flickr.net/2009/03/18/building-fast-client-side-searches/ > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
