Vale la pena echarle un vistazo a Litestar

• Litestar es una joya poco conocida entre los frameworks web asíncronos de Python
• Gracias a su rápida escalabilidad y arquitectura flexible, se puede aplicar fácilmente a distintos tipos de proyectos
• Ofrece modelado de datos sin depender de bibliotecas específicas como Pydantic
• Su integración con SQLAlchemy es excelente, lo que le da una gran fortaleza en conexión y gestión de bases de datos
• Sus funciones integradas para autenticación, caché, logging, monitoreo y más permiten usarlo de inmediato en entornos reales

---

Resumen de Litestar

• En los últimos años han ganado atención los frameworks web de Python async-first y basados en type hints, y entre ellos se eligió Litestar para adquirir experiencia de uso
• Al adoptarlo como framework principal en varios proyectos reales, la confianza en esa elección ha seguido aumentando
• Muchos desarrolladores web de Python aún no conocen Litestar, así que este texto presenta sus principales ventajas y características distintivas

Ejemplos y comparación con otros frameworks

• Litestar permite escribir con mucha facilidad incluso una aplicación web de un solo archivo

  • El route decorator es una función independiente que no está ligada al objeto app
  • En el código de ejemplo, al acceder a /greet?name=Bob se devuelve “Hi, Bob!”
  • Si falta un parámetro obligatorio, responde automáticamente con un 400

• A diferencia de microframeworks clásicos de Python como Flask o FastAPI, Litestar tiene características estructurales que le permiten escalar de forma natural en proyectos de distintos tamaños

  • En Flask o FastAPI, los decoradores de rutas están ligados al objeto app, lo que puede provocar problemas de import circular al separar en múltiples archivos
  • Normalmente hay que usar un registro de rutas secundario (blueprint en Flask/Quart, APIRouter en FastAPI, etc.), así que la barrera de entrada sube o se requiere cambiar la estructura
  • En cambio, como en Litestar el decorator es una función independiente, la transición entre una app de archivo único y una estructura distribuida a gran escala es muy sencilla

• Gracias a la arquitectura base y la forma en que está escrita la documentación de Litestar, es posible introducir desde muy temprano los conceptos de router y agrupación de funcionalidades, lo que facilita mantener la consistencia incluso al construir APIs complejas

  • Su fortaleza está en la composability, como inyección de dependencias, permisos y configuración compartida por ruta
  • Es posible registrar la misma ruta varias veces para aplicar autenticación o dependencias según el entorno

Modelado sin dependencia de Pydantic

• Frameworks como FastAPI dependen fuertemente de Pydantic para los datos

  • Pydantic destaca en validación y serialización de datos basada en tipos, pero su integración directa con ORMs como SQLAlchemy no es sencilla
  • En la práctica, eso obliga a escribir por separado los modelos de SQLAlchemy y los modelos de Pydantic

• Litestar soporta de forma general distintos tipos además de Pydantic, como dataclasses, msgspec, attrs y modelos de SQLAlchemy

  • Incluye un protocolo de plugins de serialización, lo que mejora su extensibilidad
  • Trae extracción automática de objetos de transferencia de datos (DTO), así que si cambias la clase de datos original, el DTO se refleja automáticamente
  • También permite declarar fácilmente exclusión o inclusión de campos, mapeo de nombres y DTOs para actualizaciones parciales
  • Esto ayuda a evitar la duplicación de campos del modelo y errores frecuentes en procesos manuales de sincronización

Integración con SQLAlchemy y presentación de Advanced Alchemy

• El ORM SQLAlchemy es, en la práctica, el estándar para conectarse a bases de datos en Python

  • Litestar destaca mucho por su nivel de integración con SQLAlchemy, incluyendo serialización automática de esquemas, automatización de DTOs, plugins para gestión de sesiones y plugins compuestos

• A través de la biblioteca Advanced Alchemy (mantenida por el equipo de Litestar), se amplían aún más las capacidades de SQLAlchemy

  • Ofrece varias mejoras de calidad, como PKs grandes agnósticas de base de datos, timestamps automáticos, claves UUID, tipo JSON, integración con migraciones de Alembic y funciones de Seed/Export
  • Una función particularmente destacable es el soporte para abstracciones de repository y service layer, que proporciona automáticamente varias capacidades de persistencia como CRUD y paginación
  • En frameworks que, a diferencia de Django, ofrecen menos guía estructural, esto ayuda a establecer una forma organizativa recomendable para introducir repository/service layer

Otras características y funciones integradas

• Litestar también ofrece de forma nativa sistema de autenticación (funciones guard, middleware), caché (stores), logging, respuestas de error estandarizadas, métricas basadas en Prometheus/OpenTelemetry y soporte para htmx
• A diferencia de otros microframeworks, para implementar ciertas funciones no hace falta buscar bibliotecas externas ni escribir glue code personalizado
• Mantiene la simplicidad de un “microframework”, pero cuando se necesita expansión o funciones adicionales, estas pueden usarse de inmediato según convenga
• Más que ser un reemplazo directo de Django o Flask, su concepto se acerca a combinar de forma Pythonic ventajas de frameworks de otros lenguajes como Java Spring Boot, por ejemplo estructura inicial y conveniencia
• En conjunto, es una opción con alta productividad y ventajas estructurales para el desarrollo web profesional en Python

Conclusión

• Litestar está emergiendo como un framework que cualquier desarrollador web de Python debería considerar al menos una vez, gracias a su asincronía, enfoque basado en tipos, escalabilidad flexible, modelado de datos no rígido, y excelentes capacidades de ORM y funciones integradas
• Tras usarlo repetidamente en proyectos reales, se ha comprobado su alta productividad y mantenibilidad en entornos diversos, incluidos startups y otros tipos de proyectos
• Se espera que los desarrolladores lo incluyan entre las opciones al planear su próximo proyecto web en Python

[minhoryang]

¿No existe ya una solución bastante clara para el "problema de importación circular" en Python? Me cuesta verlo como un problema grave.

[GN⁺]

Opinión de Hacker News

• Durante el último año he estado desarrollando un proyecto grande de backend con FastAPI. Empecé siguiendo el estilo del tutorial oficial, pero me resultó incómodo que la plantilla oficial de FastAPI y su forma de manejar dependencias prácticamente empujaran a meter todo el CRUD en un solo archivo. Al usar SQLModel también me topé con varias limitaciones, como la falta de soporte para modelos polimórficos, y eso, sumado a que incluso los PR de mejora de la comunidad podían pasar meses sin recibir ni una revisión, me hizo dudar de qué tan bien mantenido está. La documentación tampoco tenía suficientes referencias realmente útiles, así que al final tuve que revisar hasta el código fuente. Está bien para armar CRUD rápido, pero para construir sistemas complejos siento que terminas montando otro framework encima del framework, así que no creo recomendarlo. Desde mañana planeo migrar a Litestar
  • Si quieres estudiar un caso práctico de una app grande hecha con FastAPI, creo que conviene revisar el código del servidor en el repo polarsource/polar. Ahí están bien reunidos ejemplos reales de escalado, como autenticación y pruebas, así que pienso aprender siguiendo cómo está implementado ese repo
  • Estoy empezando a aprender diseño de aplicaciones centradas en API, y en este texto aprendí muchos puntos de arquitectura y herramientas que no había considerado. Yo también pienso probar Litestar. Gracias por las opiniones y por el artículo útil
  • No estoy de acuerdo con que en el tutorial oficial de FastAPI se enfatice demasiado SQLModel. En la pantalla principal ni siquiera se menciona, y solo aparece en la página donde explican la conexión con bases de datos relacionales. Que el tutorial use un ORM específico me parece una elección natural, y si SQLModel no te sirve, creo que el usuario debe escoger otra opción. Yo también vi el tutorial y decidí usar SQLAlchemy puro
  • Leyendo la documentación de Litestar, vi que también trae integrado un sistema de eventos. Es una función que en FastAPI tuve que construir por mi cuenta durante semanas, pero en Litestar ya viene lista desde el inicio
  • También me da la impresión de que Litestar debe tener algunas limitaciones. Aunque tiene menos comunidad, documentación y discusión que FastAPI, ¿igual creen que es más adecuado para aplicaciones complejas? Me interesa saber su opinión
• Litestar es muy bueno para construir backends de API. Lo uso directamente y lo recomiendo con fuerza. Advanced Alchemy también está mejorando cada vez más. Incluso sitios tradicionales con renderizado de plantillas del lado del servidor se pueden hacer perfectamente con Litestar, y además trae integrado un plugin para HTMX. Dicho eso, los patrones para diseñar endpoints de API a veces se sienten un poco incómodos en endpoints tradicionales con renderizado del servidor, como los de validación de formularios o redirecciones. Litestar en sí no tiene un sistema de manejo de formularios en el sentido más real del término, así que es difícil tratar correctamente errores por campo individual. El patrón usando @post("/route", exception_handlers={...}) se siente algo torpe. Ojalá en el futuro mejoren las herramientas integradas y la experiencia de desarrollo
  • Nunca he usado Litestar directamente, pero quizá bastaría con crear algo como un decorador propio @postform que resuelva todo el manejo relacionado con formularios
• Litestar es un framework web de Python. Lo comparto primero para quien tuviera curiosidad
  • También hubo quien dijo que gracias a eso se ahorró tiempo
• Llevo más de un año sirviendo JSON y HTML basado en plantillas con Litestar. Es un framework async de Python más rápido que FastAPI, ligero, y aun así con funciones esenciales bien cubiertas, como autenticación y sesiones. Me gustó especialmente su soporte para msgspec y el enrutamiento anidado basado en Controller. Lo recomiendo mucho
  • Yo también cambié de FastAPI a Litestar en un proyecto nuevo, y lo he estado usando sin arrepentirme. Incluso con la base predeterminada de Litestar, transmite claramente una sensación de solidez y confianza
  • He usado FastAPI durante años, pero Litestar sí parece valer mucho la pena como para probarlo al menos una vez
• Desarrollando aplicaciones con FastAPI durante varios años sentí frustraciones parecidas. Mucha gente comenta que, en desarrollo real y al medir la verdadera calidad de una API, la documentación de FastAPI, centrada en tutoriales y ejemplos, está bastante desconectada de la realidad. Me sorprende que este punto salga a relucir tan seguido
  • Últimamente me decepciona mucho que la documentación de los frameworks de Python se sienta como librerías de JavaScript, algo así como “tutorial + blog parlanchín”, y que falten referencias detalladas de API, explicaciones de parámetros y cosas así. Hace falta documentación de referencia de verdad. Quisiera detalles de opciones por método, parámetros bien organizados y opciones claramente descritas en lugar de simples frases en comentarios. Es muy incómodo que hoy haya que meterse al código fuente para encontrar información realmente clara
• FastAPI también sirve, pero para construir apps complejas no le faltan pocas limitaciones. A veces me sorprende ver que el ecosistema de microframeworks de Python parece estar redescubriendo tarde problemas que JavaEE ya había atravesado hace 15 años. Litestar se ve bastante bien. También me da curiosidad cómo manejan los casos de error en streaming
• Aunque FastAPI es popular, para proyectos pequeños starlette por sí solo me ha dejado muy satisfecho. No trae todo, pero para servicios simples no se queda corto. Litestar parece estar en un rango más cercano a FastAPI o Django
  • Últimamente estoy haciendo APIs solo con starlette, porque es limpio, conciso y la documentación oficial también está bien hecha, así que escala bien sin importar el tamaño del proyecto
• Siempre me ha interesado Litestar, aunque todavía no lo he usado directamente. Llevo bastante tiempo usando FastAPI, y creo que está un poco exagerado decir que es difícil manejar una base de código grande con FastAPI. Separando las rutas en varios archivos e importándolas para formar una estructura grande en árbol, sí se puede escalar bastante bien. Eso sí, coincido en que falta una guía oficial sobre cómo estructurar proyectos grandes. Si divides los archivos por módulos según best practices y preferencia personal, se logra suficiente escalabilidad. No he usado SQLAlchemy directamente con FastAPI, así que probablemente no conecto con ese dolor en particular
• Este artículo señala muy bien puntos importantes del desarrollo de apps reales. El diseño de Litestar realmente resulta atractivo. También tengo expectativas sobre su visión del patrón de repositorio. Estaría bien que lo desarrollaran en una publicación aparte
• El artículo estuvo bastante bueno. SQLAlchemy es complicado de manejar y su estado interno es complejo, así que tiene varios aspectos sorprendentes, pero me da curiosidad si hay gente que directamente desarrolla sin usarlo
  • Hace poco probé desarrollar un proyecto personal con peewee, y aunque no trae muchas funciones extra, cumple bien con su trabajo
  • Hay una gran diferencia entre el SQLAlchemy tradicional y Advanced Alchemy de Litestar, que igual se basa en SQLAlchemy. Antes usaba SQL puro o SQLAlchemy, pero desde que me moví de django ninja a Litestar, he ido reduciendo cada vez más mi uso directo de SQLAlchemy
  • Lo más interesante de este proyecto es que parece compensar en cierta medida las desventajas de SqlAlchemy. Cada vez que empiezo un proyecto que necesita base de datos, termino volviendo a Django. SqlAlchemy y Alembic son dolores que no quiero soportar si no hace falta
  • Creo que la forma más realista de usar SQLAlchemy es definir el esquema y las migraciones con modelos y Alembic, y luego manejar las consultas o transacciones reales directamente con SQL. Rehacer consultas con el ORM consume demasiado tiempo
  • Principalmente uso asyncpg mucho