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

[Feature Request] Divide Workflow stub objects and Workflow proxy objects #419

Open
roxblnfk opened this issue Apr 12, 2024 · 2 comments
Open
Assignees

Comments

@roxblnfk
Copy link
Collaborator

roxblnfk commented Apr 12, 2024

I have an idea

I suggest adjusting the Workflow Client interface: introduce a distinction between the concepts of Stub and Proxy.

Currently, as a result of calling the method WorkflowClient::newWorkflowStub($class) (or WorkflowClient::newRunningWorkflowStub($class)), we do not receive a Workflow Stub (WorkflowStubInterface), but a proxy object that redirects calls of Workflow methods related to the Workflow interface. That is, the user interacts with the proxy object as with an implementation of the user's Workflow interface.

At the same time, we have methods WorkflowClient::newUntypedWorkflowStub(), WorkflowClient::newUntypedRunningWorkflowStub(), which return the very WorkflowStubInterface (type-level guarantee). That is, they work as expected.

Note

WorkflowStubInterface is convenient when, for example, you need to call the Describe method or the Update method with your own WaitPolicy.

We face two problems:

  • methods with the Stub postfix work differently: two out of four return WorkflowStubInterface, the other two return a proxy.
  • there is no proper way to get WorkflowStubInterface from a Workflow class. Both methods that accept a class return us a proxy.

In this commit, you can see changes in the WorkflowClientInterface interface.
1847f72
In the methods that currently return a Proxy, I've considered backward compatibility through the $proxy parameter. This will all be cleaned up in the next major version.
Calls to create stubs with $proxy=true will throw deprecation notices.

We can also discuss replacing the naming of Stub with Handle. Then we'll just make all the *Stub methods deprecated :)

@wolfy-j
Copy link
Collaborator

wolfy-j commented Apr 16, 2024

@Sushisource, I propose to introduce new methods instead. Can we hop on a call to discuss it?

@roxblnfk
Copy link
Collaborator Author

roxblnfk commented Apr 16, 2024

New methods might be:

// Return WorkflowStubInterface
$wfClient->newWorkflow($class, ...);
$wfClient->newRunningWorkflow($class, ...);

// Return Proxy objects. There is `Proxy` suffix
$wfClient->newWorkflowProxy($class, ...);
$wfClient->newRunningWorkflowProxy($class, ...);

// Untyped (unknown class name). Return WorkflowStubInterface
$wfClient->newUntypedWorkflow($type, ...);
$wfClient->newUntypedRunningWorkflow($type, ...);

// DEPRECATED
$wfClient->newWorkflowStub($class, ...); // Proxy object
$wfClient->newRunningWorkflowStub($class, ...); // Proxy object
$wfClient->newUntypedWorkflowStub($type, ...); // WorkflowStubInterface
$wfClient->newUntypedRunningWorkflowStub($type, ...); // WorkflowStubInterface

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

No branches or pull requests

3 participants