I would recommend to try the gRPC AsyncIO API, it solves all 3 problems you 
are asking. Here is an example containing the bidi server-side code:

https://github.com/grpc/grpc/blob/master/examples/python/route_guide/asyncio_route_guide_server.py

> Is there a non-blocking way to check if any new requests came in, without 
having to create a separate thread?

In AsyncIO world, you can create a coroutine to consume the requests.

> Is there a way to attach an observer to the stream to process requests as 
they come in?

The request-consuming coroutine can also invoke the logic you want for 
every incoming request.

> Is there a way to get hold of a stream "object" that I can use to send 
responses back from a different thread? From what I have seen, "yield" 
seems to be the only way to stream data back from server to client.

The AsyncIO API's `context 
<https://grpc.github.io/grpc/python/grpc_asyncio.html#server-side-context>` 
object has `context.read()` and `context.write()` method that one can carry 
the logic of an RPC to another coroutine.

---

For sync/normal API:

> Is there a non-blocking way to check if any new requests came in, without 
having to create a seperate thread?

No. We don't have an API for checking.

> Is there a way to attach an observer to the stream to process requests as 
they come in?

Server interceptors might do the trick for you.

> Is there a way to get hold of a stream "object" that I can use to send 
responses back from a different thread? From what I have seen, "yield" 
seems to be the only way to stream data back from server to client.

You need to build your own pipe (Pipe 
<https://github.com/grpc/grpc/blob/fd3bd70939fb4239639fbd26143ec416366e4157/src/python/grpcio_tests/tests/interop/methods.py#L135>
 
example).



On Tuesday, August 3, 2021 at 3:11:07 PM UTC-7 Akhilesh Raju wrote:

> Hi all,
>
> At a very high level, I have a BiDi stream between a python grpc server 
> and node grpc client.
> The client sends a request to the server to start streaming of data back 
> to the client. At any time, the client can decide it wants to stop the 
> streaming of data from the server and send a request to the server to do 
> the same.
> For example purposes, the data streamed back by the server is a simple str 
> representation of the current timestamp.
> The proto file and server python code can be found here - GitHub Gist 
> <https://gist.github.com/akhileshraju/6cecd5973fbe3b9ea39badc6de17cd8d>
>
> Here is what I would ideally like to do
>
>    1. Send stream start request from client to server
>    2. Server receives it and starts sending back data as and when its 
>    produced, without any intervention from the client
>    3. After some time T, the client decides that it wants to stop the 
>    stream and sends a stop request to the server
>    4. The server received the request and stop sending any more data.
>
> The def TimeStream function is provided with 2 things - a request 
> iterator and context. When I try to fetch requests from the 
> request_iterator via next(request_iterator), if there are no pending 
> requests, the next() statement blocks till a new request comes in.
> To continuously stream data back from the server and also process incoming 
> requests from the client, I had to create a new thread to fetch requests 
> through the request_iterator, allowing the originial thread the request 
> came on, free to "yield" values.
> This can be seen in lines 80-135 in the server.py file 
> <https://gist.github.com/akhileshraju/6cecd5973fbe3b9ea39badc6de17cd8d#file-server-py>
>
> With this in mind, here are the questions I have
>
>    - Is there a non-blocking way to check if any new requests came in, 
>    without having to create a seperate thread?
>    - Is there a way to attach an observer to the stream to process 
>    requests as they come in?
>    - Is there a way to get hold of a stream "object" that I can use to 
>    send responses back from a different thread? From what I have seen, 
> "yield" 
>    seems to be the only way to stream data back from server to client.
>
>
>
>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/1136b74e-3e0d-4bdc-a5da-5068bd5306e9n%40googlegroups.com.

Reply via email to