Design choice - Separation of Workflow invocation and Worker code

Community Support
1

image
image996×838 84.5 KB

Choice 1
App1 receives the request, calls the controller in App2 and inside the controller, the workflow is started.
The worker (workflow, activity code) also resides in App2

Pros

  • Everything about temporal is in App2 application only.

Cons

  • Adds an additional layer of complexity (Rest Controller/gRPC Service)

Choice 2
App1 recieves the request and starts the workflow. App2 will contain the worker (workflows, activity code )
Pros

  • More resilient than Choice 1 (say App2 is down, App1 can still start the workflow. And once App2 is back, workers can continue the workflow execution)

  • Simplifies the design and removes complexity (Rest Controller/gRPC Service)

Cons

  • Some part of temporal code is shared between App1 and App2

Question

  1. Are there any more pros and cons you can identiy from temporal perspective?
  2. Which choice do you recommend?
2

Imho agree with you that “choice 2” will provide you with a higher level of resiliency, as well as ability to use the Temporal SDK client api directly, rather than having to set up custom rest/grpc apis between the two apps.

Regarding

Some part of temporal code is shared between App1 and App2

For “choice 2” you would need the temporal dependencies in both apps, for app1 you would need the client api (see for example here for different ways of starting workflow exec using the client api - https://github.com/tsurdilo/temporal-java-workshop/blob/main/src/main/java/io/workshop/s1/GreetingStarter.java)
As far as sharing dependencies for your own code, you don’t really need it as can use untyped workflow stubs. If you wanted to have a typed stub approach in App 1, you could only share your workflow interfaces between the apps and use the workflow interface in App 1 for the typed approach. Note that that works across multiple languages that Temporal has SDKs for as well.