Child Workflow Separate Service

Hi Recently we review the documentation of child workflow
but there seem no example on this one (from GitHub - temporalio/samples-go: Temporal Go SDK samples)
it’s stated that we should consider:
Consider each Child Workflow Execution as a separate service.
Workflows | Temporal Documentation

Does this mean we create two separate project, and communicate each other using an http rest?
so for the parent
we will have 1 project called parent and 1 project called child
then we will have 1 worker for parent and 1 worker for child

Parent:
w := worker.New(c,“Parent-TaskQueue”)
w.RegisterWorkflow(SampleParentWorkflow)
w.RegisterActivity(SampleActivityToCallChild)
Trigger create workflow with
c.ExecuteWorkflow(context.Background(), options, SampleParentWorkflow, resourceID)

seperate project
Child:
w := worker.New(c,“Child-TaskQueue”)
w.RegisterWorkflow(SampleChildWorkflow)
Trigger create workflow with
c.ExecuteWorkflow(context.Background(), options, SampleChildWorkflow, resourceID)

then when parent trigger child, we call via asynchronous http REST, and use signal channel to wait for the child completion flow,child need to signal the parent back

is this the right implementation or is there any suggestion/example how do we make this ?
Thank You

Temporal child workflows can have multiple usages, see more info here.

For the mentioned use case, yes you can have your child workflow hosted by a separate service, and have its own set of workers. Your child workflow (and its workers) and be written in a separate programming language as well for which Temporal has SDKs for. (see polyglot examples here and here).

You do not need to wrap the parent/child communication via some rest apis at all. If both services communicate with the same Temporal service you can use the out of box gRPC communication without issues. Parent workflow in service A and the child workflow in service B can run on different task queues.
They could even run on different namespaces, but at this time would not advice this as there are still couple of issues with cross-namespace invocations that need to be fixed on the server side before we can start recommending this use case.

So looking at child-workflow sample, In your parent workflow you could specify ChildWorkflowOptions->TaskQueue, for example:

cwo := workflow.ChildWorkflowOptions{
   WorkflowID: "MyChildWorkflowId",
   TaskQueue: "childWfTaskQueue",
   // ...
}

Your parent workflow can invoke the child on a different task queue via its workflow type (by default the name of the workflow function) so you do not have to your code between these services, in the child-workflow example:

err := workflow.ExecuteChildWorkflow(ctx, "SampleChildWorkflow", "World").Get(ctx, &result)

Overall you can think of activity and child workflow invocations as remote procedure calls, and task queue names being endpoints. Hope this helps.

1 Like