Closed c-cube closed 11 months ago
There is no more question: we now generate code that will work with any concrete RPC implementation. I'm working on one in a private repo, and there's a toy Twirp implementation in #215, and a toy ZMQ implementation in #218 .
The generated code is even more general now, it doesn't have any idea how streams/handlers/futures are represented. Concrete RPC libraries have to do a bit more work on the server side now, but at least it means the code should be usable from Lwt, Eio, sync code, etc.
this needs serious testing, and relies on #213 .
A question is: do we want to ship various runtime transports for the services, or is that best left to other libraries? For example, do we want a
pbrt-twirp-cohttp-lwt
library that takes any('a, 'b) Pbrt_service.Client.rpc
and gives back a'a -> ('b, Pbrt_service.rpc_error) result Lwt.t
(ie it encodes the query, sends it, reads the result, deserializes the result, and return that).