Cap'n Web: a new RPC system for browsers and web servers • Hacker News Board

Re: Cap'n Web: a new RPC system for browsers and web servers

#21

Post by vmg12 » Mon, Sep 22, 2025, 4:09 PM UTC

I see that it supports websockets for the transport layer, is there any support for two way communication?

edit: was skimming the github repo https://github.com/cloudflare/capnweb/tree/main?tab=readme-o...

and saw this which answers my question:

> Supports passing functions by reference: If you pass a function over RPC, the recipient receives a "stub". When they call the stub, they actually make an RPC back to you, invoking the function where it was created. This is how bidirectional calling happens: the client passes a callback to the server, and then the server can call it later.

> Similarly, supports passing objects by reference: If a class extends the special marker type RpcTarget, then instances of that class are passed by reference, with method calls calling back to the location where the object was created.

Gonna skim some more to see if i can find some example code.

Re: Cap'n Web: a new RPC system for browsers and web servers

#22

Post by chrisweekly » Mon, Sep 22, 2025, 4:11 PM UTC

random3 wrote: post #19

It's inspired by and created by a coauthor of [Cap'n Proto]( https://capnproto.org ), which is also what OCapN (referenced in a separate comment) name refers to. Cap'n Proto is inspired by ProtoBuf, protobuf has gRPC and gRPC web. We've been using ProtoBuf/gRPC/gRPC-web both in the backends and for public endpoints powering React / TS UI's, at my last startup. It worked great, particularly with the GCP Kubernetes inf…

100% agreed (as will anyone sane who's tried to use it), grpc-web is a trainwreck.

Re: Cap'n Web: a new RPC system for browsers and web servers

#23

Post by chrisweekly » Mon, Sep 22, 2025, 4:14 PM UTC

kentonv wrote: post #9

HDThoreaun wrote: post #7

This a reference to cap'n jazz?

No, in fact this is the first I've heard of Cap'n Jazz. The name "Cap'n Proto" came from "capabilities and protobuf". The first, never-released version was based on Protobuf serialization. The first public release (way back on April 1, 2013) had its own, all-new serialization. There's also a pun with it being a "cerealization protocol" (Cap'n Cruch is a well-known brand of cereal).

aha, the Cap'n Crunch "cerealization" pun is solid

Re: Cap'n Web: a new RPC system for browsers and web servers

#24

Post by kentonv » Mon, Sep 22, 2025, 4:26 PM UTC

divan wrote: post #20

> RPC is often accused of committing many of the fallacies of distributed computing. > But this reputation is outdated. When RPC was first invented some 40 years ago, async programming barely existed. We did not have Promises, much less async and await. I'm confused. How is this a "protocol" if its core premises rely on very specific implementation of concurrency in a very specific language?

What do you mean? Async programming exists in tons of languages. Just off the top of my head, I've used async/await in JavaScript, C++, Python, Rust, C#, ...

Anyway, the point here is that early RPC systems worked by blocking the calling thread while performing the network request, which was obviously a terrible idea.

Re: Cap'n Web: a new RPC system for browsers and web servers

#25

Post by kentonv » Mon, Sep 22, 2025, 4:29 PM UTC

krosaen wrote: post #18

This looks pretty awesome, and excited it's not only a cloudflare product (Cap'n Web exists alongside cloudflare Workers). Reading this section [1], can you say more about: > as of this writing, the feature set is not exactly the same between the two. We aim to fix this over time, by adding missing features to both sides until they match. do you think once the two reach parity, that that parity will remain, or more l…

I think we'll likely keep them pretty close to in-sync, at least when it comes to features that make sense in both.

If anything I'd expect Cap'n Web to run ahead of Workers RPC (as it is already doing, with the new pipeline features) because Cap'n Web's implementation is actually much simpler than Workers'. Cap'n Web will probably be the place where we experiment with new features.

Re: Cap'n Web: a new RPC system for browsers and web servers

#26

Post by jimmyl02 » Mon, Sep 22, 2025, 4:31 PM UTC

This seems like a similar and more feature complete / polished version of JSON RPC?

The part that's most exciting to me is actually the bidirectional calling. Having set this up before via JSON RPC / custom protocol the experience was super "messy" and I'm looking forward to a framework making it all better.

Can't wait to try it out!

Re: Cap'n Web: a new RPC system for browsers and web servers

#27

Post by cbarrick » Mon, Sep 22, 2025, 4:33 PM UTC

What's going on under the hood with that authentication example?

Is the server holding onto some state in memory that this specific client has already authenticated? Or is the API key somehow stored in the new AuthenticatedSession stub on the client side and included in subsequent requests? Or is it something else entirely?

Re: Cap'n Web: a new RPC system for browsers and web servers

#28

Post by kentonv » Mon, Sep 22, 2025, 4:33 PM UTC

fitzn wrote: post #10

Just making sure I understand the "one round trip" point. If the client has chained 3 calls together, that still requires 3 messages sent from the client to the server. Correct? That is, the client is not packaging up all its logic and sending a single blob that describes the fully-chained logic to the server on its initial request. Right? When I first read it, I was thinking it meant 1 client message and 1 server re…

To chain three calls, the client will send three messages, yes. (At least when using the WebSocket transport. With the HTTP batch transport, the entire batch is concatenated into one HTTP request body.)

But the client can send all three messages back-to-back without waiting for any replies from the server. In terms of network communications, it's effectively the same as sending one message.

Re: Cap'n Web: a new RPC system for browsers and web servers

#29

Post by dimal » Mon, Sep 22, 2025, 4:34 PM UTC

Looks very cool, especially passing functions back and forth. But then I wonder, what would I actually use that for?

You mention that it’s schemaless as if that’s a good thing. Having a well defined schema is one of the things I like about tRPC and zod. Is there some way that you get the benefits of a schema with less work?

Re: Cap'n Web: a new RPC system for browsers and web servers

#30

Post by chao- » Mon, Sep 22, 2025, 4:36 PM UTC

kentonv wrote: post #24

divan wrote: post #20

> RPC is often accused of committing many of the fallacies of distributed computing. > But this reputation is outdated. When RPC was first invented some 40 years ago, async programming barely existed. We did not have Promises, much less async and await. I'm confused. How is this a "protocol" if its core premises rely on very specific implementation of concurrency in a very specific language?

What do you mean? Async programming exists in tons of languages. Just off the top of my head, I've used async/await in JavaScript, C++, Python, Rust, C#, ... Anyway, the point here is that early RPC systems worked by blocking the calling thread while performing the network request, which was obviously a terrible idea.

Reminds me of the old "MongoDB is Web Scale" series of comedy videos:

https://youtu.be/bzkRVzciAZg

Some friends and I still jokingly troll each other in the vein of these, interjecting with "When async programming was discovered in 2008...", or "When memory safe compiled languages were invented in 2012..." and so forth.