Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.cloudflare.com

Post reply on HN
Print view View original

71–80 of 305 posts

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

#71

Post by spankalee »

kentonv wrote: post #66
spankalee wrote: post #60

Earlier quoted context omitted.

I presume conditionals are banned - sort of like the rules of hooks - but how?

The input to the map function (when it is called in "record" mode on the client) is an RpcPromise for the eventual value. That means you can't actually inspect the value, you can only queue pipelined calls on it. Since you can't inspect the value, you can't do any computation or branching on it. So any computation and branching you do perform must necessarily have the same result every time the function runs, and so…

But you also can't close over anything right?

I did a spiritually similar thing in JS and Dart before where we read the text of the function and re-parsed (or used mirrors in Dart) to ensure that it doesn't access any external values.

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

#74

Post by kentonv »

spankalee wrote: post #71
kentonv wrote: post #66

Earlier quoted context omitted.

The input to the map function (when it is called in "record" mode on the client) is an RpcPromise for the eventual value. That means you can't actually inspect the value, you can only queue pipelined calls on it. Since you can't inspect the value, you can't do any computation or branching on it. So any computation and branching you do perform must necessarily have the same result every time the function runs, and so…

But you also can't close over anything right? I did a spiritually similar thing in JS and Dart before where we read the text of the function and re-parsed (or used mirrors in Dart) to ensure that it doesn't access any external values.

You actually CAN close over RPC stubs. The library will capture any RPC calls made during the mapper callback, even on stubs other than the input. Those stubs are then sent along to the server with the replay instructions.

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

#75

Post by kentonv »

tonyg wrote: post #70
kentonv wrote: post #66

Earlier quoted context omitted.

The input to the map function (when it is called in "record" mode on the client) is an RpcPromise for the eventual value. That means you can't actually inspect the value, you can only queue pipelined calls on it. Since you can't inspect the value, you can't do any computation or branching on it. So any computation and branching you do perform must necessarily have the same result every time the function runs, and so…

Is .map specialcased or do user functions accepting callbacks work the same way? Because you could do the Scott-Mogensen thing of #ifTrue:ifFalse: if so, dualizing the control-flow decision making, offering a menu of choices/continuations.

.map() is totally special-cased.

For any other function accepting a callback, the function on the server will receive an RPC stub, which, when called, makes an RPC back to the caller, calling the original version of the function.

This is usually what you want, and the semantics are entirely normal.

But for .map(), this would defeat the purpose, as it'd require an additional network round-trip to call the callback.

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

#76

Post by kentonv »

Yoric wrote: post #72

That's more or less a dynamically-typed version of what we had with Opalang ~15 years ago and it worked great. Happy to see that someone else has picked the idea of sending capabilities, including server->client calls!

FWIW, Cap'n Proto is a statically-typed version of this that has been around since 2013, and is actually used heavily in the implementation of Cloudflare Workers.

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

#79

Post by ngrilly »

kentonv wrote: post #41
dimal wrote: post #29

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?

You can use TypeScript to define your API, and get all the benefits of schemas. Well, except you don't get runtime type checking with TypeScript, which might be something you really want over RPC. For now I actually suggest using zod for type checks, but my dream is to auto-generate type checks based on the TypeScript types...

Then that means we have to define the interface twice: once in TypeScript and another in Zod?

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

#80

Post by coryrc »

vereis wrote: post #53
doctorpangloss wrote: post #45

Earlier quoted context omitted.

^ maybe the most knowledgable person in the world about these gritty details RPC SDKs should have session management, otherwise you end up in this situation: "Any sufficiently complicated gRPC or Cap'n'Proto program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Akka"

i think the original quote is "Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang" :-) but your point still stands

Not quite :) https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule
Post reply on HN