At least in the Java SDK, they both seem to be a locally executed function whose result becomes part of the event history. Is there any nuance to be aware of when choosing between one or the other?
There are not any major nuances to be aware of when deciding on which to choose. However, as listed here “A Side Effect does not re-execute upon replay, but instead returns the recorded result.” Also, in the document listed above it goes over what can go wrong when using a failed Side Effect.
Please review over this document going over the benefits of using Local Activities.
Let me know if this helps.
1 Like
Also, please consider this response when trying to use local activities vs activities.
SideEffect doesn’t support any error handling and non static dependencies. It is also executed inline in the workflow thread, so it should be very fast. So use it only for very simple operations like reading configuration or environment variables that are not ever expected to fail.
1 Like
hey Maxim, just wanna clarify on this point
It is also executed inline in the workflow thread,
so in the context of go-sdk, calling local activity might cause the coroutine to yield and context switch to another coroutine?
Calling ExecuteActivity will not cause the switch, but calling Get on the returned Future will.
1 Like
@maxim hi Maxim, does side effect and local activities also suits for non-io operation like pojo to pojo translation, de/serialization etc.? If so, then how it is operationally different from if we write the same as part of workflow itself, not as any “activity”?
You don’t need to use a local activity or a SideEffect for operations that don’t involve IO or other nondeterminism. Implement them directly as part of the workflow logic. The only exception would be operations that are very CPU intensive as they are reexecuted during workflow recovery (replay).