Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Remove usage of DaprClient APIs for wokflow #1205

Closed
MregXN opened this issue Dec 8, 2023 · 8 comments
Closed

[Proposal] Remove usage of DaprClient APIs for wokflow #1205

MregXN opened this issue Dec 8, 2023 · 8 comments
Labels

Comments

@MregXN
Copy link
Member

MregXN commented Dec 8, 2023

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:

  • workflowsapp in dapr/dapr tests app (link)
  • order-processor in dapr/quickstarts workflow csharp sample (link)
  • WorkflowConspleApp in dapr/dotnet-sdk sample (link)
@cgillum
Copy link
Contributor

cgillum commented Dec 12, 2023

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).

@MregXN
Copy link
Member Author

MregXN commented Dec 13, 2023

/assign

@cgillum
Copy link
Contributor

cgillum commented Sep 10, 2024

Marked as P0 since I think we shouldn't declare workflows as stable with APIs that we don't intend to support.

@WhitWaldo
Copy link
Contributor

@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.

@cgillum
Copy link
Contributor

cgillum commented Sep 13, 2024

@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.

@WhitWaldo
Copy link
Contributor

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.

@mikeee
Copy link
Member

mikeee commented Sep 30, 2024

Duplicate/new issue - #1344

@WhitWaldo
Copy link
Contributor

Closed as part of #1362

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants