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.

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

21. 21
Configured subtypes: +1?

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