[Feature Request] Async GRPC Subscriber (dapr-ext-grpc)

[siudeks]

How to import classes defined here?

The question is about grpc generated stuff like ListTopicSubscriptionsResponse, TopicSubscription, TopicEventRequest, TopicEventResponse etc. They are required to use DAPR in intellisense-friendly way, as the classes are part of DAPR appcallback interface.

They do not exist in DAPR-related pypi modules, what makes impossible to create type-safe code based on DAPR grpc callback services

[siudeks]

May you convert the issue to a bug reporting please? Mentioned types are part of DAPR java sdk, and they do not exist in Python sdk

[berndverst]

@siudeks this is generated code - generated from protos. Not all generated proto functionality is used in the Python SDK, and that is expected behavior. Please focus on the features you are looking for.

The source is here: https://github.com/dapr/dapr/blob/master/dapr/README.md

You can compile those protos to Python using the instructions here: https://github.com/dapr/python-sdk/tree/main/tools

That being said, just because something exists in the Dapr Runtime proto does not mean we are going to use it or implement it in the Python SDK.

This is working as intended.

[berndverst]

If it makes things clearer, I will move the proto package to _internal/proto or something like that.

[berndverst]

For some more background - the Dapr GRPC client is the only official way in Python to interact with GRPC. Using the protos directly is not supported by the Python SDK maintainers.

https://github.com/dapr/python-sdk/tree/main/dapr/clients/grpc

If you take a look there you will see that this imports and uses a subset of the generated functions from the private/internal proto package.

The dapr-ext-grpc extension (code here: https://github.com/dapr/python-sdk/tree/main/ext/dapr-ext-grpc/dapr/ext/grpc) also uses some of those protos.

[siudeks]

@berndverst if it is intended limitation -> I understand

In my scenarios I consume events via gRpc connection with DAPR sidecar, so initially @app was the very good starter. Actually, @app does not support atm async methods, what I exactly wanted to achieve

If there is a way to subscribe events using grpc connection with DAPR, where my listeners are async - in such case I will not require app callback generated classes

[berndverst]

@siudeks it should be pretty easy to make an async version of dapr-ext-grpc. Ultimately that package is fairly simple, and indeed you could just create a grpc client from grpc.aio instead of grpc and use the protos we generated (just basically copy whatever we do for the sync version but make it async).

Let me change this issue into a feature request for an async grpc pubsub / events subscriber

[berndverst]

Some notes on desired implementation details:

Just like we have dapr.ext.grpc which export App and Rule, we should have dapr.ext.grpc.aio which export the same. The only usage difference should be this single import.

The grpc connection needs to be established using grpc.aio instead of grpc.

And the internal topic / event handler registration needs to be changed to an awaitable type. Change functions to be awaitable, and await any results.