This repo provides sample applications and Docker Compose config to easily get started with Temporal durable workflows in PHP with and Symfony and Laravel.
There are 4 applications in the symfony and laravel subdirs.
- An API to interact (start, query, signal) with the workflows:
workflow-api. - A first worker to execute Temporal workflow functions:
workflow-worker. - A second worker to execute Temporal activity functions:
activity-worker. - A
workflow-appapplication which runs the API and a worker which executes both the workflow and activity functions in a single container.
The workers are powered by the RoadRunner application server. The workflow workers and activity workers are configured to listen on two separate queues on the Temporal server.
The Symfony and Laravel workflow-api applicatiions can be started either with Nginx Unit, FrankenPHP, Nginx+PHP-FPM or RoadRunner (there is a container for each of these PHP app servers).
The workflow examples are taken from the Temporal PHP SDK sampes, and modified to adapt to the Symfony applications.
The Symfony and Laravel applications automatically register Temporal workflows and activities.
In the Symfony applications, this is implemented using compiler passes, located in the src/Temporal/Compiler dir in each project.
The workflow and activity classes are located in dedicated directories (src/Workflow), and tagged resp. with 'temporal.service.workflow' and 'temporal.service.activity'.
The feature is described in more details in the wiki. Follow the links below.
In the Laravel applications, the registrations are implemented with service providers.
The workflow and activity directories and namespaces are listed in a dedicated config file (config/temporal.php).
The service providers list all the classes in those directories, and register them either as Temporal workflows or activities.
By default, when using the Temporal PHP SDK, the activity and child workflow classes are instantiated in the workflow classes, therefore their options are also defined in the workflow classes. Similarily, the workflow options are defined in the workflow client code, using a stub.
A different approach is implemented in these Laravel and Symfony applications. The options are defined in the service container, each associated with a unique key. They can then be applied on workflows, child workflows and activities using a custom PHP attribute which receives the unique key as parameter.
The option attribute must be applied on the workflow, child workflow or activity interfaces in the applications making the remote calls. A facade is then defined for each of those interfaces. Note that there are separate facades packages for Laravel and Symfony.
The Symfony compiler passes and the Laravel service providers also use the facades to identify the workflow, child workflow and activity interfaces that are used for remote calls, and thus need to be configured with their respective options.
Note: while the child workflow and activity facades inherit from the base facade class, the workflow facade inherits from a custom facade class which provides additional functions to start a new workflow or get a running workflow.
- The Symfony applications
- How the Symfony integration works
- Adding a new function
- How it is implemented
Temporal PHP SDK samples