Hi, Your observation is correct, currently the only way to invoke a remote function is trough an HTTP POST request to a service that exposes a StateFun endpoint.
The endpoint must implement the client side of a the “RequestReply” protocol as defined by StateFun (basically an invocation contains the state and message, and a response contains a description of the side effects). While gRPC can be easily added a as a replacement for the transport layer, the client side (the remote function) would still have to implement the RequestReply protocol. To truly utilize gRPC we would want to introduce a new type of protocol, that can exploit the low latency bi-directional streams to and from the function. While for the later it is a bit difficult to commit for a specific date the former can be easily implemented in the next StateFun release. Would you be able to share with us a little bit more about your original motivation to ask this question :-) This would help us as we gather more and more use cases. For example: target language, environment, how gRPC services are being discovered. Thanks, Igal On Thursday, September 17, 2020, Dalmo Cirne <[email protected]> wrote: > Hi, > > > > In the latest Flink Forward, from April 2020, there were mentions that > adding support to gRPC, in addition to HTTP, was in the works and would be > implemented in the future. > > > > Looking into the flink-statefun <https://github.com/apache/flink-statefun> > repository on GitHub, one can see that there is already some work done with > gRPC, but parity with its HTTP counterpart is not there, yet. > > > > Is there a roadmap or an estimate of when gRPC will be implemented in > StateFun? > > > > Thank you, > > > > Dalmo > > > > > > > > > > > > > > > > > > >
