Open guybartal opened 1 week ago
@guybartal PRs welcome. The workflow SDK is not considered stable (yet) - and the main contributors to the workflow sub-SDK are not currently actively working on the SDK.
I'm the main overall Python SDK maintainer, but I'm not the right person to provide these examples for the Workflow SDK.
Would love contributions here from the community.
Thanks for the update, what about the underlying workflow http/grpc endpoints, are those considered stable?
Thanks for the update, what about the underlying workflow http/grpc endpoints, are those considered stable?
Those are currently beta and will become stable in the upcoming 1.15 version.
What content needs to be created or modified?
In the new SDK version, a set of decorators were introduced which simplifies the way you register activities and workflows.
Describe the solution you'd like
an updated documentation will all parameters per class and its methods, plus example which uses the new decorators, and also, all the possible methods of
DaprWorkflowContext
, not onlycall_activity
but alsocreate_timer
,call_child_workflow
,wait_for_external_event
,continue_as_new
,when_all
,when_any
the same goes for
DaprWorkflowClient
, not onlyschedule_new_workflow
but also forraise_workflow_event
,terminate_workflow
,pause_workflow
,resume_workflow
.Important note
I would also write some recommendations regarding scalability, when using workflows does it means that all activities should be in the same pod? do we call it synchronously or asynchronously? how each activity scale independently from other activities? should they be called via service invocation or pub/sub event to accomplish that or its built-in inside the workflow mechanism?
Where should the new material be placed?
here
The associated pull request from dapr/dapr, dapr/components-contrib, or other Dapr code repos
not yet
Additional context
@yaron2 's session