Can we improve the `callActivity()` and `callSubOrchestrator()` experiences in orchestrations?

[hossam-nasr]

(see relevant discussion: ejizba/func-nodejs-prototype#14 (comment))

Currently, if an orchestrator wants to call an activity function, it would have code like this:

context.df.callActivity('Hello', 'Cairo')

passing in the activity's name as a string. This provides no intellisense and no validation to confirm that the activity name is the same as the registered activity function.

Similarly, suborchestrations are started by specifying the orchestration's name as a string:

context.df.callSubOrchestrator("DeviceProvisioningOrchestration", deviceId, child_id)

This issue is to explore whether the new programming model can provide us an opportunity to improve this callActivity() and callSubOrchestrator() experience, and whether such an improvement would be worth the engineering cost.

An example of this would be to have the API to register activities (df.app.activity()) and orchestrations (df.app.orchestration()) return some kind of object that can be passed to the callActivity()/callSubOrchestration() functions, as such:

const helloActivity = df.app.activity(activityName, { handler: (input: string) => {
       return `Hello, ${input}`;
   }
});

const orchestrator: OrchestrationHandler = function* (context) {
    const outputs = [];
    outputs.push(yield context.df.callActivity(helloActivity, 'Tokyo'));
    outputs.push(yield context.df.callActivity(helloActivity, 'Seattle'));
    outputs.push(yield context.df.callActivity(helloActivity, 'Cairo'));

    return outputs;
};
df.app.orchestration('durableOrchestrator1', orchestrator);

[ejizba]

I'm wondering if it makes more sense to flip the order from this:

context.df.callActivity(helloActivity, 'Tokyo')

To something like this:

helloActivity.call(context, 'Tokyo')

[hossam-nasr]

@ejizba I would be in favor of that solution, and I don't immediately see a reason we couldn't do this

[davidmrdavid]

I think that's a really cool idea, @ejizba.

I would take it a step further and ask whether it would be possible to call it like this:

yield helloActivity.call('Tokyo') // let's not forget the `yield` is necessary.

Or taking it to the logical extreme and just do

yield helloActivity('Tokyo') // let's not forget the `yield` is necessary.

Overall, I think that hiding the context argument, which would be static for a given orchestrator, would be a neat win. Given that the SDK controls the orchestrator execution (and therefore it has a local copy of the context), I think it ought to be possible.

[hossam-nasr]

@davidmrdavid I really like your last proposal 😍 Makes writing orchestrations one step closer to feeling like writing just normal code. Once/if we also fix #5, this would basically look exactly the same as a normal async function

[jviau]

How would this affect code organization? If I want to access helloActivity in the above example in other files, how would I expose that? And would this also work for orchestrations? Would I be able to use:

const subOrchestrator = df.app.orchestration('subOrchestrator', /* impl */);

const orchestrator: OrchestrationHandler = function* (context) {
    const outputs = [];
    outputs.push(yield context.df.callOrchestration(subOrchestrator , 'Tokyo'));
    outputs.push(yield context.df.callOrchestration(subOrchestrator , 'Seattle'));
    outputs.push(yield context.df.callOrchestration(subOrchestrator , 'Cairo'));

    return outputs;
};
df.app.orchestration('durableOrchestrator1', orchestrator);

[davidmrdavid]

@jviau: let me try to answer your questions in parts.

(1)

If I want to access helloActivity in the above example in other files, how would I expose that?

I think a user would be able to export and import the helloActivity object just like they do in regular JavaScript.
I wanna say it would look like this, minus a few typos:

// fileA.js

const helloActivity = df.app.activity("MyActivityName", /* impl */ );
export helloActivity;

// fileB.js
import { helloActivity } from "fileB.js"; // or something like that

So I think the code organization bit is not the difficult part, we would just be re-using standard mechanisms in the language. I think the tricky bit to get right is not requiring an explicit reference to the context object when scheduling an Activity on a given orchestrator, but I think that's solvable.

(2)

And would this also work for orchestrations?

I think I need more context here. Can you please elaborate what you're asking?