Azure / Azure/azure-functions-durable-js
Should we add convenience APIs to quickly register Activity functions?
- Dominant language
- TypeScript
- Stars
- 142
- Forks
- 66
- Avg merge
- 3d 19h
- Merged PRs (30d)
- 4
Description
Based on discussion [here](https://github.com/ejizba/func-nodejs-prototype/pull/14#discussion_r1014359135).
Current implementation of the SDK for v3 includes two supported ways to register orchestrations and entity functions:
passing the handler directly:
```TS
const orchestrator: OrchestrationHandler = function* (context) {
const outputs = [];
outputs.push(yield context.df.callActivity(activityName, 'Tokyo'));
outputs.push(yield context.df.callActivity(activityName, 'Seattle'));
outputs.push(yield context.df.callActivity(activityName, 'Cairo'));
return outputs;
};
df.app.orchestration('durableOrchestrator1', orchestrator);
```
or passing in an options object:
```TS
df.app.orchestration('durableOrchestrator1', { handler: orchestrator });
```
However, this overload isn't done for registering activities. Currently the only way to register activities is by passing in an options object:
```TS
const helloActivity: ActivityHandler = (input: string) => {
return `Hello, ${input}`;
};
df.app.activity('Hello', { handler: helloActivity });
```
This issue is to discuss whether or not we should also add a convenience overload that allows passing in the handler directly to register an activity, as below:
```TS
df.app.activity('Hello', helloActivity);
```
The argument against having this overload is that activity functions, unlike orchestrations or entity functions, _can_ accept extra input and output bindings, so there are already other valid parameters that can be passed in the options object than `handler` (namely `extraInputs` and `extraOutputs`). However, it's possible that this is not a very common use-case, and the convenience of having this overload for the cases in which no extra bindings are necessary still justifies adding it.
Contributor guide
Research direction
Start at the df.app.activity registration entry point and read the linked pull request discussion for the rationale behind the current options-object API. Compare direct-handler registration with extraInputs and extraOutputs, then document or implement the decided behavior and verify that the supported activity registration forms are consistent.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100