I’m a data engineer who started on Alteryx before moving to Python, and I kept missing one thing: being able to click any step in a pipeline and immediately see what my data looked like. That frustration turned into Flowfile, a visual data pipeline tool that runs entirely in your browser using WASM.
You can drag and drop transformations, preview your data at every step, and export clean, standalone Python code. There’s no backend, no signup, and nothing leaves your machine. It’s built with Vue and vue-flow, and runs Pyodide + Polars client-side.
In Python, after a few transformations, you’re often guessing. After a pivot on “Category”, is the column called Technology or technology? Office Supplies or Office_Supplies? You end up with df.schema and print() everywhere. I started calling this the schema guessing game.
And honestly, data engineering involves way too much debugging and not enough actual thinking. We have type hints and LSPs that autocomplete every class in your codebase, but after a simple pivot your IDE has no idea what columns exist. That’s not a rite of passage — it’s a tooling gap.
Alteryx solved the visibility problem, but after exploring newer open-source tools, I realized it never gave me the freedom or thoughtfulness you’d expect from something that costs $5k/year. You build something, you’re locked in. Your logic lives in their format, and that never sat right with me.
With Flowfile, you build transformations visually and export clean Python. You can move freely between representations — code to visual to code to YAML — without vendor lock-in. The exported output has no Flowfile dependency.
Under the hood, every transformation is a Pydantic settings object. The UI creates a NodeFilter config, and the Python API (df.filter(...)) creates the exact same config. Both build the same DAG. This was a happy accident: I started with the UI, needed structured settings for forms, and then realized the API could produce identical objects.
The WASM demo runs on Pyodide 0.27.7, which still has Polars bindings (newer versions dropped them). Internally, the engine stores Polars LazyFrames as query plans rather than actual data, so collect_schema() gives you the schema without loading anything.
We use Flowfile at work for quick data exploration and for explaining pipeline logic to teammates. I’ll often prototype visually, export the generated .py, and drop it straight into Airflow.
Feedback is very welcome. Would this be interesting if you could embed it directly into a website or internal tool?
This project was born out of curiosity. Two years ago, I was a Python developer who had never touched Vue, WASM, Electron, or MkDocs. I gave myself one month. Twenty-three months later, I’ve learned all of them. At some point you stop asking “should I learn this?” and just accept that the project will teach you whatever it needs you to know.
edwardeechoud•1h ago
You can drag and drop transformations, preview your data at every step, and export clean, standalone Python code. There’s no backend, no signup, and nothing leaves your machine. It’s built with Vue and vue-flow, and runs Pyodide + Polars client-side.
In Python, after a few transformations, you’re often guessing. After a pivot on “Category”, is the column called Technology or technology? Office Supplies or Office_Supplies? You end up with df.schema and print() everywhere. I started calling this the schema guessing game.
And honestly, data engineering involves way too much debugging and not enough actual thinking. We have type hints and LSPs that autocomplete every class in your codebase, but after a simple pivot your IDE has no idea what columns exist. That’s not a rite of passage — it’s a tooling gap.
Alteryx solved the visibility problem, but after exploring newer open-source tools, I realized it never gave me the freedom or thoughtfulness you’d expect from something that costs $5k/year. You build something, you’re locked in. Your logic lives in their format, and that never sat right with me.
With Flowfile, you build transformations visually and export clean Python. You can move freely between representations — code to visual to code to YAML — without vendor lock-in. The exported output has no Flowfile dependency.
Under the hood, every transformation is a Pydantic settings object. The UI creates a NodeFilter config, and the Python API (df.filter(...)) creates the exact same config. Both build the same DAG. This was a happy accident: I started with the UI, needed structured settings for forms, and then realized the API could produce identical objects.
The WASM demo runs on Pyodide 0.27.7, which still has Polars bindings (newer versions dropped them). Internally, the engine stores Polars LazyFrames as query plans rather than actual data, so collect_schema() gives you the schema without loading anything.
We use Flowfile at work for quick data exploration and for explaining pipeline logic to teammates. I’ll often prototype visually, export the generated .py, and drop it straight into Airflow.
Feedback is very welcome. Would this be interesting if you could embed it directly into a website or internal tool?
This project was born out of curiosity. Two years ago, I was a Python developer who had never touched Vue, WASM, Electron, or MkDocs. I gave myself one month. Twenty-three months later, I’ve learned all of them. At some point you stop asking “should I learn this?” and just accept that the project will teach you whatever it needs you to know.