We should offer a way to bridge Cap'n Web to Cap'n Proto. People writing servers in languages like C++, Rust, or Go probably prefer to use an IDL+code generator like Cap'n Proto, rather than use TypeScript types.
In this model, the interface is defined primarily by a .capnp file. We'd need a code generator which produces corresponding TypeScript types, and a proxy implementation which converts between the protocols.
Most of the heavy-lifting for this proxy is actually already implemented in the Workers Runtime, though not exposed publicly yet. Namely, we have a mechanism for a Worker to include Cap'n Proto schemas with its source code, and then the runtime dynamically generates a JavaScript API based on them. This is currently used by first-party workers to call edge services.
Currently, none of this is exposed publicly, although much of the implementation is in workerd.
We should offer a way to bridge Cap'n Web to Cap'n Proto. People writing servers in languages like C++, Rust, or Go probably prefer to use an IDL+code generator like Cap'n Proto, rather than use TypeScript types.
In this model, the interface is defined primarily by a
.capnpfile. We'd need a code generator which produces corresponding TypeScript types, and a proxy implementation which converts between the protocols.Most of the heavy-lifting for this proxy is actually already implemented in the Workers Runtime, though not exposed publicly yet. Namely, we have a mechanism for a Worker to include Cap'n Proto schemas with its source code, and then the runtime dynamically generates a JavaScript API based on them. This is currently used by first-party workers to call edge services.
Currently, none of this is exposed publicly, although much of the implementation is in workerd.