FastAPI o Django: más peticiones no sustituyen ORM y transacciones

Para una API ligera centrada en recibir, validar y devolver datos, FastAPI suele ser la elección más directa. Si el proyecto también necesita gestionar entidades y dar acceso al personal, Django puede ahorrar trabajo: su ORM y administración basada en modelos permiten consultar relaciones y gestionar registros desde una interfaz para usuarios autorizados. Esa diferencia de alcance importa tanto como la velocidad HTTP.

FastAPI concentra sus herramientas integradas en el contrato de la API. Su documentación de funciones describe validación con Pydantic, esquemas OpenAPI y JSON Schema, documentación interactiva e inyección de dependencias. La elección depende de cuánto trabajo habrá alrededor de las rutas: persistencia, acceso del personal y operaciones que deben completarse juntas.

Qué mide la ventaja en peticiones por segundo

En el endpoint «ping» sobre x86, el repositorio del benchmark registra 27.898 peticiones por segundo para FastAPI, 3.227 para Django con middleware predeterminado y 8.115 para Django sin ese middleware; todas las variantes se sirvieron con Uvicorn. Son resultados de esas configuraciones y de esa carga, no una tasa de respuesta garantizada para cualquier aplicación construida con cada framework.

La variación entre las dos configuraciones de Django muestra cuánto influye el recorrido de una petición antes de llegar a la vista. En un «ping», ese recorrido pesa relativamente más porque la ruta hace muy poco trabajo. Si una operación consulta varias tablas, valida reglas de negocio o escribe en la base de datos, esas tareas cambian la composición del tiempo de respuesta y pueden reducir la importancia relativa del coste HTTP.

El ensayo permite afirmar que FastAPI atendió más peticiones en esa prueba mínima. No permite convertir la diferencia en horas de desarrollo ahorradas ni predecir la latencia de una ruta con autenticación y datos. Para estimar capacidad en un proyecto concreto, la comparación útil reproduce su middleware, sus consultas y la concurrencia prevista; el número de un endpoint vacío solo describe una parte de ese recorrido.

Cuándo una API ligera favorece a FastAPI

FastAPI resulta cómodo cuando las entradas y salidas HTTP son el centro del servicio. Las declaraciones de tipos alimentan la validación y la descripción de las operaciones, mientras que las dependencias permiten compartir lógica entre rutas. Para un servicio que expone funciones delimitadas a otros sistemas, esas piezas evitan construir desde cero una parte importante del contrato público.

La capa de datos sigue siendo una decisión del proyecto. La guía de bases de datos de FastAPI usa SQLModel como ejemplo y permite elegir otras bibliotecas SQL o NoSQL. Esa libertad encaja cuando ya existe una estrategia de persistencia o cuando el servicio necesita una integración particular; también exige decidir cómo organizar modelos, sesiones y operaciones sobre los datos.

Por ejemplo, en un caso hipotético donde la identidad y la gestión de registros ya estén resueltas por otros sistemas, añadir una administración propia aportaría poco al servicio. Si más adelante el mismo equipo debe mantener usuarios, permisos internos y edición de entidades, tendrá que incorporar esas capacidades. El coste relevante no es solo escribir una ruta, sino sostener las piezas que permiten usarla dentro del producto.

Qué aporta el panel administrativo de Django

El ORM de Django vincula clases y relaciones con las consultas a la base de datos. Su ejemplo de documentación relaciona un modelo Article con Reporter y muestra consultas que recorren esa relación. Al registrar Article en la administración, el personal autorizado puede añadir, modificar y eliminar registros. Para una aplicación que necesita gestionar las mismas entidades que consulta, esa continuidad evita elegir e integrar un panel independiente desde el principio.

El ahorro es especialmente visible en un panel interno cuyo trabajo consiste en localizar objetos, editar campos y mantener relaciones. Una aplicación editorial, por ejemplo, puede necesitar administrar artículos y sus autores antes de diseñar la experiencia pública. El modelo ya ofrece una estructura para ambas tareas, aunque las reglas específicas de publicación, revisión o permisos siguen requiriendo decisiones del equipo.

El panel administrativo tiene un alcance concreto: está orientado a gestionar modelos. Si el personal necesita un proceso guiado que combine decisiones, pasos y controles propios del negocio, probablemente harán falta vistas adicionales. Contar la administración como una solución completa para cualquier flujo inflaría el ahorro esperado; ignorarla en un proyecto basado en registros también distorsionaría la comparación.

El monolito transaccional cambia el cálculo

Cuando una operación modifica varias entidades que deben quedar coherentes entre sí, la transacción forma parte del comportamiento del producto. Pensemos en un caso hipotético: registrar un pedido y descontar existencias como una sola operación. La rapidez con que una ruta responde «ping» no dice cuánto tardará ese trabajo ni cómo se mantendrá la coherencia de los datos si una escritura falla.

En ese tipo de aplicación, el valor de Django está en reunir modelos relacionados, acceso a datos y administración dentro de un mismo proyecto. FastAPI puede participar en un sistema con base de datos y transacciones, pero el equipo debe escoger y conectar las bibliotecas correspondientes. La comparación de esfuerzo pasa entonces por el alcance que hay que entregar: rutas públicas, gestión interna, acceso de usuarios y reglas de escritura.

Esto tampoco convierte a Django en la opción automática para todo servicio con datos. Una API que utiliza una capa de persistencia ya establecida puede beneficiarse más de la flexibilidad de FastAPI. Lo decisivo es identificar qué componentes existen y cuáles deberá construir o mantener el equipo, además de medir la carga que recibirán.

ASGI y el límite de las transacciones asíncronas

Django admite vistas asíncronas y consultas asíncronas del ORM, pero sus reglas de ejecución asíncrona indican que las transacciones todavía deben agruparse en una función síncrona y llamarse mediante sync_to_async(). Declarar una vista con async def no convierte automáticamente en asíncrona una operación transaccional sobre varios registros.

La ejecución asíncrona puede aportar valor cuando una petición espera servicios externos o mantiene una respuesta abierta durante más tiempo. Para obtener una pila asíncrona de extremo a extremo en Django hace falta ejecutarlo bajo ASGI y contar con middleware compatible. Si una pieza de middleware es síncrona, Django adapta su ejecución y mantiene un hilo para ese tramo; esa condición afecta especialmente a servicios que buscan sostener muchas peticiones concurrentes mientras esperan operaciones externas.

El caso transaccional pide una lectura distinta: conviene delimitar el bloque síncrono que mantiene juntas las escrituras y observar también el coste de la base de datos. ASGI describe cómo se atienden las conexiones, pero no elimina las consultas ni las reglas de coherencia. Por eso una necesidad real de concurrencia asíncrona y una necesidad real de transacciones pueden coexistir en el mismo proyecto sin resolverse con una sola cifra de throughput.

La elección según el producto que hay que entregar

Si el resultado esperado es una API pequeña, con consumidores definidos y persistencia limitada o ya resuelta, FastAPI concentra el esfuerzo en el contrato HTTP. Si el producto incluye un panel para personal autorizado y numerosas entidades relacionadas, Django ofrece una base integrada que puede reducir el trabajo de ensamblaje. Para un monolito con escrituras coordinadas, la organización de los modelos y las transacciones merece más peso que la velocidad de una ruta mínima.

La necesidad de esperar muchas respuestas externas puede favorecer el uso de vistas asíncronas en cualquiera de las arquitecturas que las admita, con las restricciones propias de sus componentes. La decisión se vuelve más precisa al presupuestar las funciones que faltan y medir una operación parecida a la que atenderá el servicio: así se comparan tanto el coste de construirlo como el de ejecutarlo.

Lee también:

• Patrocinio en YouTube: marcar la casilla no sustituye un aviso visible
• NetSPI y Synack se fusionan: la IA no sustituirá a sus hackers humanos
• Cancelar un CFDI 4.0: elegir mal el motivo complica la sustitución