On Mon, Sep 12, 2016 at 10:46 AM, <leifurha...@gmail.com> wrote:

> Is the idea to provide asynchronous / async-friendly APIs on the stub,
> service, or both?

The feature requests we've received cover both although I think we've
gotten more on the stub side. Since dynamically the two uses would be
separated by many layers of code and perhaps some physical distance over a
network, the reasons for developing them together would be... API style
consistency? Which is plenty important, but does any other reason come to

Based on my experience, I think designing an asynchronous api for rpc
> services is probably trickier, particularly for streaming replies. The
> simple and developer-user friendly generator idiom for streaming replies
> doesn't translate to asyncio coroutines, which can only return once.
> Coroutine generators are not implemented in python 3.5, see
> https://www.python.org/dev/peps/pep-0492/#coroutine-generators
> What I think this means is that an asynchronous rpc method with a
> streaming reply would have to push elements onto a queue or other object
> representing a stream, rather than returning them directly. Something like
> the following:
> async def MethodWithStreamingReplies(request, reply_stream):
>     while some_condition:
>         item = await some_coroutine()
>         reply_stream.push(item)
>     reply_stream.close()

For my own clarity: the preceding is a sketch of stub-side code within gRPC
Python (or generated by gRPC Python)? How do you think the corresponding
application-authored code would look?

Thanks for contributing,

You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to