Skip to main content

Comparison to Cap'n Web

We were days away from releasing @lumenize/rpc and @lumenize/testing when Cloudflare released Cap'n Web (Cloudflare's own last-mile RPC built under the leadership of the father of Durable Objects, Kenton Varga). We went ahead and released @lumenize/testing with full documentation as planned because it had been promised to the community and we soft-released @lumenize/rpc because @lumenize/testing depends upon it, but with almost no docs and those said that we were holding off on recommending it until we'd had a chance to do a deep dive comparison between the two.

At the time, we were thinking of several possibilities:

  1. Cap'n Web would be everything we'd hoped it would be and we'd port all of Lumenize (including @lumenize/testing) over to it.
  2. We'd continue using Lumenize RPC internally and maintaining it, but not strongly recommend it, or at least say when to choose which.
  3. Lumenize RPC would hold up well in comparison, and we'd be able to strongly recommend it.

We're happy to say that today we are delivering that deep dive analysis and are making a strong recommendation for Lumenize RPC.

References​

High Level Comparison​

Similarities​

  • Both magically make it feel like you are working with local resources.
  • Both are new, but based upon significant legacy. The first versions of Lumenize running on Azure go back over a decade. Cap'n Web was built with learning from and designed to feel like Workers RPC even if it shares little, if anything, in terms of code.
  • They also have some architectural similarities:
    • They do their magic using a thenable Proxy
    • While the terminology is different, they both support batching, chaining, and nesting calls where the result of one operation can be used in another one while incurring only a single round trip.
    • Both clients run anywhere JavaScript runs.
    • They each support injecting custom transports via a well-defined interface.
  • They have essentially the same perceived performance which is driven almost entirely by minimizing round trips. We couldn't find a single pattern where their round trip counts differed.
  • Both are small (minify+gzip). Cap'n Web: 10KB. Lumenize RPC: 7KB.
  • Both support using syntax for automatic resource cleanup on the client-side.

Differences​

  • Cap'n Web's server side is designed to run anywhere JavaScript is run, while Lumenize RPC server-side currently only runs in Cloudflare.
  • Lumenize RPC's default transport layer uses Durable Objects hibernating WebSockets. Cap'n Web uses non-hibernating WebSockets even when running on Durable Objects.
  • Cap'n Web supports passing functions as parameters which enable bidirection communication (although we found significant limitations). The as-yet-unreleased LumenizeBase supports server to client communications over hibernating WebSockets.
  • Cap'n Web has a "magic map() method" which can be used to remotely transform a value, without pulling it back locally. In Lumenize, you'd need to call a method that does the transformation.
  • Lumenize RPC provides seemless access to ctx (including storage) and env, even allowing you to use env to hop from the RPC host to another DO (e.g. client.env.DO_BINDING.getByName('instance-name').someMethod() just works). Cap'n Web doesn't allow this.
  • Lumenize RPC supports every type that Workers RPC supports (Set, Map, objects with cycles and aliases, etc.) except Readable/Writable Stream. Type support in Cap'n Web is very limited at the moment. That will improve but objects with cycles or aliases will not be part of that improvement. In fact, Cloudflare plans to remove support for cycles and aliases from Workers RPC.
  • Lumenize RPC maintains no server-side resources. Cap'n Web dedicates ~10% of its documentation to discussing server-side "Resource Management and Disposal".

To continue, proceed to the next comparison document "It just works"