3 ms·
Yeah, this definitely requires splitting state-impactful activity into its own function. That's good practice anyways, though I understand it might be a pain in
by KraftyOne 2y ago
Yeah, this definitely requires splitting state-impactful activity into its own function. That's good practice anyways, though I understand it might be a pain in large codebases. Regional tags are definitely an interesting alternative!
For the UI example, I don't think you'd use durable execution for most of the UI--it's just not needed. But maybe there's one button that launches a complex asynchronous background task, and you'd use durable execution for that (with careful workflow ID management to ensure idempotency and allow you to retrieve the status of the background task).
- ethbr1 2y ago> splitting state-impactful activity into its own function. Each separate state-impactful activity into its own function, no? > For the UI example... I wasn't talking about building a GUI in a python program: I was talking about using python to automate an external GUI app. Because that toy example (which also happens to be done in the real world!) encapsulates a lot of the state issues that don't seem well-handled by the current design. Namely, that external interactions are a mix between stateless and stateful operations.