Django + React: cuándo separarlos y cuándo no
Silvano Puccini
Full Stack Engineer
Hay una presión constante en el ecosistema web hacia la separación total: Django como API pura, React como SPA independiente. Es el stack moderno, el stack que aparece en los job posts, el stack que todos parecen usar.
El problema es que esa separación tiene un costo real, y en muchos proyectos no vale la pena pagarlo.
Performance
Qué ganás con Django + DRF + React separados
Seamos honestos sobre los beneficios reales:
- Equipos independientes: el frontend y el backend pueden deployar por separado y moverse a ritmos diferentes
- Flexibilidad de cliente: la misma API sirve para web, mobile y terceros
- Escalabilidad independiente: podés escalar el frontend y el backend por separado según la carga
Si tenés un equipo de 5+ personas o múltiples clientes consumiendo la misma API, la separación tiene sentido.
Qué pagás por esa separación
Lo que nadie menciona tanto:
CORS, autenticación y sesiones duplicadas — Tenés que manejar tokens JWT o sesiones cross-domain. No es difícil, pero es complejidad extra que no existía antes.
Dos deployments, dos pipelines, dos sistemas de monitoreo — Cuando algo falla en producción, ahora tenés que investigar en dos lugares.
Hydration y SEO — Si tu React es una SPA pura, perdés SEO by default. Si agregás SSR con Next.js, ahora tenés tres sistemas en juego.
Latencia de red entre servicios — Cada request del frontend hace al menos una llamada al backend. En Django monolítico, esa operación era local.
El caso que nadie quiere admitir
En FerrelonStock, el sistema de inventario que construí para una ferretería, empecé con Django + DRF + React. Era el stack que conocía, el que usaba en proyectos más grandes.
A los dos meses me di cuenta que estaba manteniendo dos codebases para un sistema que tenía un solo tipo de usuario (los operadores de la ferretería) y cero necesidad de API pública.
Migré el módulo de reportes a Django templates + HTMX. El resultado:
- El tiempo de carga de los reportes bajó porque dejé de pagar la latencia de la API
- Eliminé 400 líneas de serializers que no hacían nada interesante
- Las actualizaciones de UI en tiempo real (stock disponible) se manejaron con HTMX sin escribir JavaScript
El módulo de inventario en tiempo real, donde sí necesitaba interactividad compleja y estado del lado del cliente, siguió siendo React.
El criterio para decidir
No es una decisión binaria. Podés tener Django templates para las partes estáticas y React para las partes con interactividad real.
La pregunta es: ¿qué nivel de interactividad necesita esta parte del sistema?
| Necesidad | Tecnología |
|---|---|
| Formularios simples, tablas, reportes | Django templates + HTMX |
| Interactividad moderada, algunos estados | Alpine.js sobre templates |
| Estado complejo, tiempo real, múltiples vistas interconectadas | React |
| API pública o múltiples clientes | DRF + React o Next.js |
No hay respuesta universal. Hay contexto.
Lo que sí importa
La elección de stack importa menos que la consistencia. Un proyecto que mezcla Django templates, React components sin convención y jQuery en un tercer módulo es mucho más difícil de mantener que uno que usa un solo enfoque, aunque ese enfoque no sea el más moderno.
Elegí el stack más simple que resuelve el problema. Después escalá cuando el problema lo justifique.
Newsletter
¡No te pierdas! Mantenete cerca del radar.
Recibí semanalmente lo que estoy construyendo — artículos, recursos técnicos y reflexiones sobre el futuro del diseño digital. Sin spam, solo arquitectura.