More niche use case but this would be awesome for communicating between contexts in web app (e.g. web worker, iframe, etc)
Cap'n Web: a new RPC system for browsers and web servers
81–90 of 305 posts
Re: Cap'n Web: a new RPC system for browsers and web servers
#82The section on how they solved arrays is fascinating and terrifying at the same time https://blog.cloudflare.com/capnweb-javascript-rpc-library/#... . > .map() is special. It does not send JavaScript code to the server, but it does send something like "code", restricted to a domain-specific, non-Turing-complete language. The "code" is a list of instructions that the server should carry out for each member of the arra…
[deleted]
Re: Cap'n Web: a new RPC system for browsers and web servers
#83More niche use case but this would be awesome for communicating between contexts in web app (e.g. web worker, iframe, etc)
That's a use case I'm actually already using it for. :)
That's why the MessagePort transport is included.
Re: Cap'n Web: a new RPC system for browsers and web servers
#84Earlier quoted context omitted.
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?
No. Zod gives you TypeScript types corresponding to the schema. So you would only need to write the schema in Zod.
(I do wish it could be the other way, though: Write only TypeScript, get runtime checks automatically.)
Re: Cap'n Web: a new RPC system for browsers and web servers
#85Any idea how its compares to tRPC and oRPC? Wish all such project always had section of 'Why' and explained why it was needed and what it solved that other projects didn't.
I haven't actually used tRPC nor oRPC.
But my understanding is that neither of them support object-capabilities nor promise pipelining. These are the killer features of Cap'n Web (and Cap'n Proto), which the blog post describes at length.
Re: Cap'n Web: a new RPC system for browsers and web servers
#86Earlier quoted context omitted.
Then that means we have to define the interface twice: once in TypeScript and another in Zod?
No. Zod gives you TypeScript types corresponding to the schema. So you would only need to write the schema in Zod. (I do wish it could be the other way, though: Write only TypeScript, get runtime checks automatically.)
I'm familiar with zod.infer but I'm not sure how to use it to produce an interface that would be compatible with RpcStub and RpcTarget, like MyApi in the example in your post:
// Shared interface declaration:
interface MyApi {
hello(name: string): Promise;
}
// On the client:
let api: RpcStub = newWebSocketRpcSession("wss://example.com/api");
// On the server:
class MyApiServer extends RpcTarget implements MyApi {
hello(name) {
return `Hello, ${name}!`
}
}Re: Cap'n Web: a new RPC system for browsers and web servers
#87What would this look like for other language backends to support? Eg would be neat if Rust (my webservers) could support this on the backend edit : Downvoted, is this a bad question? The title is generically "web servers", obviously the content of the post focuses primarily on TypeScript, but i'm trying to determine if there's something unique about this that means it cannot be implemented in other languages. The ser…
Now you've likely been downvoted because you're complaining about downvotes. Which is too bad because you've elicited a great answer from the author. It's usually best to ignore downvotes. Downvoted comments are noticeably grey. If people feel that's unfair, that'll attract upvotes in my experience.
> Now you've likely been downvoted because you're complaining about downvotes.
Fwiw i think it was only once, and i was upvoted after mentioning it. You're right i could have worded it as something more ambiguous, aka "it seems this is unpopular" or w/e, but my edit was in reply to someones feedback (the downvote), so i usually mention it.
No complaint, just a form of wordless-feedback that i was attempting to respond to. Despite such actions being against HN will heh.
Re: Cap'n Web: a new RPC system for browsers and web servers
#88Earlier quoted context omitted.
No. Zod gives you TypeScript types corresponding to the schema. So you would only need to write the schema in Zod. (I do wish it could be the other way, though: Write only TypeScript, get runtime checks automatically.)
I'm familiar with zod.infer but I'm not sure how to use it to produce an interface that would be compatible with RpcStub and RpcTarget, like MyApi in the example in your post: // Shared interface declaration: interface MyApi { hello(name: string): Promise ; } // On the client: let api: RpcStub = newWebSocketRpcSession("wss://example.com/api"); // On the server: class MyApiServer extends RpcTarget implements MyApi { h…
I'll be honest and say I haven't tried it myself.
But my expectation is you'd use Zod to define all your parameter types. Then you'd define your RpcTarget in plain TypeScript, but for the parameters on each method, reference the Zod-derived types.
Re: Cap'n Web: a new RPC system for browsers and web servers
#89Earlier quoted context omitted.
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.
Async/await became ergonomic and widespread only recently, I am sure there were async systems in the '80 but for example nodejs focus on non blocking I/O changed how a lot of people thought about servers and concurrency (whether node was first is almost irrelevant)
Often when something is discovered or invented is far less influential[1] than when it jumps on and hype train.
[1] the discovery is very important for historical and epistemological reasons of course, rewriting the past is bad
Re: Cap'n Web: a new RPC system for browsers and web servers
#90The section on how they solved arrays is fascinating and terrifying at the same time https://blog.cloudflare.com/capnweb-javascript-rpc-library/#... . > .map() is special. It does not send JavaScript code to the server, but it does send something like "code", restricted to a domain-specific, non-Turing-complete language. The "code" is a list of instructions that the server should carry out for each member of the arra…
In C#, there's expression trees which handle things like this and it's how Entity Framework is able to convert the lambdas it's given into SQL. This means that you can pass around code that can be inspected or transformed instead of being executed. Take this EntityFramework snippet:
db.People.Where(p => p.Name == "Joe")
Since JS doesn't have this, they have to pass in a special placeholder value and try to record what the code is doing to that value.