Arquitectura hoy

Desde hace un tiempo, los microservicios parecen dominarlo todo, y con ellos, FastAPI en Python. La adopción de la nube como infraestructura en casi todas las empresas apunta en esa dirección. Sin embargo, la desventaja más obvia de este enfoque es la gestión y orquestación de dichos microservicios; hay que ser muy cuidadoso con las dependencias entre ellos para no “cruzar los cables”. Hay que tener a personas altamente capacitadas para mantener estas operaciones.

Dicho esto, los microservicios se han convertido en el estándar. Han surgido herramientas para facilitar su uso como contenedores, Kubernetes o Prometheus y ofrecen un montón de ventajas que pueden dejar atrás a una tecnología como Django. Es lento, o al menos en la superficie, en cambio FastAPI es rápido, tanto al procesar solicitudes como al desarrollar con él. Además, incluye tipado casi “gratis” (algo que a Python le viene muy bien, como lo necesitaba javascript) y cuenta con un sistema de dependencias sumamente robusto.

Por otra parte, Django existe desde 2005; es casi tan antiguo como Facebook. Se mantiene vigente gracias a una comunidad bien organizada y apasionada por el desarrollo web. En consecuencia, gran parte de los problemas habituales al programar para internet ya están pensados y resueltos. Viene con “baterías incluidas”, un término que hace referencia a que gran parte de tu solución ya está lista desde el inicio (autenticación, panel de administración, ORM, seguridad, plantillas y enrutamiento). El problema es que su filosofía no se alinea tanto con esta tendencia de los microservicios, puesto que proviene de una época donde brillaba el monolito, la aplicación como un todo centralizado y la orientación al servidor.

No obstante, Django tiene contras importantes. Se ve lento y, en su momento, no existía la posibilidad de hacer llamadas asíncronas (algo que hoy parecería una locura). En términos de escalabilidad puede quedarse atrás, incluso con su estructura de monolito modular y despliegue por apps. Además, Django tiene una forma de trabajo estricta y opinada. Puede resultar overkill para proyectos pequeños. Todo esto nos lleva a su curva de aprendizaje, la cual resulta más difícil que la de su alternativa.

Con esto dicho, me gustaría indagar más y analizar las diferentes dimensiones desde la perspectiva del negocio, que son las que finalmente nos llevarán a decidir entre una u otra herramienta.

Time To Market

Tenemos que tener clara la prioridad del negocio al lanzar el MVP: ¿En qué consiste el producto? ¿Requiere administrar usuarios, roles o algún tipo de gestión común? O, por el contrario, ¿es más importante la velocidad de ejecución de cada llamada en un servicio específico? Estas preguntas nos orientan. Si la solución requiere gestionar usuarios, contraseñas, moderar contenido o tener algún tipo de soporte administrativo, con FastAPI tendrás que construir todo esto desde cero y los tiempos van a aumentar significativamente.

En cambio, si necesitas sincronizarte con equipos de frontend o mobile, la fluidez te la entregará FastAPI. Su documentación interactiva y la rapidez para prototipar rutas listas para que el equipo de frontend las consuma, aceleran increíblemente los tiempos.

También es ideal para validar ideas e indagar en mercados con algún servicio tecnológico muy específico. Hablamos de algo tan conciso que la infraestructura robusta de Django solo entorpecería la tarea.

Presupuesto y Equipo

Sin equipo y sin presupuesto, Django brilla. Con muy poco, podemos hacer mucho. Y si a eso le sumas agentes de IA… en el mismo codebase y de forma prácticamente nativa. Un solo desarrollador puede manejar una gran solución, moviéndose desde la base de datos hasta la visualización y la interfaz.

Sin embargo, hay que recordar que el que mucho abarca, poco aprieta.

La historia cambia si tienes un área de desarrollo estructurada, con al menos un equipo dedicado puramente al frontend, varios desarrolladores y los recursos para invertir el tiempo que requiere volver a “inventar la rueda”. Aunque, digámoslo, será una rueda mucho más específica y veloz. Al fin y al cabo, si estamos compitiendo en la Fórmula 1, no te recomendaría manejar una camioneta.

Visión del producto

¿Estamos creando una plataforma pesada y centralizada, o un producto que será parte de un ecosistema de servicios? Si el valor del negocio reside en reglas enrevesadas y en la gestión de datos estructurados, lo más probable es que Django sea la dirección adecuada. En cambio, si el valor radica en la velocidad de procesamiento, la concurrencia y la independencia, quizás no lo sea. Hay que detenerse y pensar: ¿cómo veo esta solución en 2 o 3 años? A tener en cuenta:

• Complejidad relacional
• Centralización
• Especialización técnica
• Independencia de interfaces

Escalabilidad

A simple vista, esta pelea se reduce a sincrónico vs. asincrónico. FastAPI es async por defecto, y los microservicios crecen mucho mejor que los monolitos. Sin embargo, en la realidad, gigantes como Instagram, Pinterest y Patreon empezaron (y en gran medida siguen operando) con Django. Decir que Django no sirve para manejar grandes cantidades de usuarios simplemente no es cierto.

La verdadera pregunta es: ¿Ese tráfico masivo ocurre exactamente en el mismo instante? Si el desafío va más allá de solo “aguantar” a más usuarios y se centra en la interacción en tiempo real entre ellos (como un chat en vivo o un juego multijugador), FastAPI es la decisión correcta para que la arquitectura no se tambalee.

Agilidad

En estos términos, hace unos años Django era una estrella indiscutida; nos ahorraba mucho tiempo al permitirnos hacer más con menos código. Hoy, con agentes de IA escupiendo código como máquinas, esta característica de “baterías incluidas” pierde un poco de peso. Ahora podemos lograr lo mismo usando herramientas más pequeñas.

Sin embargo, Django ha evolucionado y ha encontrado un nuevo nicho de valor: la estandarización y el control del caos.

Es mucho más probable que un ingeniero poco experimentado levante un codebase caótico e inentendible usando una herramienta como FastAPI, que usando Django, ya que este último te indica paso a paso cómo estructurar las cosas. Muchos frameworks hacen esto (como Ruby on Rails o NestJS): te ponen “barandillas” para que no te salgas del carril. Escribir código con IA significa que hoy, más que nunca, debemos preocuparnos por la mantenibilidad y la deuda técnica.

KISS

Al final del día, para elegir correctamente podemos acotarlo a saber dónde estamos, quiénes somos y hacia dónde vamos.