[WORKFLOW SDK FEATURE REQUEST] Support pydantic models

[leechristensen]

Describe the WORKFLOW SDK feature

It would be convenient if workflows/activities could support Pydantic models as input, automatically handling the (de)serializaiton. Right now, they only support dictionaries or simple values. The motivation comes from wanting to use strongly typed objects vs dictionaries (which are more opaque in their types).

There is some precedent here with the FastAPI extension supporting them in subscriptions.

Release Note

RELEASE NOTE: Workflows and activities can now use Pydantic models as their input.

[acroca]

Thank you for opening the issue!

I checked the Go and Java SDKs and they both support custom user objects, using JSON. But both Go and Java have an 'easy' way to support this out of the box, so it doesn't add a lot of complexity.
I'm wondering if it'd be possible to support any sort of object that is serializable and deserializable using json, to add a more generic support to json->object instead of just pydantic. Any thoughts?

Also, we need to make sure the pydantic dependency is optional.

[leechristensen]

Swappable serializers I'm sure would be welcome! I think adding a serializer arg to the subscribe method would be a good option, or expose a way to set that globally all across all subscribers.

I'm wondering if it'd be possible to support any sort of object that is serializable and deserializable using json

Is it necessary to restrict to JSON? I personally use Pydantic JSON objects the most, but Protobufs/Grpc are a close 2nd. Dapr uses Protobufs underneath IIRC so I feel like it slots in well there.

Also, we need to make sure the pydantic dependency is optional.

My preference would be to use Python extras to install the functionality. That way users could do something like:

pip install 'dapr[pydantic-serializer]'

But that does deviate away from how some of the current sdk extensions are implemented (i.e. as other pypi packages)

[olitomlinson]

Big +1 for supporting Pydantic models and alternative serializers. Having consistency across the SDK is essential for good UX (and the precedent has already been set, so unless there is a good reason not to we should do this)