Re:Show HN: Workflow orchestrator in Golang
by harshadmanglani on Monday March 04, 2024 @10:47PM
(#39599199)
Thanks for the inputs! I'll add some examples in the documentation.
- with control on the database reader yourself, i think you should be able to find a way around saturation/desaturation?
- again, the fairly certain you can limit DB readers in the DataStore interface you pass to the orchestrator. I'll think about the cpu and memory share and if there's a way to expose that.
A major concern I've always had with workflow orchestrators is the versioning of workflows. Think about long running workflows (>2 days). If you change your workflow logic, what happens to the existing ones that haven't completed yet?
Everyone handles this differently, and I've been thinking about a generic way to do this. Thoughts?
- with control on the database reader yourself, i think you should be able to find a way around saturation/desaturation?
- again, the fairly certain you can limit DB readers in the DataStore interface you pass to the orchestrator. I'll think about the cpu and memory share and if there's a way to expose that.
A major concern I've always had with workflow orchestrators is the versioning of workflows. Think about long running workflows (>2 days). If you change your workflow logic, what happens to the existing ones that haven't completed yet?
Everyone handles this differently, and I've been thinking about a generic way to do this. Thoughts?