Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
In Defense of GWT-RPC
Presenter:
Colin Alworth
Co-Founder
colin@vertispan.com
RPC is horrible and you
should stop using it.
Presenter:
Colin Alworth
Co-Founder
colin@vertispan.com
3
GWT-RPC’s Problems
• Funny Interfaces
• No lambda support
• Reachable type explosion
• Not human readable
• Doesn’t use ...
4
GWT Serialization Alternatives
• RequestFactory
• …plain AutoBeans?
• JSOs JsInterop beans
• Gwt-Jackson
• Wrap protobuf...
RPC RequestFactory AutoBeans JsInterop
Gwt-
Jackson
Protobuf
Funny
Interfaces
X OK ? ? ? ?
No
Lambdas
X X ? ? ? ?
Reachabl...
6
RPC is crap.
• …might not be a fair assessment
• Some of this is a bit subjective
• Criteria are picked out against RPC
7
Points we skipped
• Supports polymorphism (beats all but gwt-jackson)
• "Feels" like Java (beats all) for easier adoptio...
8
Generators revisited
• APT didn’t exist when Generators came about
• Even RequestFactory was written after APT
• Uses AP...
9
The "whole world"
• How much of an app is serializable?
• "shared" module
• shared dependencies
10
J2CL suggestions
• Keep modules smallish, keep client/server separate
• Facilitates incremental (faster) recompilation
...
11
Whole APT world
• In APT, largest "world" is files changed in last
compile
• Clean build - all files
• Incremental build ...
12
Whole APT world
• All this leaves is…
13
(back to this in a minute)
14
Lambda Support
• Why not support Java 8?
• Generators.
• Adding this will require a new, APT-based
implementation
15
Lambda Support: point awarded?
16
Supporting all subtypes
• Except gwt-jackson, these others support no
polymorphism
• For JsInterop/JSO, this includes c...
17
Supporting all subtypes
• "Collections": why we need more than just a single
shared module
• JRE code
• Useful librarie...
18
Options to find all types
• Classpath scanning
• Somewhat expensive
• Assumes (in J2CL) that all are gwt-compatible
• A...
19
"All" vs "Too Many" types
• Becomes a problem of configuration
• Offer multiple options, pluggable tools?
• Or do we ass...
20
Options to find "all" types
• Somehow limit reach of processor
• By dependency
• By package
• By rules
• Limit or warn ...
21
Configured subtypes: +1?
22
Not human readable
• JSON is pretty readable after beautifying it
• Rewriting with APT gives us the exact same server
a...
23
Not human readable: half credit?
24
Doesn’t use X
• We can’t play flavor of the month and rewrite to
support everything
• No Protobuf for GWT impl exists…
•...
25
Doesn’t use X
ALL OPTIONS
FAIL THIS TEST
26
Changing versions = incompatibility
• "NoSQL" means "NoSchema", just never change
your app, then you won’t need columns!
27
Changing versions = incompatibility
• This is a feature of RPC that JSON is lacking
• Protobufs solves it differently… ...
28
Changing versions = incompatibility
• If you need one server to support many client
versions, avoid changing types, or ...
29
Versioning - one right answer for all?
30
Code Size
• What makes code size big?
• Too many types? Too many unused types?
• Too many unused properties server stil...
31
Code Size
• What makes code size big?
• I don’t believe this argument applies to RPC.
32
Huge app from type explosion
• List vs ArrayList
• Map vs HashMap
• One FieldSerializer per supported class
33
Contrast "huge"
• AutoBeans must have code to copy each property
• Protobuf must have code per property (and support
al...
34
Huge app from type explosion
• How big is big for an app?
• How huge is huge for an explosion?
• I’ve never seen concre...
35
Place your bets
Simple test:
• control (simple app)
• RequestBuilder, one call
• AutoBeans, one RequestBuilder call
• R...
36
Place your bets, cont’d
RPC tests:
• void method with no params
• String method, String param
• List Method, List param...
37
RequestBuilder, one call
RF, one empty bean, one call
AutoBeans, one RequestBuilder call
GWT-Jackson, one RequestBuilde...
38
Results (not in recording)
• RequestBuilder is a baseline, everything else uses
it anyway
• Jackson is pretty big for a...
39
RequestBuilder, one call
RF, one empty bean, one call
AutoBeans, one RequestBuilder call
GWT-Jackson, one RequestBuilde...
40
Results (slide not in recording)
• RPC is only bigger than plain RequestBuilder (since
it uses RequestBuilder
• Let’s a...
41
void method, no params
String method, String param
List method, List param
Set method, Set param
Map method, Map param
...
42
Results (slide not in recording)
• Without adding Guava, the biggest possible
explosion of List/Set/Map type is still s...
43
Results (slide not in recording)
• This means that the Guava numbers are the worst
possible case: telling RPC that all ...
44
Results (slide not in recording)
• None of these figured account for gzip
45
Type Explosion: Not so bad?
• (bullets not in recording)
• Unless you are deliberately making types or adding
libraries...
46
RPC for a new GWT
• Annotation processor
• Support two JVMs, support version check
• Shared module, not package
• Alrea...
47
RPC for a new GWT
• Drop ancient browsers
• No more IE6-specific hacks, IE9 memory leak
• TypedArrays?
• Better packing ...
Upcoming SlideShare
Loading in …5
×

In defense of GWT-RPC By Colin Alworth

621 views

Published on

"In defense of GWT-RPC "
By Colin Alworth
#GWTcon2017 Florence Setptember 28-29th 2017

Published in: Technology
  • Be the first to comment

  • Be the first to like this

In defense of GWT-RPC By Colin Alworth

  1. 1. In Defense of GWT-RPC Presenter: Colin Alworth Co-Founder colin@vertispan.com
  2. 2. RPC is horrible and you should stop using it. Presenter: Colin Alworth Co-Founder colin@vertispan.com
  3. 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. 4 GWT Serialization Alternatives • RequestFactory • …plain AutoBeans? • JSOs JsInterop beans • Gwt-Jackson • Wrap protobuf.js • Reimplement Protobuf/g-rpc
  5. 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. 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. 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. 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. 9 The "whole world" • How much of an app is serializable? • "shared" module • shared dependencies
  10. 10. 10 J2CL suggestions • Keep modules smallish, keep client/server separate • Facilitates incremental (faster) recompilation • Requires a distinct shared module
  11. 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. 12 Whole APT world • All this leaves is…
  13. 13. 13 (back to this in a minute)
  14. 14. 14 Lambda Support • Why not support Java 8? • Generators. • Adding this will require a new, APT-based implementation
  15. 15. 15 Lambda Support: point awarded?
  16. 16. 16 Supporting all subtypes • Except gwt-jackson, these others support no polymorphism • For JsInterop/JSO, this includes collections!
  17. 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. 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. 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. 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
  21. 21. 21 Configured subtypes: +1?
  22. 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. 23 Not human readable: half credit?
  24. 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. 25 Doesn’t use X ALL OPTIONS FAIL THIS TEST
  26. 26. 26 Changing versions = incompatibility • "NoSQL" means "NoSchema", just never change your app, then you won’t need columns!
  27. 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. 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. 29 Versioning - one right answer for all?
  30. 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. 31 Code Size • What makes code size big? • I don’t believe this argument applies to RPC.
  32. 32. 32 Huge app from type explosion • List vs ArrayList • Map vs HashMap • One FieldSerializer per supported class
  33. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 44 Results (slide not in recording) • None of these figured account for gzip
  45. 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. 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. 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

×