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

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

seperate project
w := worker.New(c,“Child-TaskQueue”)
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

Is the cross-namespace child workflow invocation issue fixed yet? If yes please specify versions for same. We had a use case on this.


Hi @tihomir
Were you referring to this issue ParentClosePolicy not working cross-namespace · Issue #2043 · temporalio/temporal · GitHub
in cross namespace communication between parent and child workflows?
Is there any more issue that we should be aware of before implementing such architecture?

Cross-namespace child workflows are deprecated. We are working on providing an alternative through the Nexus project.

@maxim What is the recommended pattern for cross-namespace child workflows while we wait for Nexus to be available? Creating an Activity that uses a WorkflowClient to launch the Workflow?

Can you be more specific about what is broken with cross-namespace child Workflows? Is it still safe to use in some use-cases?

You can define Namespace in ChildWorkflowOptions (by default it will inherit it from parent exec).
If you must do this, for now would probably go with the “starting workflow from activity” approach tho (so not child worklfows)

@tihomir Thanks! I understood how to launch a cross-namespace child workflow, I just wasn’t clear on why it’s deprecated (and I’m still not :slight_smile:). I was hoping that if I understood what specifically the issue with them was, I would know if we could safely use them for our use-case. I’d prefer to avoid the “start workflow from activity” pattern, as it adds extra extra development/runtime overhead vs just launching the child workflow. But if the guidance is to never use cross-namespace child workflows under any circumstances, so be it.

if the guidance is to never use cross-namespace child workflow

We can’t tell you not to use it, but we can’t recommend using a feature that has been deprecated. So would not use it at all I think.