Hi Omid, I'm glad to hear that you are evaluating StateFun in your company! let me try to answer your questions:
1. In version 2.x, StateFun only supported messages of type com.google.protobuf.Any, and we had a tiny optimization that reads type hints and unpacked the real message out of the Any message. Version 3.x removed protobuf from the API surface (hence no more Any) but while Protobuf is not a requirement, you can still use Protobuf to send and receive messages by using [1][2]. 2. The benefits of gRPC in StateFun can be a long discussion, since currently StateFun does use Protobuf over HTTP/2 (if the remote function's app server supports that), and with a built-in backpressure mechanism (backpressure comes from Flink). Having said that, we are currently working on making the transport pluggable, and gRPC based transport is a natural candidate. 3. I think this is a very interesting point, and StateFun doesn't promote any specific paradigm here. The basic building block is a function, a specific function is uniquely addressed by providing a namespace, a function type, and an id. a group of functions that implement a specific API can share a namespace prefix, for example "com.foo.api.auth/". You can perhaps (by convention) have a public function per namespace that exposes some sort of an API (list of messages that it supports) And it can dispatch the messages internally to the various functions. Alternatively, a "client" library for your auth API can be a Python class with named methods that accepts a StateFun context, and translates a method invocation to a message sent to the corresponding function. The clients of your functions will basically invoke methods on an object. Perhaps a generated interface described by gRPC, is a good idea to explore further :-) 4. I'm not sure what KNative example you are looking for, as StateFun remote functions do not require any specific type of deployment, they are like regular Flask services. Looking forward to learning what you've built :-) Good luck! Igal. [1] https://github.com/apache/flink-statefun-playground/blob/release-3.0/python/showcase/showcase/showcase_custom_types.py#L28 [2] https://github.com/apache/flink-statefun-playground/blob/release-3.0/python/showcase/showcase/__main__.py#L89,L91 On Tue, Jul 20, 2021 at 3:07 AM Omid Bakhshandeh <omidbakhshan...@gmail.com> wrote: > Hi, > > We are evaluating Flink Stateful Functions in our company and we are > trying to see if it fits our needs. I'm hoping to get some help from the > community as we do this. > > There are a couple of primary questions that can speed up our process: > > 1- It seems in version 2.2.0, in the Python SDK, it was possible to have > messages with a specific type because everything was Protobuf but in 3.0.0 > that is not possible and there is always some boilerplate to convert > messages. > > @functions.bind("showcase/messaging") >> def messaging(context: Context, message: Message): > > vs > >> def greet(context, greet_request: GreetRequest): > > > Is that right? > > > 2- Is GRPC and maybe more efficient protocols part of the roadmap in the > near future? > > 3- All of the examples I found on the Python SDK, all the function has > been written in a single file with no specific structure (e.g. > implementing an API or ...), is there a better way to create Functions in a > more structured way? How can one share these functions within teams and > other projects? It would be great if something like GRPC services and API > exists for functions so other users can get into the dev cycle. > > 4- Is there any KNative example? > > I hope these questions make sense. > Thanks, > -- > -------- > Omid >
