Desarrollo web con Python: algunos consejos

Disclaimer: Python no es mi lenguaje de preferencia para desarrollo web, así que he tenido limitada experiencia con sus herramientas existentes. Por lo mismo esto no es una guía, sino que velo como un consejo de alguien que logró solucionar sus problemas.

Personalmente, siempre prefiero la herramienta que haga mi trabajo como desarrollador más fácil, en desmedro de la herramienta que haga más fácil el trabajo de la máquina. Las máquinas son mágicas e inteligentes, yo no. No necesitan ayuda, yo si.

La mayoría de las veces, esto puede llevar a un overhead más alto debido a varias razones, pero generalmente tiene que ver con el costo de las herramientas que hacen tu trabajo más fácil. Dicho esto, todos los ingenieros y desarrolladores saben que nuestro rubro es saber manejar el trade-off en distintos escenarios.

Hace un tiempo, tomé un proyecto donde se requería una pequeña sección de administración y CRUD, y además el lenguaje debía Python. Para mí, que sólo consideraba a Python como un lenguaje para hacer análisis de data y un par de cosas más pero nunca desarrollo web, fue una oportunidad para explorar el mapa.

Primero, ¿framework?, ¿si es así, cuál? Me llegó la sugerencia de Flask, un microframework web. Al investigar un poco, me recordó a la escencia de Sinatra (si, mi corazón vive con Ruby, deal with it) y me gustó. Para proyectos pequeños, que no requieran mucho más que un CRUD y unas vistas simples, es perfecto. Sin toda la bullshit de Django (lo mismo para Rails).

Luego, el delicado tema de la persistencia de data: ¿Qué mapeador de data y ORM utilizar? ¿Vale la pena evitar todo eso y trabajar con alguna implementación propia con sentencias SQL salvaje corriendo por allí?

En mi experiencia y por los horrores que he escuchado de algunos colegas, existen sólo alrededor de 3 o 4 situaciones dónde una implementación propia de manejo de data (DIY-ORM) a bajo nivel hacen sentido, y la mayoría incluyen un arma apuntada a tu cabeza o depresión severa o trabajar en 1960.

Siempre favorece el uso de herramientas probadas por otros, no se trata de seguir a la manada, sino que utilizar algo que ya ha sido probado. La rueda ya se inventó. Puede ser más pesado para la máquina, pero si fuera tan grave, ninguna de estas herramientas existirían o tendrían mercado en primer lugar. Y además, es más seguro. Errores de seguridad de data (SQL Injection y todas esas hierbas) ocurren principalmente con implementaciones DIY que no velan severamente por la seguridad o sanitización.

Me topé con SQLAlchemy. Mi sensación inmediatamente fue que estaba sacando un documento en el Registro Civil, donde los números de espera era runas y yo tenía el número 4 y los empleados públicos eran oficiales de la Gestapo.

Leí varias opiniones que SQLAlchemy es muy burocrático, muy complejo para acciones básicas como por ejemplo, obtener un registro. También leí que es muy poderoso, con funcionalidades que permiten alta complejidad, y el precio que paga es la burocracia, y la gran curva de aprendizaje.

También probé algo que Quick ORM, pero realmente es SQLAlchemy en el fondo, con funcionalidades propias encima que lo hacen más simple. O más bien, lo hacían. Desde al menos, marzo de 2014 dejó de ser mantenido.

Al final encontré Orator y encontré mi hogar. Orator implementa el patrón ActiveRecord, cosa que automáticamente significa un precio en performance que, en mi opinión, se paga múltiples veces con la simplicidad.

Conectar con una base de datos es equivalente a describirla en un archivo de configuración (5 líneas en YAML). Soporta uso simultáneo de más de una DB con la misma facilidad de utilizar sólo una.

Clases sencillas, relaciones sencillas, sistema de migración clarísimo y fáciles de manejar, un query builder poderoso y simple, soporte para scopes, agnóstico al motor de bd. La API es más limpia, agradable y sencilla que la de SQLAlchemy.

Orator es Ruby on Rails en el mundo de Python. Es relativamente nuevo (aún no llega a versión 1) y poco popular, de hecho no existe tag en StackOverflow para Orator, y aún así, he logrado solucionar todos los problemas que me han surgido solo leyendo la documentación. Bastante bien para un 0.9.

Después de mucho investigar, leer opiniones de apoyo, opiniones en contra, artículos algo neutrales, me quedo con una idea que ya conocía antes de entrar a Python. No tiene que ver con un lenguaje específico.

Un buen ORM te permite manejar, de manera elegante y sencilla, la hermosa complejidad que posee SQL puro, sin utilizar el dolor, el peligro y la fealdad de SQL puro.

Mucha gente ha construido muchos ORM en Python, muchos. Algunos de ellosy su comparación con otros puede ser vista acá comparados con otros. Y un buen cara a cara entre SQL puro y ORMs.