Talently
Talently
Flask

Flask

El microframework Python para APIs y aplicaciones web ligeras

Flask es un microframework web para Python que provee las herramientas mínimas necesarias para construir aplicaciones web y APIs. Su filosofía minimalista y sin opiniones otorga total libertad sobre la arquitectura, convirtiéndolo en la opción preferida cuando se necesita simplicidad, flexibilidad o integración directa con el ecosistema Python de datos y machine learning.

PythonRESTMicroframeworkAPI

Demanda del mercado

Flask tiene alta demanda en proyectos de ciencia de datos, machine learning y APIs ligeras. Es ampliamente usado para exponer modelos de ML como APIs REST y en proyectos donde Python es el lenguaje principal pero no se necesita la complejidad de Django.

Alta demanda en ML y data scienceMuy usado para APIs de modelos MLPopular en startups con stack Python

Requisitos técnicos

Intermediate

Requiere buen dominio de Python y conceptos de programación web como HTTP, routing y APIs REST. A diferencia de Django, Flask requiere que el desarrollador tome decisiones sobre ORM, autenticación y estructura, por lo que es importante conocer el ecosistema de extensiones de Flask.

Casos de uso

Proyectos Reales

Flask se utiliza para desarrollar:

  • APIs REST para exponer modelos de machine learning
  • Microservicios ligeros con responsabilidades específicas
  • Prototipos y MVPs con stack Python
  • Backends simples para aplicaciones con frontends modernos

Tipos de Empresa

Flask es adoptado por:

  • Equipos de data science que exponen modelos como APIs
  • Startups en fase de prototipo con stack Python
  • Empresas con microservicios Python de bajo acoplamiento
  • Organizaciones con proyectos de investigación que requieren APIs rápidas

Escenarios de Producción

Flask es ampliamente utilizado en entornos productivos como:

  • APIs de inferencia de modelos ML con bajo overhead
  • Microservicios con lógica específica y bien delimitada
  • Backends ligeros para aplicaciones internas
  • APIs de integración entre sistemas con lógica simple

Escalabilidad

Flask ofrece múltiples mecanismos para escalar aplicaciones:

  • Despliegue con Gunicorn o uWSGI como servidor WSGI
  • Caché con Flask-Caching y Redis
  • Tareas asíncronas con Celery y Redis o RabbitMQ
  • Escalado horizontal stateless con balanceadores de carga

Ventajas y Desventajas

Ventajas

Extremadamente ligero y con mínima curva de aprendizaje para developers Python.

Total libertad sobre la arquitectura sin convenciones impuestas.

Integración directa y natural con el ecosistema Python de datos y ML.

Desventajas

Requiere decisiones manuales sobre cada componente que Django incluye por defecto.

Puede generar arquitecturas inconsistentes en equipos sin convenciones definidas.

Para aplicaciones grandes, la falta de estructura puede volverse un problema de mantenibilidad.

Comparación

Ventajas de Django

  • Solución completa con ORM, admin y autenticación integrados
  • Mayor estructura para equipos y proyectos grandes
  • Menor tiempo de configuración inicial

Consideraciones

Django es preferible para aplicaciones web completas con múltiples dominios. Flask es más adecuado cuando se necesita máxima flexibilidad, el proyecto es pequeño o la integración con ML es prioritaria.

Preguntas básicas

Flask es preferible cuando se necesita máxima flexibilidad, el proyecto es pequeño o mediano, o la API tiene un propósito muy específico como exponer un modelo de ML. Django incluye muchas herramientas que pueden ser innecesarias para una API simple.
Flask es preferible cuando el equipo ya tiene experiencia con él, se necesita compatibilidad con extensiones WSGI existentes o la simplicidad extrema es prioritaria. FastAPI es generalmente preferible para nuevas APIs donde el rendimiento y la validación automática aportan valor real.
Flask permite importar directamente librerías Python como scikit-learn, TensorFlow o PyTorch en el mismo proceso, sin overhead de comunicación entre servicios. La integración es directa y el setup mínimo, ideal para equipos de data science que necesitan exponer modelos rápidamente.
Mediante el decorador @app.route() que asocia una URL y métodos HTTP a una función. Las rutas pueden incluir variables con sintaxis como y organizarse en Blueprints para modularizar la aplicación.
Son componentes que agrupan rutas, handlers y configuración relacionados. Permiten modularizar la aplicación en secciones independientes que se registran en la app principal, facilitando la organización en proyectos que crecen.
Usando clases de configuración por entorno que se cargan según la variable de entorno FLASK_ENV o FLASK_CONFIG, complementadas con variables de entorno para valores sensibles cargados con python-dotenv en desarrollo.
En proyectos donde Python es el lenguaje del stack completo, especialmente cuando hay integración con herramientas de datos, ML o análisis. El mismo lenguaje en la API y en el procesamiento elimina la necesidad de comunicación entre servicios en distintos lenguajes.
El servidor de desarrollo integrado es de un solo hilo, no es seguro y no está optimizado para carga. En producción se usa Gunicorn o uWSGI como servidor WSGI con múltiples workers, generalmente detrás de un proxy inverso como Nginx.

Preguntas técnicas

Flask mantiene dos contextos: el de aplicación con current_app y g para datos del ciclo de vida de la app, y el de request con request y session para datos específicos de cada petición HTTP. Ambos se crean y destruyen automáticamente en el ciclo de cada request.
Usando la extensión Flask-JWT-Extended que provee decoradores como @jwt_required() para proteger endpoints, funciones para crear tokens de acceso y refresco, y manejo automático de errores de autenticación con respuestas JSON consistentes.
Con la extensión Marshmallow para definir esquemas de serialización y validación, o con Pydantic para validación con tipado estático. La validación se aplica antes de procesar la lógica de negocio, devolviendo errores estructurados.
Usando el patrón Application Factory con create_app() para instanciar la aplicación, organizando cada dominio en un Blueprint con sus rutas y handlers, y separando modelos, servicios y esquemas de validación en módulos independientes.
Son funciones que se ejecutan antes o después de cada request respectivamente. Se usan para lógica transversal como autenticación, logging, gestión de conexiones a base de datos o modificación de cabeceras de respuesta.
Usando el decorador @app.errorhandler() para registrar handlers por código de error HTTP o por tipo de excepción. Esto centraliza el formato de las respuestas de error y evita duplicar lógica de manejo de excepciones en cada endpoint.
Usando Flask-SQLAlchemy que integra SQLAlchemy con el ciclo de vida de Flask, gestionando automáticamente la conexión y el cierre de sesiones por request. Se define un objeto db que se importa en los modelos y se usa en las consultas.
Con Celery como sistema de colas de tareas y Redis o RabbitMQ como broker. Las tareas se definen con el decorador @celery.task y se encolan desde los endpoints de Flask, procesándose en workers independientes sin bloquear la respuesta HTTP.

Preguntas avanzadas

Cargando el modelo una sola vez al iniciar el worker con Gunicorn para evitar overhead por request, usando múltiples workers con pre-fork, caché de predicciones frecuentes con Redis y considerando herramientas especializadas como TorchServe o TensorFlow Serving para modelos muy pesados.
Cuando el rendimiento bajo carga se vuelve un cuello de botella, cuando la validación manual de inputs genera errores frecuentes o cuando el equipo adopta tipado estático con Python. La migración puede ser gradual exponiendo nuevos endpoints en FastAPI mientras los existentes permanecen en Flask.
Usando el cliente de testing de Flask para tests de integración de endpoints, pytest con fixtures para configurar el contexto de aplicación de test, una base de datos SQLite en memoria para tests de integración con base de datos y mocks para dependencias externas como servicios de terceros.
Con Flask-Limiter usando Redis como backend compartido en entornos multi-instancia, definiendo límites por endpoint según su sensibilidad con decoradores y devolviendo cabeceras informativas sobre los límites restantes para facilitar la integración por parte de los clientes.
Usando el módulo logging de Python con formato estructurado en JSON, añadiendo correlation IDs a cada request con before_request, integrando métricas con prometheus-flask-exporter y centralizando logs en herramientas como ELK Stack o Datadog.
Aplicando el patrón Application Factory, organizando el código en Blueprints por dominio, separando en capas de rutas, servicios y repositorios, y definiendo interfaces claras entre capas para facilitar el testing y la sustitución de implementaciones.

Errores comunes en entrevistas

Crear la instancia de Flask directamente en el módulo principal dificulta el testing y la configuración por entornos. No conocer create_app() refleja poca experiencia en proyectos Flask de mediana o gran escala.
Elegir Flask para una nueva API sin evaluar FastAPI refleja desconocimiento del ecosistema Python actual. Se espera poder articular cuándo Flask sigue siendo la opción correcta frente a alternativas más modernas.
Usar flask run o app.run() en producción es un error grave de seguridad y rendimiento. No conocer Gunicorn, uWSGI o la diferencia entre servidor de desarrollo y producción refleja falta de experiencia en despliegues reales.
Poner todas las rutas en un único archivo genera deuda técnica difícil de revertir. No conocer Blueprints o no usarlos en proyectos que crecen refleja inexperiencia organizando proyectos Flask medianos.
Acceder a recursos de Flask como la base de datos en tareas Celery o scripts sin crear manualmente el contexto de aplicación genera errores runtime. No entender los contextos de Flask es una señal de comprensión superficial del framework.
Validar manualmente con condicionales en lugar de usar Marshmallow o Pydantic genera código frágil y difícil de mantener. No conocer estas herramientas refleja inexperiencia construyendo APIs Flask robustas.