Igal, Thanks for the answers. Is there any JS SDK available?
Best, --Omid On Tue, Jul 20, 2021 at 10:23 AM Igal Shilman <i...@ververica.com> wrote: > 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 >> > -- ------------------------------------------- Omid
