The docs recommend side-by-side deployments to handle workflow versioning and avoid backend migrations. I'm implementing side-by-side deployments and have a few questions about go-workflows' behavior to validate my approach:
Single Diag UI for multiple queues?
We use the diagnostic web UI. Can a single web UI visualize multiple queues? Or do we need to host a seperate web UI for each queue in our backend?
How is the _system_ queue used?
The docs say that all workers will pull tasks from the _system_ queue. But what is it actually used for? What workflows and actions are placed on the _system_ queue? Does go-workflows place work onto that queue, or is it merely a convention for go-workflows consumers to use as they see fit?
Rollback migrations?
The docs are clear that go-workflows has limited support for migrations. I plan to disable them entirely so that my team never has to worry about the risk of: executing a migration, then having to roll back our code due to a bug. This would leave us with a migrated backend that our previous version is incompatible with, is unable to talk to. We will use side-by-side deploys with separate backend instances.
For completeness: Does go-workflows implement migration rollbacks? I don't need them, so I simply hope to confirm if you do/don't support them or have plans to support them. My team may ask me about this.
The docs recommend side-by-side deployments to handle workflow versioning and avoid backend migrations. I'm implementing side-by-side deployments and have a few questions about go-workflows' behavior to validate my approach:
Single Diag UI for multiple queues?
We use the diagnostic web UI. Can a single web UI visualize multiple queues? Or do we need to host a seperate web UI for each queue in our backend?
How is the
_system_queue used?The docs say that all workers will pull tasks from the
_system_queue. But what is it actually used for? What workflows and actions are placed on the_system_queue? Does go-workflows place work onto that queue, or is it merely a convention for go-workflows consumers to use as they see fit?Rollback migrations?
The docs are clear that go-workflows has limited support for migrations. I plan to disable them entirely so that my team never has to worry about the risk of: executing a migration, then having to roll back our code due to a bug. This would leave us with a migrated backend that our previous version is incompatible with, is unable to talk to. We will use side-by-side deploys with separate backend instances.
For completeness: Does go-workflows implement migration rollbacks? I don't need them, so I simply hope to confirm if you do/don't support them or have plans to support them. My team may ask me about this.