flogo
flogo copied to clipboard
Flogo State Service
Current behavior: The Flogo State service was designed to persist the current state of execution of a given flow. This includes the current task, the input/output of each task, etc.
Expected behavior: The state service needs to be reevaluated and enhanced to support a larger set of use cases.
- [ ] Revisit the API and transport for state service communication (use gRPC?)
- [ ] Distributed state for n number of running engines
What is the motivation / use case for changing the behavior? Enable apps to run across a variety of devices & cloud services, such as serverless platforms, where the process is executed in a stateless manner, but some form of state may still be required. For example, consider a service running till completion, terminating and another function spawns and continues execution where the previous function left off.
Additional information you deem important (e.g. I need this tomorrow):