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

Remove final from WorkflowInterface #487

Merged
merged 1 commit into from
Aug 16, 2024
Merged

Conversation

Nyholm
Copy link
Contributor

@Nyholm Nyholm commented Aug 15, 2024

What was changed

I made the WorkflowInterface attribute not final

Why?

I am extending this attribute to allow myself to add more properties. The additional properties will help me with building the container and workers.

Example:

use Temporal\Workflow\WorkflowInterface;

class MyWorkflowInterface extends WorkflowInterface
{
    public function __construct(
        public string $workerName, 
    ){}
}

Now I can create a bunch of worker configuration and map it with my workflows and let my applications service container build the workers for me.

This is similar to ActivityInterface attribute.

Checklist

  1. How was this tested:

I did not test at all.

  1. Any docs updates needed?

Nope

Copy link

vercel bot commented Aug 15, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
php ✅ Ready (Inspect) Visit Preview 💬 Add feedback Aug 15, 2024 4:36am

@CLAassistant
Copy link

CLAassistant commented Aug 15, 2024

CLA assistant check
All committers have signed the CLA.

@roxblnfk
Copy link
Collaborator

Hello 👋
Have you considered creating a separate attribute like other integrations do?
For example, in integration with Spiral, this attribute is used to specify the TaskQueue name when registering workers.

@roxblnfk roxblnfk added this to the 2.11.0 milestone Aug 15, 2024
@roxblnfk roxblnfk added Feature New feature or request enhancement and removed Feature New feature or request labels Aug 15, 2024
@roxblnfk roxblnfk requested a review from wolfy-j August 15, 2024 08:32
@Nyholm
Copy link
Contributor Author

Nyholm commented Aug 15, 2024

Hello :)

Yes. That is what I do currently. But that forces my user to have two attributes.

But that is not the end of the world. They have one attribute on the workflow interface and one on the workflow implementation.

@butschster
Copy link

Hello :)

Yes. That is what I do currently. But that forces my user to have two attributes.

But that is not the end of the world. They have one attribute on the workflow interface and one on the workflow implementation.

When working with Temporal workflows that need to be shared across different services, we can use interfaces in a shared package. This approach allows services that use this package to invoke the workflow. Here's how it's implemented:

  1. Interface in a shared package:
// Shared package
<?php
declare(strict_types=1);
namespace Internal\Shared\Temporal\Workflow\Subtitle;
use GRPC\Services\Subtitles\v1\Request\GenerateSubtitleRequest;
use GRPC\Services\Subtitles\v1\Subtitle;
use Internal\Shared\Temporal\TaskQueue;
use Spiral\TemporalBridge\Attribute\AssignWorker;
use Temporal\Support\VirtualPromise;
use Temporal\Workflow\WorkflowInterface;
use Temporal\Workflow\WorkflowMethod;

#[AssignWorker(TaskQueue::SUBTITLE_GENERATOR)]
#[WorkflowInterface]
interface GenerateSubtitleWorkflow
{
    /**
     * @return VirtualPromise<Subtitle>
     */
    #[WorkflowMethod]
    public function generate(GenerateSubtitleRequest $request);
}
  1. Implementation in a service that handles the workflow:
<?php
declare(strict_types=1);
namespace App\Endpoint\Temporal;
use App\Endpoint\Temporal\Subtitle\SubtitleServiceStub;
use GRPC\Services\Subtitles\v1\Request\CreateRequest;
use GRPC\Services\Subtitles\v1\Request\GenerateSubtitleRequest;
use GRPC\Services\Subtitles\v1\Request\SubtitleProcessed;
use GRPC\Services\Subtitles\v1\Request\TranscribeRequest;
use GRPC\Services\Subtitles\v1\SubtitleRecord;
use Internal\Shared\Temporal\Workflow\Audio\TranscribeAudioWorkflowStub;
use Internal\Shared\Temporal\Workflow\Subtitle\GenerateSubtitleWorkflow;
use Temporal\Internal\Workflow\ActivityProxy;

final class ProcessAudioWorkflow implements GenerateSubtitleWorkflow
{
    private ActivityProxy|Subtitle\SubtitleActivity $subtitles;

    public function __construct()
    {
        $this->subtitles = SubtitleServiceStub::create();
    }

    public function generate(GenerateSubtitleRequest $request)
    {
        // 1. Check if audio is mp3
        // 2. Check if subtitles exist for given audio hash
        // - If so, return UUID
        // 3. Create subtitle record with status pending
        // 4. Start transcribe
        // Set UUID to subtitle
        // - persist to database
        return $subtitle;
    }
}

This setup uses the Spiral framework to handle Temporal. When the service starts, the framework looks for all classes or interfaces that have the WorkflowInterface attribute. If the attribute is on an interface and it has an implementation inside the service, it registers it in the Temporal server.

@butschster
Copy link

Oh) Your idea more about workers. I think, it;s better to use separate attribute, like AssignWorker in my example.In this case you don't need to extend final attributes)

@roxblnfk roxblnfk merged commit c4b79a0 into temporalio:master Aug 16, 2024
48 checks passed
@roxblnfk
Copy link
Collaborator

Will be available with 2.11.0.

@Nyholm
Copy link
Contributor Author

Nyholm commented Aug 16, 2024

Thank you for merging

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

Successfully merging this pull request may close these issues.

5 participants