Not yet unfortunately,

But I'd be very much happy to work with the community on a JS SDK.


On Tue, Jul 20, 2021 at 4:32 PM Omid Bakhshandeh <omidbakhshan...@gmail.com>
wrote:

> 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
>

Reply via email to