You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have this fluff all around the example.
There are two possible solutions:
Simply put that logic in the Connection module in grpc-lwt (and in grpc-async respectively)
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.
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.
Currently we have this fluff all around the example.
There are two possible solutions:
Simply put that logic in the
Connection
module ingrpc-lwt
(and ingrpc-async
respectively)Develop a more robust solution implementing grpc channels, excerpt from the docs:
More about channels:
The text was updated successfully, but these errors were encountered: