notifications Notificaciones

Marcar todas como leídas

Ver más

lightbulb_outline

5 cosas que no me gustan de Django

timer 5 Min.

remove_red_eye 2626

calendar_today 25/03/20

Django es sin duda uno de los Framework web más populares en la actualidad. Grandes compañias como Instagram, Spotify, Bitbucket, Dropbox, entre otras, muchas, muchas más, respaldan sin duda alguna a este gran Proyecto. Hay desarrolladores que simplemente lo adoran y otros que no tanto. 😃 Desde mi punto de vista personal, el Framework es simplemente genial, hay muchas cosas que me gustan de él, como su administrador, el motor de templates, la facilidad con la cual podemos hacer pruebas unitarias, entre otras cosas más (muy probablemente me explaye en otra ocasión). Sin embargo también hay cosas que no me terminan de convencer. Cosas/detalles los cuales otros frameworks del mismo estilo, e inclusive, con menos tiempo en el mercado, lo hace de una manera mucho mejor. Es por ello que en esta ocasión me gustaría mencionar 5 cosas las cuales no me gustan de Django, Esto es, por supuesto, una simple opinión personal. Tú tienes toda libertad de no concordar conmigo y tener otro punto de vistas, lo cual sin duda es muy bueno y te invito que plasmes tus comentarios, vaya, en la sección de comentarios. 🍻

Bien, sin más dilación comencemos con este listado.

ORM

El ORM de Django, es quizás, el feature que menos me agrande del Framework. Si bien es cierto que con él somos capaces de interactuar con la base de datos sin conocer el lenguaje SQL, creo que el hecho que tengamos que utilizar con el atributo objects y no la misma clase como modelo, hace que se pierda un poco el encanto del Framework.

Por ejemplo, en otros Frameworks web, como lo puede ser Ruby on Rails , una búsqueda simple pudiera quedar de la siguiente manera:

User.where('email is ?', nil).limit(10)

Sin duda algo muy fácil de leer. Ahora, en Django, la misma consulta quedaría de la siguiente forma:

User.objects.filter(email___isnull=True)[:10]

Funciona, de eso no hay duda, el problema nace cuando comenzamos a complicar las consultas y queremos definir acciones predeterminadas, es decir, métodos. Siguiendo con la comparación con Ruby on Rails, si queremos definir métodos a nuestro modelos, en rails lo hacemos sin ningún problema, ya sea con métodos de instancia o métodos de clases.

class Video < ActiveRecord::Base

  scope :visble,->{ where(visble: true) }

  def self.by_gt_duration(duration)
    where('duration > ?', duration).visble
  end

end

Con Django sucede algo curioso. Sin bien es cierto podemos definir los métodos dentro de la clase de modelo, lo correcto, según la documentación oficial, es apoyarnos de la clase Manager, y es allí, donde se definirán los nuevos métodos, para así ,de esta forma, realizar las peticiones a través del atributo objects.

from django.db import models

class VideoManager(models.Manager):
    def get_by_duration(self, duration=0):
        return self.filter(duration__gte=duration).filter(visible=True)

class Video(models.Model):
    title = models.CharField(max_length=50)
    duration = models.IntegerField(default=0)
    visible = models.BooleanField(default=False)

    objects = VideoManager()

Esto no solo complica los modelos, agregando un nuevo nivel de abstracción, si no que abre la puerta otro problema. Si queremos ser aun más flexibles con los consultas, por ejemplo, reutilizando ciertas condiciones, tendremos que apoyarnos de una tercera clase, un tercer nivel de abstracción, ahora trabajando con la clase QuerySet.

from django.db import models

class VideoQuery(models.QuerySet):
    def visible(self):
        return self.filter(visible=True)

    def duration_gte(self, duration):
        return self.filter(duration__gte=duration)

class VideoManager(models.Manager):
    def get_queryset(self):
        return VideoQuery(self.model, using=self._db)  

    def get_by_duration(self, duration=0):
        return self.get_queryset().visible().duration_gte(duration)

class Video(models.Model):
    title = models.CharField(max_length=50)
    duration = models.IntegerField(default=0)
    visible = models.BooleanField(default=False)

    objects = VideoManager()

>>> Video.objects.get_by_duration(10)

No me mal entienda, esto funciona. Uno pudierá pensar que al estilo de Django las consultas y los métodos estan mucho mejor organizadas, y hasta cierto punto es verdad. El problema que veo, es que de igual forma es posible tener el código muy bien organizado sin tener que pasar por tantos niveles de abtracción, tal y como Eloquent, el ORM de Rails, nos demuestra, o, no vayamos tan lejos, hay frameworks de Python como Peewee o SQLAlchemy que sinceramente no se complican tanto la vida.

Archivos URLs

Algo que me gusta mucho de Django son sus aplicaciones. Se entiende que cada aplicación será un módulo independiente de otros, teniendo un nivel de cohesión bajo. Cada aplicación tendrá sus propios recursos para funcionar, hablamos de modelos, templates, vistas, urls, esperen... las urls no forman parte esencial de una aplicación.

Cuando creamos una aplicación en Django el archivos urls.py simplemente no se crea de forma automática; seremos nosotros, los desarrolladores, quienes debemos a hacer esto forma manual. Es un proceso simple, es verdad, nuevo archivo, urls.py, importamos un par de cosas y listo. Pero de todo esto, algo que no me queda del todo claro es por que el archivo no se crea de forma automática, siendo que, el 90% de las veces que creamos una aplicación (dato inventado completamente por mi) se es necesario este archivo. Es más, me atrevo a decir que el archivo urls.py es mucho más utilizado que los archivos test.py o admin.py.

Quizás esto en algún futuro se agregue al framework, como lo han hecho muchas cosas más. Si recordamos las migraciones en Django, hasta hace un par de versiones, no eran nativas.

Archivo de configuración

El archivo settings.py es otro archivo que me causa un poco de conflictos. En este archivo colocaremos todas las configuraciones, necesarias, para nuestro proyecto. Y creo que ese es mi problema, que todas las configuraciones deben estar en un mismo archivo. Definir base de datos, templates, rutas, logs, configuraciones de correos, trabajos en segundo plano y todo lo que se necesite en el proyecto deberá estar en el archivo settings.py

Para proyectos pequeños no debería haber muchos problemas, pero si hablamos de un proyectos con docenas de aplicaciones, módulos externos y cientos de funcionalidades, el archivo se vuelve un cao. Es cierto, podemos crear otros archivos y simplemente importar, pero, creo que no debería ser necesario esto. Entiendo que el Framework no es convesión sobre configuración pero creo que ciertas cosas pudieran separarse desde un pricipio, desde la creación del proyecto mismo. Mi humilde opinión.

Ambientes

Otro problema que creo existe, y va muy relacionado con el archivo settings.py, es el manejo de los ambientes de trabajo. Por lo general en cualquier proyecto deberíamos tener, por lo menos, 3 ambientes, me refiero a desarrollo, testing y producción (Aun que si somos cinceros aveces me quedo con solo desarrollo y producción).

El problema aquí es cómo separar los ambiente. Por ejemplo, el Framework por si solo nos ofrece realizar pruebas unitarias, algo bastante cool la verdad, pero, ¿quiere que trabaje con la misma base de datos de desarrollo o la misma base de producción? ¿que utilice las mismas configuraciones para un entorno u otro? no lo creo. Es verdad, hay aplicaciones y formas las cuales podemos separar los entornos de forma profesional, pero caigo en lo mismo, esto es algo necesario en todos los proyectos, y el hecho que le dediquemos un par de minutos en configurar es algo que no me termina de convencer.

Convención sobre configuración

Y por último, o sí, convención sobre configuración. El hecho que Django no implemente este paradigma es algo que no me termina de gustar. Esto, como menciona anteriormente, es completamente mi opinión, y se que por la misma naturaleza del Framework, implementar este paradigma al cien por ciento no posible. Me gustaría que si me vista tiene por nombre admin y es de la aplicación users de forma automática se renderize el archivo admin.html del folder users, pero, no es así.

Mi principal problema con esto es que a veces, nosotros como desarrolladores, al no seguir un estándar, podemos llegar a tener como resultado código espagueti, claro, esto no culpa del Framework, pero si creo que este tipo de prácticas nos ayudarían mucho como desarrolladores. Por ejemplo Rails, si uno es desarrollador Rails y se muda a otro framework web, facilmente podría aplicar las buenas prácticas de que a este nuevo framework. Buenas prácticas, que no necesariamente, en sus comienzo, él o ella, haya tenido, si no que con el framework mismo se logro.


Bien este sería mi pequeño listado de cosas que no me terminan de gustar de Django. Como sabemos no todo es perfecto y cada uno ve las cosas de forma diferente. Aunque existan cosas, que en lo personal, no me gusten del Framework, no por ello lo dejaré de usar o lo dejaré de recomendarlo, por que, como mencione anteriormente, es una herramienta muy buena, versátil y Flexible con la cual sin duda podremos construir proyectos asombrosos en muy poco tiempo y con poco esfuerzo. 🤠🐍

Otros artículos del blog

Comunidad

Inicia sesión o Regístrate para poder agregar tu respuesta.