Retrospectiva de la serie#
Este es el artículo número 30 de la serie de tutoriales de Django Ninja.
En el capítulo final de la serie, nuestra «Aventura con Django Ninja» llega temporalmente a su fin.
Por supuesto, esto no es el final definitivo, ya que Django Ninja sigue siendo un proyecto relativamente nuevo; tengo grandes expectativas puestas en su futuro.
Este artículo se dividirá en dos partes:
- Repasar toda la serie, revisando los conceptos y tecnologías aprendidos en cada capítulo (mencionando solo lo indispensable).
- Compartir los mayores desafíos durante el proceso de redacción, mis expectativas sobre Django Ninja y, finalmente, mis reflexiones al completar el desafío Ironman.
Debido a limitaciones de espacio, compartiré más detalles tras bambalinas, secretos de creación y reflexiones personales en los artículos 31 y 32, independientes del desafío principal.
Además, actualizaré de forma ocasional «Artículos especiales de Django Ninja» para complementar aquellos contenidos que no pudieron explicarse minuciosamente en la serie principal. Si estás interesado, te invito a suscribirte a la serie o al boletín por email de este sitio.
Sin más preámbulos, comencemos.
Proyecto de ejemplo en GitHub#
1. Objetivos de la serie y principales logros de aprendizaje#
Volviendo al inicio del artículo 1, el objetivo de toda la serie era:
En esta serie de 30 días, exploraremos en detalle la implementación básica de Django Ninja. A través de explicaciones escritas y código de proyectos de ejemplo, te guiaremos paso a paso para familiarizarte con este framework potente y flexible para el desarrollo de API en Django.
Así es, ¿y qué cosas concretas logramos?
Principales logros de aprendizaje#
A través de esta serie, los lectores han dominado las siguientes habilidades fundamentales de Django Ninja:
- Configurar rutas en Django Ninja (artículos 7 y 8).
- Procesar diversas solicitudes y parámetros HTTP: parámetros de ruta, parámetros de consulta y body (artículos 9 al 12).
- Diseñar y definir la estructura de datos de las respuestas HTTP mediante Schema (artículos 13 al 16).
- Generar automáticamente documentación de API desde el código del proyecto, validar datos con Pydantic y capturar eficientemente errores del sistema (artículos 17 al 22).
- Aplicar con flexibilidad funciones avanzadas, incluyendo carga de archivos, paginación y filtrado de datos (artículos 23 al 27).
Sumado a ello, la autenticación y las pruebas unitarias al final. Ha sido un viaje sumamente completo.
No repetiremos aquí los matices técnicos ni las dificultades encontradas.
Repasemos juntos lo que considero los puntos clave al aprender Django Ninja, así como la satisfacción que genera —¡lo cual es muy importante!
2. Retrospectiva de puntos clave por capítulo#
Seleccionaremos únicamente las partes de cada capítulo que merecen una mención especial, incorporando mi perspectiva personal.
Capítulo 2: proyecto de ejemplo y configuración del entorno#
Lo más relevante de este capítulo no fue otro tema que la presentación de las «Herramientas modernas de desarrollo en Python». Recomiendo nuevamente la serie «Python Table Manners».
Desde Poetry hasta Mypy, considero que estas herramientas son elementos indispensables en proyectos modernos. Cada una posee alternativas; puedes elegir tus herramientas preferidas siempre que te asegures de integrar dichos elementos en tu flujo de desarrollo.
Tengo la convicción de que, sin importar cómo avance la IA, la «infraestructura» de los proyectos seguirá siendo siempre necesaria.
Capítulo 3, sección 1: rutas#
La configuración de rutas en Django Ninja difiere enormemente de la tradicional en Django y Django REST framework.
En este aspecto, las nuevas tecnologías han seguido en su mayoría el ejemplo del «decorador de rutas» introducido originalmente por Flask: un diseño excelente que merece ser tomado como referencia y aprendido 🫡
La nueva sintaxis no solo es más intuitiva y sencilla, sino que también evita el inconveniente de tener la configuración de rutas dispersa en múltiples archivos.
Sin embargo, debido a ello, las rutas se convierten en una pequeña barrera inicial al aprender Django Ninja. Por eso dediqué dos artículos completos a comparar las diferencias entre ambos enfoques, permitiéndote comprender con mayor claridad la lógica y las consideraciones detrás de ello.
Capítulo 3, sección 3: respuestas HTTP#
Superficialmente se habla de respuestas HTTP, pero el enfoque real estuvo en la presentación de los Schema de Django Ninja, es decir, Pydantic BaseModel.
Decir que esta sección fue una «Introducción a Pydantic» no es para nada una exageración.
Además, la importancia de comprender Pydantic se extiende a capítulos posteriores como la documentación de API y la validación de datos. Es, por así decirlo, la base de todo.
Django Ninja utiliza Schema para organizar y serializar las respuestas HTTP, lo cual, en esencia, no difiere de los serializadores utilizados por Django REST framework.
Sin embargo, las diferencias en la mentalidad de uso entre ambos me brindaron una experiencia completamente distinta. Mis observaciones principales las he plasmado en el «Artículo 15: Respuestas (3) ¿Por qué no usar ModelSchema? — Las razones por las que prefiero Django Ninja frente a DRF», el cual vale la pena releer una y otra vez.
Capítulo 4: documentación de API#
¿Qué más se puede añadir? ¡Es absolutamente crucial!
De no existir la funcionalidad estrella de «generar automáticamente documentación de API según el código y las type hints», ¿cómo tendría la motivación un desarrollador acostumbrado a Django REST framework, como yo, para aprender un nuevo framework con una orientación similar?
¡La pereza es el motor de todo!
Capítulo 5: validación de datos y manejo de errores#
¡Este capítulo representó mi sangre y lágrimas! 😂
Las formas de validar datos y manejar errores en Django Ninja son muy diferentes a las de Django REST framework. Lo que me causó aún más dolor de cabeza fue que, en mis proyectos de trabajo anteriores, no lo implementaba de la manera «más ortodoxa», pues seguía influenciado por los hábitos de desarrollo en Django REST framework.
En aquel entonces llegué a pensar: «¡Esto es demasiado difícil de usar!» —cuando en realidad el equivocado era yo. Para redactar bien estos 4 artículos, tuve prácticamente que reaprender. Debo admitir que experimenté una gran sensación de revelación y claridad.
Por lo tanto, la forma de implementación que observas en esta serie debería ser un uso sumamente razonable e idiomático. Combinando la experiencia adquirida, ya he tropezado por ti en esos obstáculos, así que no te preocupes.
A continuación comparto mis reflexiones personales.
3. El mayor desafío en la redacción#
Considero que el mayor desafío durante la creación de toda la serie fue acompañar las publicaciones con el código del proyecto de GitHub en la medida de lo posible, proporcionando ejemplos adecuados y coherentes para cada artículo.
(De más está decir que este proyecto agradecerá enormemente «tus estrellas» 🌟).
Esto resultó mucho más laborioso que simplemente dar ejemplos aislados: tuve que planificar con anticipación el avance del contenido de toda la serie, pensando en cómo encajar la implementación de la API con el tema de cada entrega para generar una sensación de «inmersión».
Asimismo, debía considerar la coherencia narrativa: el código debía avanzar progresivamente de lo simple a lo complejo, y no al revés. Solo así los lectores podrían aprender de forma fluida junto con el proyecto.
Un diseño de este tipo requiere no solo conocimientos técnicos, sino principalmente una mentalidad pedagógica y empatía con el lector: saber en qué punto podrían «quedarse atascados».
En conjunto, fue un proceso sumamente desafiante pero también muy gratificante.
4. Mi valoración y expectativas sobre Django Ninja#
Django Ninja es un proyecto de código abierto mantenido por un solo desarrollador ucraniano, Vitaliy Kucheryaviy, por lo que la frecuencia de actualización no es alta y generalmente no puede responder de inmediato a las expectativas de los usuarios.
Sin embargo, me gustaría decir: «Si es posible, realmente no quisiera volver a escribir en Django REST framework».
La razón es una sola, como mencioné en el artículo 15: «Lo explícito es mejor que lo implícito» (Explicit is better than implicit).
Tal vez Django Ninja no haga que el desarrollo sea más «rápido», pero definitivamente es más transparente y controlable.
Tengo la certeza de que, a largo plazo, esta transparencia y control nos ahorrará un tiempo de depuración que no se compara simplemente con la velocidad.
Expectativas futuras#
A medida que el propio Django incrementa progresivamente su soporte para el procesamiento asíncrono (async), confío en que el potencial de Django Ninja se irá liberando de manera gradual.
Espero que, en un futuro cercano, cuando las personas hablen de «escribir API con Django», no piensen únicamente en Django REST framework, sino que también mencionen esta nueva y potente alternativa: Django Ninja.
5. Reflexiones al completar el desafío#
¡Uf! Por fin he terminado de escribir; este proceso fue mucho más extenso de lo que imaginaba.
Desde principios de septiembre hasta mediados de octubre, durante 40 días completos (incluyendo la preparación previa al inicio), me despertaba cada mañana enfocado en escribir, dedicándome de todo corazón a esta aventura. Finalmente, he entregado un trabajo del cual me siento satisfecho.
Desde mi punto de vista, la satisfacción de escribir radica en «aportar valor y ejercer influencia». Este valor no es solo para los lectores, sino también para el propio autor: a través de la creación de estos 30 artículos, mi comprensión sobre Django Ninja se ha enriquecido enormemente.
Espero que esta serie te aporte valor y te permita desenvolverte con mayor soltura en tus próximos viajes de desarrollo.
Cada experiencia de redacción es un aprendizaje, y cada aprendizaje es un crecimiento. Puede que esta serie haya llegado a su fin, pero nuestro camino como ingenieros de software está aún muy lejos de concluir.
Y, de ser posible, me encantaría que esta se convirtiera en la búsqueda de toda una vida.