10 · Flask vs Streamlit: elegir la herramienta
Mismo modelo, dos herramientas — elige por AUDIENCIA. Flask (o FastAPI) construye una API REST programática para otros sistemas y frontends; Streamlit construye un panel de cara al humano con casi nada de código de frontend. La pregunta decisiva siempre es: ¿el consumidor es una máquina o una persona?
Elige por el CONSUMIDOR: si una MÁQUINA consume el modelo (otro servicio, una app móvil, un frontend a medida), construye una API REST con Flask/FastAPI — controlas cada detalle y devuelves JSON. Si una PERSONA lo consume (un analista, un interesado, un demo rápido), construye un panel con Streamlit — código de frontend mínimo, interactividad instantánea, pero menos personalización. Audiencia primero; control vs esfuerzo después.
Sin esto:
Elige la herramienta equivocada y peleas con el framework: una app de Streamlit no puede ser consumida limpiamente por otro programa, y construir a mano un panel de Flask + HTML + JS que iguale la interactividad de Streamlit son días de trabajo para lo que Streamlit te da en una tarde.
Ahora conoces ambas herramientas. La habilidad real no es escribir Flask o Streamlit — es saber cuál necesita un trabajo dado. No son tanto competidores como respuestas a preguntas distintas, y el factor decisivo casi siempre es el mismo: ¿quién consume el modelo — una máquina o una persona?
Flask / FastAPI — cuando una MÁQUINA es el consumidor. Si lo que llama a tu modelo es otro programa — una app móvil, un servicio de facturación, el backend de un compañero, un frontend de React a medida — quieres una API REST. Habla JSON, se integra en cualquier sistema, y te da control total sobre el contrato petición/respuesta, los códigos de estado, la autenticación, y las cabeceras. El costo de ese control es el esfuerzo: una API no tiene UI, así que un humano no puede usarla directamente — alguien aún tiene que construir un frontend encima. (FastAPI es el hermano moderno — async, tipado, auto-docs — pero el mismo rol de "API para sistemas".)
Streamlit — cuando una PERSONA es el consumidor. Si lo que usa tu modelo es un humano — un analista hurgando en predicciones, un interesado al que le haces un demo, tú explorando un modelo — quieres un panel. Streamlit te da widgets interactivos, gráficos y cargas en Python puro con casi nada de código de frontend: sin HTML, sin JS, sin rutas. El costo es menos personalización y control — trabajas dentro del modelo de layout y componentes de Streamlit, y es incómodo de consumir programáticamente (es una UI, no una API limpia).
La tabla comparativa — cuatro ejes que lo deciden:
| Eje | Flask / FastAPI (API REST) | Streamlit (panel) | |---|---|---| | Audiencia | Máquinas — otros servicios, apps, frontends | Humanos — analistas, interesados, demos | | Control / personalización | Total — cada cabecera, código de estado, ruta | Limitado — componentes y layout de Streamlit | | Esfuerzo para una UI | Alto — construyes el frontend aparte | Mínimo — los widgets son Python puro, sin frontend | | Interactividad en tiempo real | La cableas tú (JS/websockets) | Integrada — el modelo de re-ejecución, gratis |
Leyendo la tabla: Flask cambia esfuerzo por control; Streamlit cambia control por velocidad. Ninguno es "mejor" — optimizan para cosas opuestas. Una API es la opción correcta cuando otro software debe integrar el modelo o necesitas control fino; un panel de Streamlit es correcto cuando una persona necesita interactuar con el modelo rápido y no quieres construir un frontend.
No son mutuamente excluyentes. Muchos despliegues reales envían ambos sobre el mismo modelo: una API de Flask/FastAPI para que otros sistemas integren, y un panel de Streamlit para que los humanos exploren — dos puertas de entrada a un artefacto. Eso es justo lo que construye el capstone (próxima lección).
La celda de solo-lectura pone las dos superficies de "predecir" lado a lado — una ruta JSON de Flask y una app de widgets de Streamlit sobre el mismo modelo — para que veas cómo luce la misma predicción a través de cada lente.
El mismo modelo expuesto de dos formas: una API JSON `POST /predict` de Flask para máquinas (control total, devuelve JSON) y un panel de widgets de Streamlit para humanos (código mínimo, muestra un resultado legible) — el consumidor decide cuál construyes.
El servicio de facturación de otro equipo necesita llamar tu modelo de churn programáticamente y recibir un resultado estructurado sobre el que pueda actuar automáticamente — sin humano de por medio. ¿Qué herramienta encaja, y por qué?
- La pregunta decisiva es la AUDIENCIA: un consumidor máquina → API REST de Flask/FastAPI (JSON, control total); un consumidor humano → panel de Streamlit (widgets, código mínimo).
- Flask cambia esfuerzo por control (construyes el frontend, pero dueño de cada detalle); Streamlit cambia control por velocidad (interactividad gratis, pero dentro de su modelo de componentes).
- Son complementarios, no rivales — muchos despliegues envían AMBOS una API y un panel sobre el mismo modelo, uno para sistemas y otro para personas.
Toda decisión de servir un modelo empieza aquí: un motor de scoring de fraude que otros servicios llaman se envía como API; un explorador de churn que un analista hurga se envía como panel de Streamlit — y los proyectos grandes envían ambos.
Si lo quitas: Elegir mal significa pelear con la herramienta para siempre — un panel que ningún servicio puede integrar, o semanas codificando a mano un frontend que Streamlit te habría dado gratis.