Managing Workflows code repositories

Community Support
1

How are people managing their worflow code on git? We have 2 related workflows along with an http server to trigger them (from an external system). Now we need to add an unrelated workflow (the deployment pace is going to be different). I’m confused if we should add the workflow to the same codebase (making our CI/CD pipeline more complex) or keep them in different git repos (but creating separate http server for it as well)

2 Likes
2

Temporal doesn’t put any restrictions on how you manage your code. Unrelated (or even related) workflows can absolutely live in separate repositories.

You don’t need to create new HTTP service for every new workflow. Just create one that starts workflow by its name and can be used to start any workflow.

3

Thanks for the reply.

Temporal doesn’t put any restrictions on how you manage your code. Unrelated (or even related) workflows can absolutely live in separate repositories.

I asked this because we were curious about the best practices around the boundaries of putting logic into the ‘same workflow/worker process’, or ‘different worker processes but the same binary’, or ‘different binaries altogether’.

You don’t need to create new HTTP service for every new workflow. Just create one that starts workflow by its name and can be used to start any workflow.

Does this apply to Cadence too? (we’re using Cadence because Temporal isn’t stable yet).

4

Workflows and activities are essentially functions that support long calls. You can pack them into a single unit of compilation and deployment similar to microservices. So all the standard concerns that apply to microservices apply to workflows and activities.

Yes, most of the application facing APIs didn’t change much from Temporal to Cadence. We rewrote a lot of internal machinery to get rid of multiple design and implementation issues.

In Go you can pass a name of workflow or activity instead of a function for all the related API calls.

	run, err := ts.client.ExecuteWorkflow(ctx, options, "workflowType", args...)

In Java use an untyped stub:

    WorkflowStub workflowStub =
        workflowClient.newUntypedWorkflowStub("workflowType", options);
    WorkflowExecution execution = workflowStub.start(taskQueue);
5

Thanks for this. We tried making an API server which just triggers a workflow with supplied parameters. However, we couldn’t find any way to provide validation of the input parameters in the workflow.

Should we make separate API handlers for doing custom parameter validation of different workflows before triggering the workflow? or there’s a way to tell cadence about custom validation of input params before starting a workow? so that the input validation exception could be given without running the workflow.

6

@maxim Any idea about this?

7

In our main micro service myservice we define workflows and activities. This provides all validation on the endpoints that trigger a workflow. We then have a myservice-worker (we deploy n number of these) which depends on myservice and registers workflows and activities and connects to temporal to carry out the task.

8

I filed an issue to add support for input arguments validation.

9

Thanks @maxim

@moh_abk we’re currently doing this. but this has decoupled the gateway with the workflow code.