Why We Chose a Visual Pipeline Builder Over a Notebook-First Approach
The tradeoffs between flexibility and reproducibility in bioinformatics tools
When we started building Workbench, our bioinformatics workflow platform, we had a fundamental design choice: should the primary interface be a computational notebook (like Jupyter) or a visual pipeline builder (like Node-RED or Apache NiFi)?
We went with the visual builder. Here’s why, and what we’d change in hindsight.
The case for notebooks
Notebooks are dominant in bioinformatics for good reasons:
Flexibility: You can do anything — any analysis, any visualization, any hack
Narrative: Code + text + figures in one document tells a story
Familiarity: Most researchers learned computation through notebooks
Low barrier: Write code, see results. No abstractions to learn
If notebooks are so good, why build something else?
The problems we saw
After working with dozens of research teams, we noticed patterns:
Reproducibility is optional. A notebook runs on the author’s machine with the author’s environment. Share it with a colleague and it breaks. Different Python version, different package versions, missing data file.
Reuse is copy-paste. Want to run the same analysis on a new dataset? Copy the notebook, change the file path, hope nothing else needs changing. This works until it doesn’t.
Pipelines are implicit. A notebook’s execution order is determined by the cell order, which may or may not match the logical dependency order. Anyone who’s run cells out of order knows this pain.
Error handling is manual. A cell fails → you fix it → rerun → the next cell fails → repeat. There’s no retry logic, no partial rerun, no recovery from the last successful step.
Scheduling doesn’t exist. “Run this analysis every Monday on the latest data” is not something a notebook does. You need additional infrastructure (cron + papermill + monitoring).
What the visual builder gives us
In Workbench, a pipeline looks like a flowchart. Each node is an analysis step with typed inputs and outputs. You drag nodes onto a canvas, connect them, configure parameters, and run.
Under the hood:
Each node runs in a Docker container (reproducible environment)
Data flows between nodes through a managed storage layer (MongoDB GridFS + S3)
The pipeline runs on Apache Airflow (scheduling, retries, monitoring, partial reruns)
Pipeline definitions are serializable (shareable, version-controllable)
Node connections are type-checked at design time (you can’t connect a FASTA output to a node expecting a DataFrame)
The result: a pipeline built in Workbench is reproducible by default. Share the pipeline definition, and it runs identically on any Workbench instance. No “works on my machine.”
What we lost
Visual builders have real limitations:
Flexibility ceiling: Our 50+ pre-built nodes cover common analyses, but what about the uncommon ones? If a node doesn’t exist for your analysis, you’re stuck.
Complex DAGs are hard to visualize: A pipeline with 3-4 steps is clear. A pipeline with 20 steps and branching is a mess.
Exploration vs. execution: Notebooks are great for exploratory analysis — try something, look at results, adjust, repeat. A visual builder is designed for defined workflows, not discovery.
The abstraction tax: Researchers now need to understand our node system instead of just writing code. That’s a real learning cost.
The escape hatch: embedded Jupyter
Our solution to the flexibility problem is an embedded JupyterHub. When the visual builder isn’t enough:
Drop into a notebook with all pipeline data pre-loaded
Write custom analysis code with full access to the Python/R ecosystem
Results from the notebook can feed back into the visual pipeline
This gives us the best of both worlds, in theory. In practice, the transition between visual and notebook modes is still clunky. It’s our biggest UX challenge.
What we’d do differently
Start with fewer nodes, better ones. We built 50+ nodes. Researchers use about 15 regularly. We should have polished 15 nodes and added the rest on demand.
Design for exploration first. We designed for reproducible execution. But most researchers spend 80% of their time in exploration mode. We should have optimized for that flow and made the “lock it down for reproducibility” step come later.
Better notebook integration from day one. The embedded Jupyter feels bolted on because it was. If we started over, notebook and visual would be two views of the same underlying pipeline, not two separate systems.
Who should use visual builders vs. notebooks?
Visual builder: When you have a defined pipeline you’ll run repeatedly, when reproducibility matters, when multiple team members share workflows, when you need scheduling/monitoring.
Notebooks: When you’re exploring data without a clear plan, when you need maximum flexibility, when you’re a single researcher working on a one-off analysis.
Both: Most real research workflows. Explore in a notebook, then formalize in a visual pipeline.
Workbench is part of Graphomics (graphomics.com). If you’ve built or used bioinformatics workflow tools, I’d love to hear what works and what doesn’t in your experience.