Hi all, Had a long conversation with Stefan on Discord about where the builder and UI could and should go. And we've got had good ideas. Wanted to bring it here for broader input before I go deeper. PR #687 ( https://github.com/apache/burr/pull/687 ) has my current work. What we're trying to solve:
Right now, building a Burr app means writing Python, running it, then switching to the tracking UI to see what happened. There's no way to go from a visual graph back to code, or to prototype a flow visually before writing the implementation. Stefan framed it as "code -> picture -> code", where the graph is the shared representation between the two. I think that's the right north star. build_graph() convention The simplest unlock is agreeing on a function signature: def build_graph() -> Graph: return ( GraphBuilder() .with_actions(...) .with_transitions(...) .build() ) The UI looks for this, calls it, gets the graph object. No regex, no guessing. Should this live in core as a recommended pattern, or stay as a UI convention? Pyodide/WASM: Stefan pointed out that tryhamilton.dev already runs Pyodide. If we do the same for Burr, the UI can execute build_graph() directly in the browser, stub out non-burr imports, and use inspect to get action metadata. This replaces the regex parser I built and makes the code-picture-code loop actually reliable. Main question: should the WASM runtime be loaded on demand or always bundled? Any concerns about scope here? What I'm committing to: I can own the builder and UI side. Concretely: - *This month:* Get PR #687 reviewed and merged. Builder with node types, Monaco editor, save/load. - *Next month:* Pyodide integration spike. Starter templates (chatbot, RAG, tool-calling agent). Serve/test functionality in the UI. - *Ongoing:* VS Code extension exploration, template hub. Stefan also brought up Hamilton-Burr integration and the broader Hamilton/Burr/Airflow stack vision. Happy to discuss that separately, keeping this thread focused on the builder. Would appreciate thoughts on direction, priorities, or concerns about scope. Andre Ahlert.
