dapr
[Proposal] Remove usage of DaprClient APIs for wokflow
Describe the proposal
The DaprClient for workflow is outdated and is going to be abandoned. The DaprWorkflowClient class in Dapr.Workflow are recommended to use instead.
Here are the projects I found that are still using DaprClient to operate workflows:
-
workflowsappindapr/daprtests app (link) -
order-processorindapr/quickstartsworkflow csharp sample (link) -
WorkflowConspleAppindapr/dotnet-sdksample (link)
FYI @halspang and @RyanLettieri - this is something I asked @MregXN to help with.
For additional context, the workflow APIs exposed by DaprClient were originally intended to be general purpose and work with a variety of workflow implementations (temporal, etc.). However, we've since abandoned supporting multiple workflow engines and decided to instead only support the built-in engine. For that reason, the generic workflow API surface is no longer recommended for SDK users, and we instead recommend that all users use the more purpose-built DaprWorkflowClient APIs instead.
(Note that we won't be abandoning the underlying workflow management APIs that are built into the runtime. The workflow management APIs are still valuable to have those exposed over HTTP for languages that don't have Dapr SDK support).
Marked as P0 since I think we shouldn't declare workflows as stable with APIs that we don't intend to support.
@cgillum Does this differ in any meaningful way from #1344 ? I already have a PR for that one at #1345 and the PR for the docs has already been merged here.
@WhitWaldo good observation. I think the difference is that #1344 tracks removing the APIs whereas this item tracks removing all references to those APIs. Technically, this one could be completed first without removing the APIs themselves.
It looks like there's at least one place where we're still using the deprecated APIs in dapr/dapr test code.
It's probably worth doing a cursory peek through all the SDKs to see if any of the non-.NET variants are using the old methods as well.
