Provide opinionated cruft around client side connection and stream management
Currently we have this fluff all around the example.
There are two possible solutions:
-
Simply put that logic in the
Connectionmodule ingrpc-lwt(and ingrpc-asyncrespectively) -
Develop a more robust solution implementing grpc channels, excerpt from the docs:
Channels are a key concept in gRPC. Streams in HTTP/2 enable multiple concurrent conversations on a single connection; channels extend this concept by enabling multiple streams over multiple concurrent connections. On the surface, channels provide an easy interface for users to send messages into; underneath the hood, though, an incredible amount of engineering goes into keeping these connections alive, healthy, and utilized.
More about channels:
- https://grpc.github.io/grpc/core/md_doc_connectivity-semantics-and-api.html
- https://docs.microsoft.com/en-us/aspnet/core/grpc/performance?view=aspnetcore-6.0
I think we should aim to provide more robust support for channels (option 2). This includes implementing the state machine as well as retries with exponential backoff. We can also handle lifecycle management of the connection here as per our recent discussion.