Azure / Azure/azure-functions-durable-js

Should we add convenience APIs to quickly register Activity functions?

Open
#417 0 comments 0 reactions 0 assignees View on GitHub
Enhancement post-GA programming model 🚀 v3
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.