Open bergundy opened 3 years ago
Discussion notes:
Are people asking for side effect or are we just trying to reach parity? Even if mutable side effect is technically useful, is that enough of a justification for its inclusion? If we do want this, should link core issue when created.
Side-effect will probably not be implemented in newer SDKs, we should consider implementing mutable side effects. Not planned for now since nobody has asked for it.
I'm new to Temporal so I'm still learning the concepts, but my initial thinking is the side effect API could be useful for writing safer workflows.
E.g, say I have a long working workflow that calls someFunctionThatIsDeterministic
, and calls child activities based on the result of this function, it would be useful to just wrap it in some kind of wf.sideEffect(() => someFunctionThatIsDeterministic())
where I know for certain that the result is cached and it won't be re-executed, similar to React.useMemo
in ReactJS land. This would guard against if I accidentally make changes to someFunctionThatIsDeterministic
while some workflows are running.
I think at the moment the best way to do this is to just pass in these sorts of values as arguments to a workflow, or to use activities, but surely a side effect API would be less friction for these sorts of use cases which ultimately encourages writing safer workflows?
say I have a long working workflow that calls
someFunctionThatIsDeterministic
Side effects are for non-deterministic actions. If it's deterministic, just execute in workflow.
I think at the moment the best way to do this [...] to use activities,
:+1: Local activities to be more precise. You need to leave the workflow sandbox to execute these anyways, so that friction already exists. Side effect does not provide much value over local activities.
If you want to discuss options in detail, feel free to join us at https://temporal.io/community (Slack or forum).
Requires sdk-core support