RFC: Support dynamic workflow types

[lejenome]

This is a proposal to allow the implementation of Workflow Types dynamically. It's done by exporting a default function with the the following signature:

// @file src/workflows.js
import { proxyActivities } from '@temporalio/workflow';

/**
 * @param {string} workflowTypeName
 * @returns {(...args: any[]) => Promise<any>} The Workflow Type function
 */
export default function dynamicWorkflow(workflowTypeName) {
  if (workflowTypeName === "greeting") {
    // Workflow Type: greeting
    return async (name) => {
      const { greet } = proxyActivities();
      return await greet(name)
    }
  }
  else if (workflowTypeName === "multi") {
    // Workflow Type: multi
    return async (num1, num2) => {
      const { multi } = proxyActivities();
      return await multi(num1, num2)
    }
  }
}

And from the client.js

  const handle = await client.start("greeting", {
    args: ['World'],
    taskQueue: 'hello-world',
  });
  console.log(await handle.result()); // Hello World!

  const handle2 = await client.start("multi", {
    args: [2, 4],
    taskQueue: 'hello-world',
  });
  console.log(await handle2.result()); // 8

What was changed

• initRuntime will fallback to default export (if it's a function) to get Workflow Type dynamicly

Why?

Allow the creation of Workflow Type to be dynamic, use cases:

• Generate Workflow Types from a DSL definition
• Allow lazy load of Workflow Types definitions from an external source or from a DSL definition

Checklist

1. Closes

2. How was this tested:

• Tested on external project, sample project can be added after initial feedbacks

3. Any docs updates needed?

• Documentation of Workflow Type definition on TypeScript will need some updates

[CLAassistant]

All committers have signed the CLA.

[bergundy]

Thanks!
This matches some internal conversations we’ve had in the team.
We definitely want to support this.
The only thing I’m slightly concerned about is backwards compatibility, there is a chance that user have workflows named default and this change would break them.
Before we merge this we’d need to add tests and make sure to reflect this in the worker options docs and the Temporal docs site.
We can help with all of that.

[bergundy]

@mjameswh want to weigh in on this too?

[mjameswh]

This is indeed a feature we want to support. Thank you for your proposal!

I still have uncertainties on the best way to implement this, so I will take a few days to ponder about your proposition a little more. There are other issues that also relates to the structure of that object, and I want to make sure the implementation we put forward for this correctly fit our requirements around this.

[mjameswh]

@lejenome You mention this potential use case:

"Allow lazy load of Workflow Types definitions from an external source or from a DSL definition"

Can you explain a little bit more?

I don't think the default function, as it has been proposed at this point, can help with that. The default function will be executed inside the workflow sandbox, so it can't make calls to a database or load more files from the filesystem... Nor can the default function use activities to perform such access, since the internal state of the workflow has not yet been properly setup at that point in time...

[mjameswh]

Closing in favor of #1038.