Manuel RubioSenior Software Engineer, Elixir at Telnyx

Hablemos de DJANGO

28 Sept 2024 · 14 min

Watch on YouTube

14:04

Chip and Violeta explain Django, the Python web framework built on DRY principles and rapid development. Created by Adrian Holovaty and Jacob Kaplan-Moss, it powers Quora, Instagram, Pinterest, and The New York Times. The hosts break down Django's MTV architecture, its ORM, and why it has a gentler learning curve than Rails.

Chapters

No te repitas a ti mismo. No te repitas a ti mismo. No te repitas.
¿Qué haces?
Estoy repasando. Hoy es un gran día.
Te has salido con la tuya y hoy hablamos más de Python, Sí, y calla que me desconcentras. No te sirve de nada prepararte a última hora. Yo vi las votaciones y me puse a estudiar mucho antes.
¿Mucho antes? Espera, ¿has estudiado?
Ah, ya sabéis entonces que la gente ha votado para escuchar algo más sobre Python. ¿Sobre Django específicamente?
Sobre Django especialmente.
¡Vaya! Le ganó al Lambo Boy.
Larabel, bueno, seguro que sale la próxima vez.
No si sale antes Go.
Vayamos al grano, que no he estado estudiando para nada. Venga, venga, preguntadme.
Vale, Chip, pero antes... ¿Un inciso?
Esto debe ser un evento canónico ya.
Antes de continuar, un inciso.
¿Te gustaría apoyar a nuestro canal?
No te olvides de darle a me gusta y, si no lo estás, suscribirte para no perderte futuro contenido. También puedes apoyarnos si quieres uniéndote al canal o enviándonos un gracias aquí abajo en el botoncito. Nosotros te lo agradeceremos igualmente y os avisaremos de ofertas y promociones del canal.
Y además también podemos acompañarte desde tu plataforma de podcast favorita.
Ahora sí, continúa.
¿Qué es Django?
Esa es fácil.
Django es... un framework web para facilitar la creación de páginas web con base de datos.
¡Esa me la sabía! Oye, no vale responder las preguntas que se hacen a los demás.
Hay que ser más rápido, Chip.
No te preocupes, Chip. Esta la podrás responder tú.
Estoy preparado. ¡Dispara!
Dime su filosofía de diseño.
No te repitas a ti mismo. O DRY en inglés.
Bien, esa es una y muy importante. Su filosofía es que la redundancia es mala y la normalización es buena. Hay que acomodar todo en su lugar y en un único lugar.
Un lugar para cada cosa y cada cosa en su lugar.
Vale. Otra era... menos código. Escribir cuanto menos código mejor.
Siempre que funcione, supongo.
De hecho, es una característica que persiguen la mayoría de frameworks web actuales: eliminar el código repetitivo, código de plantilla o código predefinido.
A eso le decimos boilerplate.
Código repetitivo. No pienso usar anglicismos. Pero sigamos, aún nos faltan un par de filosofías que sigue Django.
Sí, fácil. Otra era el desarrollo rápido.
Productividad siempre está bien. ¿Y la última?
La última era algo de la configuración... No, espera. De los módulos que... ¡Bajo acoplamiento, chip! Eso es lo que iba a decir.
Sí, ya.
Está relacionado con cómo se organiza el código en los módulos con bajo acoplamiento y baja cohesión.
No chip, bajo acoplamiento y alta cohesión.
¿Y qué diferencia hay?
El alto acoplamiento creo que lo conoces, pero te lo explicaré de forma muy, muy fácil. Imagina que tienes varios juguetes conectados con cuerdas muy cortas. Si quieres mover uno, todos los demás también se mueven, aunque no quieras.
Exacto. Esto es lo que pasa cuando hay alto acoplamiento en el código. Las diferentes partes del programa están tan conectadas Que si cambias una cosa, otras partes se ven afectadas incluso aunque no tengan relación.
Sí, me queda claro. De hecho, lo sabía, pero gracias por la explicación. ¿En qué se diferencia de la cohesión?
Vale, imagina que tienes una caja llena de piezas de rompecabezas y todas las piezas juntas forman una imagen. Una imagen preciosa, un código muy elegante. Cada pieza constituye una parte de esa imagen. Y no puedes separarla en otra caja porque si no pierdes parte de esa imagen. ¿Me explico?
Creo que sí. Quiere decir que todo lo que tenga que ver con un mismo código debe permanecer junto.
¡No solo eso, Chip! Imagina que en esa caja introduces otros juguetes: lápices, caramelos, goffers... ¡Sería un desastre porque cada elemento tiene una finalidad diferente!
Entonces, alta cohesión es que tienes todas las piezas del rompecabezas ¿Y solo eso?
Sí, una única tarea, una única responsabilidad, solo las piezas y nada más.
Vale, ya me quedó claro.
Pues ahora tocaría preguntar, si es que lo sabes, sin presiones.
Sí, pregunta, pregunta.
¿Por qué se llama Django?
Por Django Reinhardt.
Sí, un guitarrista romaní de música jazz. Pero, ¿por qué le pusieron ese nombre?
A ver, el principal creador de Django, Adrian Holovety, es... un alma libre, podríamos decir.
No creo que fuese al estilo de Larry Wall.
No de ese tipo. Adrian estudió periodismo e informática. De hecho, trabajó como desarrollador web y periodista en varios sitios y tocaba la guitarra.
De ahí su admiración por el guitarrista romaní.
Exacto. Cuando Adrian estaba en Lawrence Journal World, entre 2002 y 2005, Él y otros desarrolladores web—
¡Jacob Kaplan-Moss!
No está mal, Chip, aunque ha dicho desarrolladores en plural.
Pero está bien, Jacob fue uno, los otros fueron Simon Wilson y Wilson Miner. Los creadores iniciales fueron Adrian y Simon, mientras que Adrian y Jacob son en estos momentos los BDFL. No pongáis esas caras, ya recordáis lo que era un BDFL, ¿no?
Sí, un dictador benevolente de por vida.
Gracias, Violeta. Continúa, Chip. Vamos a ver, si comenzaron desarrollando su página web en PHP, ¿por qué usaron Python?
Ese es fácil. Adrian y Simon eran grandes seguidores de Mark Pilgrim, el autor de Dive into Python, un libro que habla de Python en profundidad.
Un libro de 2001 que está disponible en su página web. Os dejamos el enlace en comentarios.
Un libro muy recomendable incluso siendo de 2001.
Increíblemente habla de Python 3 y sus diferencias con Python 2.
Vale, Chip, entonces... ¿Comenzaron a usar Python porque les gustó el libro?
Según recuerdo, decían que lo programado en PHP les parecía cutre, por lo que decidieron comenzar a usar Python.
No creo que en la organización les dejasen hacer un cambio tan grande. Seguro que lo hicieron como proyecto personal.
En verdad, la empresa en la que trabajaban era pequeña. Y eso implica que tenía mucha flexibilidad. El jefe delegaba completamente en ellos y, por tanto, si ellos decían que ese era el camino a seguir, su jefe les dejaba.
En esos días había sistemas web hechos en Python, como Plone, que podría competir con WordPress, o Thope, que era su framework, pero no eligieron ninguno de ellos. ¿Sabes por qué?
Pues a ver, Plone, ya sabes, es antiguo y—
En esos momentos no era antiguo.
En verdad, según dijo en una entrevista, Adrian consideraba que ninguno era 100% adecuado. Simon y Adrian buscaban siempre usar buenas prácticas, por lo que se enfocaron en mantener URLs limpias, un uso adecuado de las peticiones GET y POST, etc.
Ahora vayamos a la parte técnica. ¿Qué arquitectura usa Django?
¿Arquitectura? ¿Te refieres a MTV?
¡Exacto! Eso mismo.
¿MTV como la MTV? ¿No habrás querido decir MVC de Modelo Vista Controlador?
No, no, MTV. A ver, en teoría sería como MVC, pero como en Django usan el controlador y lo llaman vista, y a la vista la llaman plantilla o template en inglés, entonces cambiaron el nombre por Modelo Plantilla Vista, aunque obviamente en inglés quedaría como MTV.
La arquitectura de Modelo-Vista-Controlador se basa en mantener los datos en el modelo y el modelo es la única parte de la aplicación que puede acceder a los almacenes de datos. Por ejemplo, base de datos o caché.
Sí, según recuerdo, en Rails esta parte por convención almacena todo lo que tiene que ver con los datos y crea abstracciones para que el resto de aplicación no deba preocuparse de qué se hace a nivel de almacenamiento.
Exacto. En Rails se usa ActiveRecord. Chip, ¿qué se usa en Django?
Django ORM. Una librería diseñada para facilitar la conversión de código en Python a SQL y no tener que pelearse con SQL.
Aunque haya que pelearse con Python. No sé qué es peor.
¡Ey!
Si usaras Django ORM te darías cuenta de que es mucho mejor que usar SQL directamente. De hecho, en Python si no usas Django puedes usar SQLAlchemy que es casi lo mismo.
Muy bien, Chip. ORM quiere decir justamente eso: Object Relational Mapping o mapeo de objeto a relacional. Es decir, que hace de traductor entre los objetos de Python y la lógica relacional de las bases de datos.
Lo uso a diario.
A ver, Chip, ¿por qué cambiaron de controlador a vista y qué hace la vista en esta arquitectura?
El controlador en Django se hace desde el framework. La vista se encarga solo de indicar qué datos se deben presentar.
Todo va en la configuración.
Todo va en la configuración.
Ciertamente, muchos frameworks separan la vista de la presentación que se delega normalmente en una plantilla. En Django se hace de forma explícita, indicándose así en su infraestructura. ¿Qué usamos para las plantillas?
DTL, la biblioteca de plantillas de Django, por Template Library.
Muy bien. Esta forma de plantillas ha sido muy extendida y a día de hoy podemos ver dos formas de hacer plantillas en web. La que realiza Rails, es decir, incrustando código dentro de HTML, y la que realiza Django creando un sublenguaje limitado para usar en el HTML.
Sí, es mejor el segundo enfoque porque proporciona un código más limpio y mantenible gracias a que separa claramente estas dos capas.
Aunque resta flexibilidad. Sistemas embebidos como el que emplea Rails, Phoenix Framework o Laravel Dan una mayor flexibilidad al poder emplear código Ruby, Elixir o PHP respectivamente dentro de la plantilla.
Aquí estoy con Chip, es mejor un código limpio y mantenible.
Bueno, vale, entonces ya hemos definido las capas de la arquitectura de Django. Veamos ahora, ¿qué hay hecho en Django?
Pues hay muchas empresas que usan Django: Quora, Instagram, Pinterest, The Washington Post... Obviamente, donde trabajó Adrian. Sí, también National Geographic, The New York Times, The Guardian, Mozilla, Google, Spotify, YouTube, Dropbox...
Sí, hay muchas empresas que usan hoy en día Django. No en vano Python es uno de los lenguajes más empleados y Django su framework de desarrollo web más famoso.
Además, es muy fácil de aprender. Tiene la curva de aprendizaje más baja que otros frameworks como puede ser Rails y sucedáneos.
¿Seguro? Eso no lo he visto ni leído en ningún sitio.
Tú confía en mí.
Confiaría, pero tengo entendido que muchas empresas migraron a Flask y a FastAPI para implementar microservicios.
Eso sí que no lo he visto en ningún sitio. No lo creo. Como mucho habrá algunas empresas como Instagram que usan tanto Django como Flask o incluso FastAPI, dependiendo del servicio o microservicio, pero su sistema base, el inicial, sigue estando en Django.
De momento. Estáis graciosos hoy, Un último punto, Chip.
¿El último?
¿Cómo es la comunidad de Django?
Pues la comunidad es muy activa, diversa e inclusiva. Sobre todo acogedora, lo que facilita que tanto principiantes como expertos se sientan bienvenidos. Como por ejemplo en el foro oficial.
Curioso, Chip. Ese foro está hecho en Ruby on Rails.
Pero eso es porque se emplea Discourse, un sistema ya hecho entre JavaScript y Ruby on Rails que emplean muchas comunidades. Como la comunidad de Go.
¡Vaya! Pues es verdad.
No nos desviemos, hablamos de la comunidad. De hecho, en España se ha celebrado la última DjangoCon el pasado junio de este 2024.
Sí, una pena no haber estado para transmitir el evento.
También está el Discord de Django. Ver en la descripción.
Queda claro entonces cómo contactar con la comunidad y que es abierta y amigable. Pues... Conclusiones.
Me da la sensación de que siempre que hablamos de Python los capítulos son más cortos.
Es que se te pasa volando. ¿No, Chip?
Será eso.
Creo que ya hemos comentado la historia de Django, por qué se creó, qué necesidades cubría y su enfoque y filosofía. Además, hemos dejado un par de explicaciones sobre cohesión, acoplamiento, MVC y MTV.
Completito, completito.
Yo aún quería más. Supongo que habrá que esperar a que hablemos de Flask o FastAPI.
Sí, coméntalo con los cronistas, lo mismo te echan una mano.
Ahora es el turno para vosotros. ¿Habéis usado Django?
¿Django cubrió vuestras necesidades o tuvisteis que cambiar a algo mejor?
No hay nada mejor ni más simple, ¿a que no?
Déjanos tus comentarios.
Violeta, Violeta, Violeta.
Chip, chip, chip. ¿Qué quieres?
No te retractaste.
¿De qué tendría que retractarme?
Dijiste en el vídeo de Julia que Python era lento cuando ya dijiste en otros capítulos que no lo era.
No recuerdo qué dije exactamente en el vídeo de Julia, pero si alguien se sintió ofendido Si herí el corazoncito de alguien que amase Python, si dañé la sensibilidad o la autoestima de un programador de Python, si...
Te cuesta pedir perdón, Lo siento, ¿vale?
¿Contento?
Entonces Python no es lento, ¿a que no?
No, al menos no tanto como otros.
Ay, Violeta... ¿Continuará?