10 · Flask vs Streamlit: choosing the tool
Same model, two tools — pick by AUDIENCE. Flask (or FastAPI) builds a programmatic REST API for other systems and frontends; Streamlit builds a human-facing dashboard with almost no frontend code. The deciding question is always: is the consumer a machine or a person?
Choose by the CONSUMER: if a MACHINE consumes the model (another service, a mobile app, a custom frontend), build a REST API with Flask/FastAPI — you control every detail and return JSON. If a PERSON consumes it (an analyst, a stakeholder, a quick demo), build a dashboard with Streamlit — minimal frontend code, instant interactivity, but less customization. Audience first; control vs effort second.
Without this:
Pick the wrong tool and you fight the framework: a Streamlit app can't be cleanly consumed by another program, and hand-building a Flask + HTML + JS dashboard to match Streamlit's interactivity is days of work for what Streamlit gives you in an afternoon.
You now know both tools. The real skill isn't writing Flask or Streamlit — it's knowing which one a given job needs. They're not competitors so much as answers to different questions, and the deciding factor is almost always the same: who consumes the model — a machine or a person?
Flask / FastAPI — when a MACHINE is the consumer. If the thing calling your model is another program — a mobile app, a billing service, a teammate's backend, a custom React frontend — you want a REST API. It speaks JSON, integrates into any system, and gives you total control over the request/response contract, status codes, auth, and headers. The cost of that control is effort: an API has no UI, so a human can't use it directly — someone still has to build a frontend on top. (FastAPI is the modern sibling — async, typed, auto-docs — but the same "API for systems" role.)
Streamlit — when a PERSON is the consumer. If the thing using your model is a human — an analyst poking at predictions, a stakeholder you're demoing to, you exploring a model — you want a dashboard. Streamlit gives you interactive widgets, charts, and uploads in pure Python with almost no frontend code: no HTML, no JS, no routes. The cost is less customization and control — you work within Streamlit's layout and component model, and it's awkward to consume programmatically (it's a UI, not a clean API).
The compare table — four axes that decide it:
| Axis | Flask / FastAPI (REST API) | Streamlit (dashboard) | |---|---|---| | Audience | Machines — other services, apps, frontends | Humans — analysts, stakeholders, demos | | Control / customization | Total — every header, status code, route | Limited — Streamlit's components & layout | | Effort to a UI | High — you build the frontend separately | Tiny — widgets are pure Python, no frontend | | Real-time interactivity | You wire it yourself (JS/websockets) | Built in — the rerun model, free |
Reading the table: Flask trades effort for control; Streamlit trades control for speed. Neither is "better" — they optimize for opposite things. An API is the right call when other software must integrate the model or you need fine-grained control; a Streamlit dashboard is right when a person needs to interact with the model fast and you don't want to build a frontend.
They're not mutually exclusive. Plenty of real deployments ship both over the same model: a Flask/FastAPI API so other systems can integrate, and a Streamlit dashboard so humans can explore — two front doors to one artifact. That's exactly what the capstone (next lesson) builds.
The read-along cell puts the two "predict" surfaces side by side — a Flask JSON route and a Streamlit widget app over the same model — so you can see how the same prediction looks through each lens.
The same model exposed two ways: a Flask `POST /predict` JSON API for machines (total control, returns JSON) and a Streamlit widget dashboard for humans (minimal code, shows a readable result) — the consumer decides which you build.
Another team's billing service needs to call your churn model programmatically and get back a structured result it can act on automatically — no human involved. Which tool fits, and why?
- The deciding question is the AUDIENCE: a machine consumer → Flask/FastAPI REST API (JSON, total control); a human consumer → Streamlit dashboard (widgets, minimal code).
- Flask trades effort for control (you build the frontend, but own every detail); Streamlit trades control for speed (interactivity for free, but within its component model).
- They're complementary, not rivals — many deployments ship BOTH an API and a dashboard over the same model, one for systems and one for people.
Every model-serving decision starts here: a fraud-scoring engine other services call ships as an API; a churn explorer an analyst pokes at ships as a Streamlit dashboard — and big projects ship both.
If you remove it: Choosing wrong means fighting the tool forever — a dashboard no service can integrate, or weeks hand-coding a frontend Streamlit would have given you for free.