In defense of GWT-RPC By Colin Alworth
1 like1,759 views
RPC is not as bad as often claimed and alternatives have their own drawbacks: - RPC code size is smaller than RequestFactory even with large collections, and comparable to JSON serializers for simple cases. - Type explosion concerns are reduced unless deliberately adding unused library types. - Versioning compatibility is better than JSON and similar to protocols like Protobuf. Overall, RPC performance is reasonable for many apps and a modernized version could address remaining issues like lambda support.
In defense of GWT-RPC By Colin Alworth
- 1. In Defense of GWT-RPC Presenter: Colin Alworth Co-Founder colin@vertispan.com
- 2. RPC is horrible and you should stop using it. Presenter: Colin Alworth Co-Founder colin@vertispan.com
- 3. 3 GWT-RPC’s Problems • Funny Interfaces • No lambda support • Reachable type explosion • Not human readable • Doesn’t use $FAVORITE_TECHNOLOGY • Versioning incompatibility • Huge code size
- 4. 4 GWT Serialization Alternatives • RequestFactory • …plain AutoBeans? • JSOs JsInterop beans • Gwt-Jackson • Wrap protobuf.js • Reimplement Protobuf/g-rpc
- 5. RPC RequestFactory AutoBeans JsInterop Gwt- Jackson Protobuf Funny Interfaces X OK ? ? ? ? No Lambdas X X ? ? ? ? Reachable Type Explosion X OK OK OK X OK Uses Generators X X X OK X OK Not readable X X OK OK OK ? Doesn’t use X X X OK OK OK OK Versioning X X X X X OK Huge Code Size X X X OK X ?
- 6. 6 RPC is crap. • …might not be a fair assessment • Some of this is a bit subjective • Criteria are picked out against RPC
- 7. 7 Points we skipped • Supports polymorphism (beats all but gwt-jackson) • "Feels" like Java (beats all) for easier adoption • Supports useful types: • Date • long • enum
- 8. 8 Generators revisited • APT didn’t exist when Generators came about • Even RequestFactory was written after APT • Uses APT for validation on server • APT can’t see the whole world • Usually we don’t need to
- 9. 9 The "whole world" • How much of an app is serializable? • "shared" module • shared dependencies
- 10. 10 J2CL suggestions • Keep modules smallish, keep client/server separate • Facilitates incremental (faster) recompilation • Requires a distinct shared module
- 11. 11 Whole APT world • In APT, largest "world" is files changed in last compile • Clean build - all files • Incremental build - only changed files • Our shared module may be most of the world we need…
- 12. 12 Whole APT world • All this leaves is…
- 13. 13 (back to this in a minute)
- 14. 14 Lambda Support • Why not support Java 8? • Generators. • Adding this will require a new, APT-based implementation
- 15. 15 Lambda Support: point awarded?
- 16. 16 Supporting all subtypes • Except gwt-jackson, these others support no polymorphism • For JsInterop/JSO, this includes collections!
- 17. 17 Supporting all subtypes • "Collections": why we need more than just a single shared module • JRE code • Useful libraries • Or, we need to expressly forbid this - for some teams, more appropriate
- 18. 18 Options to find all types • Classpath scanning • Somewhat expensive • Assumes (in J2CL) that all are gwt-compatible • Assumes you want all compiled in (size concerns) • Whitelist/Blacklist • Limit certain types? • Compiler warnings on large sets of types?
- 19. 19 "All" vs "Too Many" types • Becomes a problem of configuration • Offer multiple options, pluggable tools? • Or do we assume that all applications are the same? • Everyone should just write proto files! • Or, no one ever needs enums, just use JsInterop!
- 20. 20 Options to find "all" types • Somehow limit reach of processor • By dependency • By package • By rules • Limit or warn on "too general" of types • GWT-RPC already does this for Object
- 22. 22 Not human readable • JSON is pretty readable after beautifying it • Rewriting with APT gives us the exact same server and client code • However we’d still need a tool compiled with the same rules to make this work • (I haven’t written this yet, but can explain it…)
- 23. 23 Not human readable: half credit?
- 24. 24 Doesn’t use X • We can’t play flavor of the month and rewrite to support everything • No Protobuf for GWT impl exists… • …that is generally available and more than an experiment
- 25. 25 Doesn’t use X ALL OPTIONS FAIL THIS TEST
- 26. 26 Changing versions = incompatibility • "NoSQL" means "NoSchema", just never change your app, then you won’t need columns!
- 27. 27 Changing versions = incompatibility • This is a feature of RPC that JSON is lacking • Protobufs solves it differently… with more compiled output • JSON doesn’t solve it at all, code may just fail • Today, RPC gives an error, just requires latest version
- 28. 28 Changing versions = incompatibility • If you need one server to support many client versions, avoid changing types, or use something which expressly supports this • Don’t remove fields when sending to client • Don’t add fields when sending to server
- 29. 29 Versioning - one right answer for all?
- 30. 30 Code Size • What makes code size big? • Too many types? Too many unused types? • Too many unused properties server still sends? • Multiple services supporting the same super- interface used in all beans?
- 31. 31 Code Size • What makes code size big? • I don’t believe this argument applies to RPC.
- 32. 32 Huge app from type explosion • List vs ArrayList • Map vs HashMap • One FieldSerializer per supported class
- 33. 33 Contrast "huge" • AutoBeans must have code to copy each property • Protobuf must have code per property (and support all versions!) • Plain JSON has no copy… • …but has full property names all over app • And either no type safety or… • Per-property checks!
- 34. 34 Huge app from type explosion • How big is big for an app? • How huge is huge for an explosion? • I’ve never seen concrete numbers, just a lot of "RPC is terrible!", so I decided to run some experiments…
- 35. 35 Place your bets Simple test: • control (simple app) • RequestBuilder, one call • AutoBeans, one RequestBuilder call • RequestFactory, one empty bean, one call • GWT-Jackson, one RequestBuilder call • RPC tests (cont’d)
- 36. 36 Place your bets, cont’d RPC tests: • void method with no params • String method, String param • List Method, List param • Map Method, Map param • Collection method, Collection param Repeat above with Guava in project, unused Repeat above with "final" serialization turned on
- 37. 37 RequestBuilder, one call RF, one empty bean, one call AutoBeans, one RequestBuilder call GWT-Jackson, one RequestBuilder call 0 25000 50000 75000 100000 39,424 bytes 9,725 bytes 93,547 bytes 6,705 bytes
- 38. 38 Results (not in recording) • RequestBuilder is a baseline, everything else uses it anyway • Jackson is pretty big for a simple app, but RequestFactory is huge! • AutoBeans are fairly minimal (for a single simple bean) - low overhead compared to the other two
- 39. 39 RequestBuilder, one call RF, one empty bean, one call AutoBeans, one RequestBuilder call GWT-Jackson, one RequestBuilder call RPC, void method, no params RPC, String method, String param 0 25000 50000 75000 100000 7,281 bytes 7,231 bytes 39,424 bytes 9,725 bytes 93,547 bytes 6,705 bytes
- 40. 40 Results (slide not in recording) • RPC is only bigger than plain RequestBuilder (since it uses RequestBuilder • Let’s add every reachable collection in a few experiments…
- 41. 41 void method, no params String method, String param List method, List param Set method, Set param Map method, Map param Collection method, Collection param List method, List param + Guava Set method, Set param + Guava Map method, Map param + Guava Collection method, Collection param + Guava Collection method, Collection param + Guava + Final Map method, Map param + Guava + Final 0 27500 55000 82500 110000 102,298 bytes 99,015 bytes 77,814 bytes 73,378 bytes 58,380 bytes 22,953 bytes 23,678 bytes 19,489 bytes 19,190 bytes 16,044 bytes 7,281 bytes 7,231 bytes
- 42. 42 Results (slide not in recording) • Without adding Guava, the biggest possible explosion of List/Set/Map type is still smaller than RequestFactory (or even gwt-jackson) with no collections at all! • The base application at least used a LinkedHashMap, LinkedHashSet and ArrayList - but never used Guava
- 43. 43 Results (slide not in recording) • This means that the Guava numbers are the worst possible case: telling RPC that all Guava types are allowed, but never using them • If you use Guava, you would likely already have included some of those types, so the worst case scenario of 102KB is actually the worst possible case, not a baseline!
- 44. 44 Results (slide not in recording) • None of these figured account for gzip
- 45. 45 Type Explosion: Not so bad? • (bullets not in recording) • Unless you are deliberately making types or adding libraries that aren’t used in your app, yet are eligible to be serialized, you shouldn’t be worried • Even if you are worried about 20kb in your app, a future RPC tool will have features to tune this better
- 46. 46 RPC for a new GWT • Annotation processor • Support two JVMs, support version check • Shared module, not package • Already a good idea, new suggestion to use J2CL • Controls to pick packages/dependencies to scan, or be specific • Seems like more work? Reasonable defaults? • How often is customizing RPC requested?
- 47. 47 RPC for a new GWT • Drop ancient browsers • No more IE6-specific hacks, IE9 memory leak • TypedArrays? • Better packing of data, esp with GZIP • Pass between workers (or MessagePort) for free • Still compatible with GWT2 • Existing projects can switch for future-proofing