Si quieres volver a aprender Django desde cero: un mapa de aprendizaje que comienza con HTTP

Si quieres volver a aprender Django desde cero: un mapa de aprendizaje que comienza con HTTP

Al llegar al final del año, es natural hacer una revisión de lo que ha pasado. Para mí, siempre surge una pregunta: ¿estoy realmente aprendiendo Django?

He trabajado con Django y Django REST Framework (DRF) durante varios años, pasando por proyectos grandes y pequeños. Ahora puedo decir con confianza:

“Sé dónde está cada pieza y cómo funciona; el panorama es mucho más claro que antes.”

Aún así, todavía me quedan dudas. Pero ahora puedo decirle a mi yo del pasado y a los desarrolladores que recién empiezan: “Si sigues este orden, no te perderás tanto.”

Este artículo es una guía personal sobre cómo empezar de nuevo con Django. Quiero que sirva como un punto de referencia útil, tanto si lo lees al final del año como en cualquier otro momento.

1. Django, en última instancia, es un framework que maneja HTTP

Puede parecer obvio, pero al principio de aprender Django, a menudo olvidamos este hecho.

Django, ya sea que renderice una interfaz de usuario o devuelva solo JSON, se reduce a recibir una solicitud HTTP y devolver una respuesta HTTP.

• El cliente (navegador, aplicación, otro servidor) envía una solicitud HTTP.
• Django la recibe y la procesa.
• Devuelve una respuesta HTTP (HTML, JSON, archivo, error, etc.).

Los componentes que solemos asociar con Django son:

• URLConf
• View (FBV/CBV)
• Template
• ORM
• Middleware
• Autenticación / Permisos
• Serializer, ViewSet, Router de DRF…

Todo esto es simplemente una herramienta para recibir, procesar y devolver solicitudes HTTP.

Si pierdes esta perspectiva al comenzar, el framework pronto se vuelve un "caja mágica".

“Si lo uso de esta manera, funciona… pero no entiendo por qué.”

Con el tiempo, te quedarás atrapado en el framework.

2. Antes de las funciones brillantes, entiende por qué se hacen

Al aprender Django, a menudo te encuentras con características como:

• Registro/Inicio de sesión, login social
• Gestión de permisos
• Configuración de caché
• Tareas asíncronas (Celery, etc.)
• Diversos middlewares y ajustes

Estas son funciones útiles, pero el problema surge cuando las abordas demasiado pronto.

Surge la pregunta:

“¿Por qué se hace de esta manera?”

Si no puedes responderla, construirás código que:

• Deja un sentimiento de incompletitud incluso después de arreglar errores.
• Se vuelve difícil de refactorizar.
• Se basa en soluciones copiadas de Google sin comprenderlas.

Mi consejo para mí mismo y para los que están empezando: Primero entiende el flujo de HTTP y el funcionamiento de la web.

3. Entender el flujo HTTP te permite ver más allá de Django

Para manejar Django de forma transparente, no puedes evitar comprender el flujo básico del protocolo HTTP.

Al menos, deberías experimentar con:

• ¿Qué estructura tiene una solicitud?
• URL, método (GET/POST/PUT/DELETE…), encabezados, query string, cuerpo.
• ¿Qué determina la respuesta?
• Código de estado (200/400/404/500…), encabezados, cuerpo (JSON/HTML, etc.).
• ¿Qué caché maneja el navegador y qué debe cuidar el servidor?

Un ejemplo sencillo: envía una solicitud desde la terminal.

curl -X GET "http://localhost:8000/articles/1/" -H "Accept: application/json"

Esta solicitud contiene todo lo esencial de HTTP:

• URL: /articles/1/
• Método: GET
• Encabezado: Accept: application/json
• Tipo de respuesta deseado: JSON

Al visualizar este flujo, también empiezas a comprender:

• Por qué nginx proxya ciertas rutas a Django.
• El papel de servidores WSGI como gunicorn/uWSGI.
• Qué responsabilidades recae en Django y qué en otras capas.

Cuando llegas a este punto, Django deja de ser un "misterio". Comprendes que la estructura que ves es necesaria para manejar solicitudes HTTP.

4. El primer proyecto: simple y con FBV

Para principiantes, recomiendo comenzar con un proyecto intencionalmente sencillo y con Function-Based Views (FBV).

Condiciones ideales:

• Implementación mínima de autenticación/permiso.
• Estructura sin complejidad administrativa.
• Modelos simples (por ejemplo, artículos y comentarios).
• Funcionalidades que permitan sentir el flujo de trabajo.

Ejemplo: una vista FBV que devuelve un artículo en JSON.

# views.py
from django.http import JsonResponse
from .models import Article

def article_detail(request, pk):
    article = Article.objects.get(pk=pk)
    data = {
        "id": article.id,
        "title": article.title,
        "content": article.content,
    }
    return JsonResponse(data)

En esta vista se incluyen los pasos clave:

1. Recibe el objeto request.
2. Busca el artículo con el pk recibido.
3. Construye un diccionario.
4. Lo envuelve en una respuesta JSON.

Al depurar línea por línea, puedes observar:

• Cómo URLConf conecta la URL con la vista.
• Qué información contiene request.
• Qué SQL ejecuta el ORM.
• Cómo se convierte la respuesta en JSON.

Dominar el ORM en esta etapa es una inversión valiosa para cualquier proyecto futuro.

5. Luego, avanza rápidamente a CBV y DRF

Una vez que domines el flujo HTTP–View–ORM–Response con FBV, es hora de pasar a CBV y DRF sin dudar.

El verdadero poder de Django y la comodidad de DRF se sienten aquí.

CBV y DRF ofrecen:

• Reducción de patrones repetitivos.
• Consistencia en todo el proyecto.
• Responsabilidades claras.
• Diseño extensible con URL/Serializer/ViewSet/Permission.

Ejemplo de la misma funcionalidad con DRF:

# views.py (DRF)
from rest_framework.viewsets import ReadOnlyModelViewSet
from .models import Article
from .serializers import ArticleSerializer

class ArticleViewSet(ReadOnlyModelViewSet):
    queryset = Article.objects.all()
    serializer_class = ArticleSerializer

Y solo registras el router:

# urls.py
from rest_framework.routers import DefaultRouter
from .views import ArticleViewSet

router = DefaultRouter()
router.register(r'articles', ArticleViewSet, basename='article')

urlpatterns = router.urls

Ahora tienes automáticamente:

• /articles/
• /articles/{id}/

Si ya comprendes el flujo HTTP, verás que CBV/DRF simplemente abstrae ese flujo en clases.

“Dentro de esta abstracción sigue el mismo flujo HTTP/Respuesta.”

Esta perspectiva es crucial. Si lo ves como una sintaxis que debes memorizar, te perderás. Si lo ves como una herramienta que encapsula lo que ya conoces, lo asimilarás mucho más rápido.

6. Resumen del orden de aprendizaje

Para mí y para los que están empezando, recomiendo el siguiente camino:

1. Comprender la web y HTTP - Flujo de solicitud/respuesta. - Métodos, códigos de estado, encabezados, cookies, sesiones. - Práctica con curl o Postman.
2. Fundamentos de Django con FBV - URLConf → View → Template → ORM. - Proyecto pequeño sin autenticación. - CRUD con ORM.
3. Profundizar en ORM y Admin - Relaciones, optimización de consultas. - Gestión de datos vía Admin.
4. Migrar a CBV - Vistas genéricas, mixins, herencia.
5. Crear una API con DRF - Serializers, ViewSets, Routers, permisos, autenticación.
6. Añadir funcionalidades avanzadas - Autenticación/permiso, throttling, paginación, filtros. - Caché, tareas asíncronas, despliegue, escalado.

El objetivo es que, en cada etapa, puedas explicar por qué haces algo, no solo qué haces.

7. Conclusión: no memorices el framework, entiende la web

Para terminar, quiero dejar esta frase para mí y para los que están empezando:

No memorices el framework; entiende cómo funciona la web.

Django es solo una herramienta que facilita esa comprensión.

Si mantienes esta perspectiva, podrás:

• Adaptarte a nuevas versiones de Django.
• Transicionar a otros frameworks (Flask, FastAPI, Node, Spring, etc.).
• Enfrentar nuevas arquitecturas y entornos en la nube.

Siempre podrás preguntar:

• “¿Cómo maneja HTTP este sistema?”
• “¿Qué capa es responsable de qué?”
• “¿Qué patrón de solicitud/respuesta está oculto?”

Con esa base, no te quedarás atado a un solo framework y crecerás como desarrollador web sólido y adaptable.