gRFC L13: Python Client and Server Interceptors

[Mehrdad Afshari]

I've submitted a gRFC for supporting client and server interceptors in Python:

https://github.com/grpc/proposal/pull/39

Implementation: https://github.com/grpc/grpc/pull/12778

Feedback is appreciated. Per the gRFC process, please keep discussion in this thread.

[dd...@netflix.com]

Glad to see a Python interceptor proposal!

It seems to follow the pattern used in grpc-go, with APIs for RPC types (unary_unary, unary_stream, etc) rather than APIs for phases of the request/response (sendMessage, close, etc) like grpc-java. Can you describe the overall strategy for interceptor APIs in the supported languages?

I'm also curious about the names of the 4 RPC types. I'm familiar with these names from the Node implementation:

Unary

ClientStreaming

ServerStreaming

Bidirectional

And from searching the grpc/grpc codebase I see those names in other implementations. Is there an interest in standardizing the names of RPC types across languages?

[Mehrdad Afshari]

Re the pattern, the basic idea adopted here, as in Go and C#, is to be able to add hooks to intercept all invocations before reaching the RPC core. To intercept "events", the interceptor would optionally decorate the return value from itself, to be able to inject code during the control-flow. I am considering adding a canonical interceptor that intercepts all RPC types and directly exposes higher-level hooks for such events, though I am not sure it should be part of the core PR, as it will effectively be an application of this interceptor API.

With respect to the naming, I followed the RPC handler object types in the language. In python, they are UnaryUnary, UnaryStream, StreamUnary, and StreamStream.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/546d9ea4-239a-4c6c-bb03-81ccd55cf32c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Amit Saha]

Could we add the order of execution of the interceptors to the proposal? (Not sure if that makes sense for this document). As per the proposed implementation, there's a comment saying that the interceptors are given control in the order they are listed when calling `intercept_server()`. However, when i tried to verify this behavior via:

diff --git a/demo2/grpc-services/grpc_interceptors/_interceptor.py b/demo2/grpc-services/grpc_interceptors/_interceptor.py

index c63b065..bb33b0b 100644

--- a/demo2/grpc-services/grpc_interceptors/_interceptor.py

+++ b/demo2/grpc-services/grpc_interceptors/_interceptor.py

@@ -228,6 +228,7 @@ class _InterceptingRpcMethodHandler(grpc.RpcMethodHandler):

             return self._rpc_method_handler.unary_unary

         def adaptation(request, servicer_context):

+            print(self._interceptor)

When I make a `unary_unary` call, this prints the _interceptor object in the reverse order they were specified when registering them with the server.

[Mehrdad Afshari]

I will clarify the order in the proposal, but the intended behavior is in order they are specified, so if you are observing otherwise, that might be a bug in the PR. Will check.