Hace unos 6 meses comencé a trabajar en un proyecto Python/Django. Si bien yo ya tenía cierta familiaridad con Python, nunca había trabajando con Django, la mayoría de las cosas que había hecho a nivel profesional tenían que ver con scripts para automatizar tareas de deployment.

Para ser justo, me parece que antes de compartir mis reflexiones debo explicar algunas cuestiones de contexto que pueden tener cierta influencia en mis percepciones.

• El primer punto es importante: no estuve trabajando en un proyecto nuevo, sino en una aplicación existente. Más concretamente una aplicación creada hace ya varios años con Python 2.7 y Django 1.4.
• La aplicación tiene una cantidad no despreciable de código JavaScript, no React, no Angular, JavaScript puro, «vanilla JavaScript» condimentado apenas con jQuery. Esto es un punto no menor, porque parte del tiempo lo he pasado trabajando con código JavaScript en lugar de Python.
• La aplicación cuenta con unos 1000 test automatizados del código python y también tiene tests automatizadas de parte del código JavaScript.
• Esta aplicación Django es la parte central de un ecosistemas de aplicaciones, la mayoría de ellas también construidas con Python pero no necesariamente con Django.
• Finalmente el último detalle contextual es que las funcionalidades en las que estuve trabajando tuvieron que ver con cuestiones «algorítmicas/lógica de negocio», o sea, no tuve que modificar el modelo de datos.

Aclarado el contexto ahora sí mis percepciones. Definitivamente Django es a Python lo que Rails es Ruby con todo lo bueno y lo malo que eso pueda implicar. Django es un framework orientado a la creación de sistemas de información (CRUD) y como tal ofrece muchas facilidades para con relativamente poco código resolver muchas de las cuestiones planteadas por este tipo de aplicaciones: validaciones, persistencia de datos, envío de mails, autenticación, manejo de usuarios, sistema de backoffice/admin, etc. Todo esto complementado con una funcionalidad de scaffolding que genera una porción importante de nuestro código.

Todas estas facilidades que provee Django no son «gratis», tienen un costo asociado el cual implica que la aplicación tiene cierta estructura que en ocasiones puede ser un dolor de cabeza. En este sentido un punto que me resulta particularmente molesto es el grado de acoplamiento con la base de datos que dificulta la escritura de pruebas unitarias ya que al momento de escribir pruebas que utilicen las entidades de negocio (lo que Django llama models) es necesario tener una conexión con la base de datos. Otra cuestión que me resulta muy molesta es la convención de utilizar «pocos archivos pero muy grandes», ejemplo: en vez de tener un archivo por cada clase, un archivo por cada controller, etc, la propuesta es tener un archivo models con todas las clases de entidades, un archivo views con todos los controllers, etc, etc.

Por otro lado hay dos cuestiones que me resultan fantásticas: el debugger de línea de comando (que en realidad es un funcionalidad de Python, no de Django) y el Django shell, que al igual que el Rails console, nos permite manipular de forma interactiva los objetos de nuestra aplicación.

Otra cuestión, en este tipo de frameworks, es el manejo de la persistencia. Al igual que Rails, la persistencia está implementada al estilo ActiveRecord. Esto es que cada entidad/model hereda de una clase base provista por el framework la cual nos provee todo un conjunto de métodos para «llevar y traer» objetos de la base de datos y de esta forma no tenemos que lidiar con la escritura de SQL.

Finalmente el último punto que quiero mencionar es la sensación (y resalto que es una sensación) de que Django «nos lleva a hacer aplicaciones grandes» en contraposición con las tendencias actuales de micro-servicios. Ojo, no digo que el frameworks nos obligue a hacer aplicaciones grandes, sino que algunas de las funcionalidades que provee (como la posibilidad de tener varias aplicaciones dentro de un mismo proyecto) resulta muy tentador para seguir trabajando dentro del mismo proyecto/artefacto en lugar de crear un nuevo proyecto independiente.

En fin, si bien hay cuestiones que no me gustan nada, hay algunas otras que están muy bien.