gRPC implementation in OCaml


Anyone ever dabbled with gRPC with OCaml? E.g. building clients, servers, serializers, etc. I’ve come across piqi-ocaml and ocaml-protoc for serializations, but none for server/client implementations. I’m interested in exploring this, but would rather avoid duplication if there’s an effort or assessment already underway.


I have some libgrpc bindings in progress that will (if finished) work together with ocaml-pb and ocaml-pb-plugin. They’re not online yet.


The lack of gRPC support was one of the reasons why OCaml was not suitable for us at work. I opened an issue on the official gRPC issue tracker when I was researching OCaml.


I am the author of piqi-ocaml. There are no plans for suppoting grpc. I do plan however to add support for Protobuf3 (currently piqi-ocaml supports only Protobuf2) which grpc relies on, and support for some kind of stubs generation for services. This way it would be usable for grpc serialization.

Those who want full grpc support would need to implement grpc protocol in OCaml, but this is strictly outside of the current piqi-ocaml project scope.


That’s good to hear. I was also thinking perhaps binding to the core C libraries can prove to be more efficient while waiting for a pure OCaml implementation of the protocol (which may or may not happen). Sadly I’m currently not really familiar with C, but perhaps it’s all the more reason for me to also dig into it. Would you perhaps be able to share how far the progress have been?

Yeah I also came across this issue when looking around, great to be pointed to the interop tests.

Hi! Thank you for the nice lib.

I agree. I also think such grpc support should live on its own.


Few months ago I had the crazy desire to do an ocaml native implementation (that way would be hopefuly possible to run on mirageos) of grpc, but the problems I’ve found were that there is still no http2 support for cohttp, so I tried to implement that, but then there was no support of ALPN for the ocaml-tls, and then I realised that I’m not very familiar with tls’ internals in order for me to submit a patch, and sadly I stopped.
I’m glad that this matter is being raised again.


I tried going that path also but stopped when I realized that cohttp does not support HTTP/2. It’s concerning that the issue has been open for almost three years. Going forward, it’s crucial to have a reliable gRPC implementation since it’s becoming the defacto standard for microservices communication and cloud-native apps.


Is this the “only” thing blocking cohttp from supporting http/2? It’s good to have some actionables so we can understand what’s currently missing.


No. HTTP/2 is a major change to the HTTP protocol. I would not underestimate the difficulty of implementing reliably multiplexed streams.


Well, it’ll be open until someone has the time to do the very significant chunk of work required :slight_smile:

The first step is probably to encode the http2 binary protocol using Angstrom and Faraday serialisers, and then work upwards from there towards the HTTP interfaces.


I’m currently trying to implement ALPN support for tls:

(If you’re familiar with TLS, please take a look!)

I reckon something would need to be done with ssl as well but dealing with C is not exactly my forte. If protocol negotiation is done I think the next step is to make the clients (e.g. conduit-lwt-unix for cohttp) utilize that information.

I imagine it could go in parallel with the encoding of binary protocol as @avsm said, if anyone is interested to lend a helping hand :smile: