Thoughts on Cap'n Web

First thing that comes to mind is that it solves a common problem with BFFs on mobile/native: breaking changes are hard or impossible You need some way to compose the primitives on the server, GraphQL solves this with a type system but is hard to adopt because of the required tooling

On the web we don't really have that problem, a BFF can just make a breaking change because it can be locked to the client. In other words we can atomically deploy the client in lockstep with the new BFF version. Older clients aren't gonna stick around for long

Mobile is harder, because old clients stick around for a long time. It's common to introduce GraphQL to solve this, but cap'n web could be an alternative that's easier to adopt

I'm not a huge fan of the proxy magic around promises, and especially not a fan of if on `.map`. Does that stringify the function and execute it on the server? Sounds very hairy.¹

This might present a learning curve that's less like GraphQL's and more like React Server Components. It requires learning some new rules and a new security model (if you're not already doing capabilities). But I think I prefer this to the tooling adoption problem of GraphQL

The other problem GraphQL has is that it requires special protocol affordance for what it calls federation. You can only have a single namespace so you then need to decompose it somehow

I'm not sure what a solution looks like for cap'n web. Maybe you can compose RPCTargets together trivially but I need to play around to see

imagine not supporting these types in the big 2025. common react flight w

It's incredibly easy to wire up in a deno server