DAG Workflow Engine

(github.com)

18 points by blobmty4 hours ago

5 comments

  • tibbar55 minutes ago
    I was expecting to see some verbose LLM output, but actually the code has a distinctly hand-crafted feel. Nice to see! I'm not sure if "production ready" is a safe claim 7 commits in to a project ;)
    • afshinmeh53 minutes ago
      <a href="https:&#x2F;&#x2F;github.com&#x2F;vivekg13186&#x2F;Daisy-DAG&#x2F;blob&#x2F;main&#x2F;backend&#x2F;src&#x2F;api&#x2F;ai.js#L142" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;vivekg13186&#x2F;Daisy-DAG&#x2F;blob&#x2F;main&#x2F;backend&#x2F;s...</a>
  • _ZeD_17 minutes ago
    how it compares to airflow?
    • colton_padden3 minutes ago
      Was going to ask the same thing. The orchestration space already has some very well established frameworks like Airflow and Dagster. Would be curious to see the pros and cons.
  • taybin59 minutes ago
    What makes it production ready? What&#x27;s the code coverage on your tests? There are only seven commits in this repo as of this comment.
  • blobmty4 hours ago
    DAG Workflow Engine A production-ready DAG (Directed Acyclic Graph) workflow engine driven by a YAML DSL. Validates, executes, and visualizes workflows with support for parallel execution, retries, conditional branching, batch iteration, and pluggable actions.
  • esafak1 hour ago
    I don&#x27;t see any references to existing orchestrators, which are way more complete, so I presume you did this as an exercise?<p>Just seeing YAML used for workflows in this age makes me automatically nope out.
    • afshinmeh47 minutes ago
      Curious, what format would you prefer to use to represent a workflow instead of YAML?
      • esafak31 minutes ago
        Type-safe code. Workflows are not configuration! If I wanted YAML hell I could stick to Github Actions.<p>But that&#x27;s only the start. There are a lot of other things I would expect of a new workflow orchestrator in 2026 so if you are not comparing yourself to the competition you probably don&#x27;t know what you&#x27;re getting yourself into.
        • afshinmeh21 minutes ago
          Yeah, that makes sense. I looked at a few workflow orchestrators and I&#x27;m building something that I will release soon, but my thinking is that the &quot;workflow engine&quot; should be an abstraction that takes the input and executes the steps. &quot;What&quot; you use to define that workflow is probably the SDK layer though, but I can certainly see the value in using type safe code to define as opposed to a YAML file.<p>I&#x27;m mainly focusing on the portability aspect of it (e.g. use TS&#x2F;Python&#x2F;etc. to define the workflow&#x2F;steps or just simple a simple YAML file).
          • verdverm5 minutes ago
            Are you planning to map those varied definitions onto varied orchestrators?
          • esafak15 minutes ago
            [dead]