[HN Gopher] Show HN: Workflow orchestrator in Golang
       ___________________________________________________________________
        
       Show HN: Workflow orchestrator in Golang
        
       A brief overview: 1. Workflows steps share a running context, with
       access to data they need require. 2. Steps in the workflow
       (builders) are chained together based on a topologically sorted
       built from the predefined input & output. 3. No servers spin up
       (like Conductor/Cadence) - the orchestrator is low level and meant
       for simplifying business logic. 4. Before/After listeners for each
       step.  Would love to hear your thoughts and feedback!
        
       Author : harshadmanglani
       Score  : 34 points
       Date   : 2024-03-04 17:21 UTC (5 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | peter_l_downs wrote:
       | Looks like a great side project, congrats on launching. My basic
       | feedback is that you should set expectations on the project page
       | by answering the following questions:
       | 
       | - Why would someone use this instead of
       | Airflow/Cadence/Temporal/Databuilderframework?
       | 
       | - What does this look like when it's used? Most frameworks
       | provide some kind of example project, you should too.
       | 
       | - Related, but more specifically, what does the `IDataStore`
       | interface contract mean? Beyond the two functions that I have to
       | implement, are there any considerations related to the overall
       | performance/scalability/durability of the system? Would it make
       | sense to use a disk-backed store, or Redis, or Postgres?
       | 
       | - How do I observe the system? Which workflows are running, which
       | have failed, what the current state is, etc. Are there metrics?
       | Logs?
       | 
       | All of this is based on the assumption you want people to adopt
       | this framework. If it's just a cool side project, that's fine
       | too, but you should probably try to set that expectation in the
       | README.
        
       | scosman wrote:
       | Love this space. I've build a few versions of this in go, glad to
       | see some go native frameworks.
       | 
       | Would also love to see some examples.
       | 
       | Concerns I've had to deal with in the past (if these are solved,
       | examples would go a long way):
       | 
       | - max queue size between elements is important. Don't want the
       | database reader role to outrun the workers, but also never want
       | them desaturated
       | 
       | - some dynamic limits for local to a role (limit DB readers to
       | limit connection pool) and global (how much cpu and memory share
       | does a job need before starting)
        
       | mdaniel wrote:
       | It seems you overlooked adding a license so that people can know
       | under what circumstances they can use your project's code
        
         | withinboredom wrote:
         | If there isn't a license, you can't use it. I think it's pretty
         | clear.
        
       | ksajadi wrote:
       | This looks very cool for embedding workflows in a native Go
       | project. There is also Trackman
       | (https://github.com/cloud66-oss/trackman) which is mostly built
       | for workflow based commanline execution.
        
       ___________________________________________________________________
       (page generated 2024-03-04 23:00 UTC)