Django vs FastAPI en Cloudflare Workers: cuál elegir

Django vs FastAPI en Cloudflare Workers: ¿cuál conviene?

Django es la mejor elección cuando ya existe una aplicación Django o se necesita un backend de producto completo. FastAPI encaja mejor al crear desde cero una API tipada, un servicio de webhooks o un endpoint en el edge con mucha E/S. Conviene mantener la aplicación en su origen actual si algún paquete imprescindible, el modelo de procesos o una carga con estado quedan fuera de lo que admite el entorno de Workers.

Cloudflare cambió el punto de partida el 2 de septiembre de 2026. Los Python Workers ya pueden alojar aplicaciones WSGI y ASGI directamente mediante adaptadores del módulo workers. WSGI es el contrato web síncrono tradicional de Python. ASGI es su sucesor asíncrono, pensado para solapar operaciones de E/S, hacer streaming y mantener conexiones de larga duración. Los ejemplos publicados por Cloudflare vinculan expresamente Django con WSGI y FastAPI con ASGI, aunque Django puede usar cualquiera de los dos protocolos.

Django ofrece la migración más segura cuando su conjunto integrado de funciones ya aporta valor al producto. Cloudflare documenta ahora puntos de entrada tanto para WSGI como para ASGI, además de una ruta mediante django-cf para D1 y Durable Objects.

FastAPI es la opción más limpia para un proyecto nuevo cuando el resultado debe ser una API y no un producto web respaldado por un panel de administración. Cloudflare aporta la capa de servidor ASGI, por lo que el Worker no necesita ejecutar Uvicorn ni administrar un socket.

El empate de precio solo se rompe si cambia el uso de CPU

Ningún framework tiene ventaja de precio. Los precios se verificaron el 5 de septiembre de 2026 en páginas oficiales activas: Django es gratuito y de código abierto bajo su licencia BSD, FastAPI usa la licencia MIT y Workers Paid comienza en $5 por cuenta al mes.

Esos $5 incluyen 10 millones de solicitudes y 30 millones de milisegundos de CPU al mes. Las solicitudes adicionales cuestan $0.30 por millón y la CPU adicional, $0.02 por cada millón de milisegundos. Las solicitudes de Static Assets son gratuitas e ilimitadas. Workers Free incluye 100,000 solicitudes diarias, pero sus 10 ms de CPU por invocación lo convierten en una referencia poco adecuada para comparar aplicaciones complejas basadas en estos frameworks.

Al normalizar ambos frameworks con la misma carga, el resultado es deliberadamente poco sorprendente. Con 15 millones de solicitudes dinámicas al mes y un promedio de 7 ms de CPU por solicitud, cualquiera cuesta $8 al mes: $5 de base, $1.50 por exceso de solicitudes y $1.50 por exceso de CPU. Con 100 millones de solicitudes y el mismo promedio de 7 ms, cualquiera cuesta $45.40 al mes.

El cálculo de sensibilidad resulta más útil que un benchmark inventado entre frameworks. Una vez agotado el cupo de CPU incluido en ambas aplicaciones, cada diferencia de 1 ms en el promedio de CPU modifica la factura en $0.30 con 15 millones de solicitudes y en $2 con 100 millones. Por tanto, una brecha medida de 5 ms equivale a $1.50 o $10 al mes en esos niveles de tráfico. Es una diferencia demasiado pequeña para justificar la reescritura de un framework solo por el costo de cómputo.

No existe un punto de cruce en el precio del proveedor. Una opción solo pasa a ser más barata cuando difieren el tiempo de CPU medido, los servicios auxiliares o la carga de mantenimiento. Un framework rápido alrededor de consultas lentas a la base de datos no salvará la arquitectura; a la vez, un framework integrado que evita semanas de trabajo de sustitución puede ser el sistema más económico, aunque un microbenchmark favorezca al otro.

Migración: Django gana en sistemas existentes y FastAPI en APIs nuevas

El cambio de adaptador es pequeño; la migración de la aplicación no. Ambos frameworks solo necesitan un punto de entrada mínimo, pero todo lo que hay detrás debe respetar el modelo de paquetes, almacenamiento, sistema de archivos y ciclo de vida de Cloudflare.

Migrar Django a Cloudflare Workers: el adaptador es lo fácil

Django puede conservar su objeto de aplicación WSGI estándar y entregarlo al adaptador de Cloudflare:

import os

from django.core.wsgi import get_wsgi_application
from workers import wsgi

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
app = get_wsgi_application()
Default = wsgi.entrypoint(app)

Esto basta para convertir una solicitud entrante de Workers en una llamada WSGI de Django. No migra la base de datos, los archivos persistentes, las tareas programadas, la estrategia de sesiones ni todos los paquetes de terceros para Django.

La nueva guía del paquete Django de Cloudflare ofrece una ruta de almacenamiento realmente nativa para el framework. El paquete django-cf aporta backends compatibles con SQLite para D1 y Durable Objects. Ambos alimentan el ORM síncrono de Django, por lo que Cloudflare indica que esta configuración debe servirse mediante WSGI. En un producto CRUD que ya depende de modelos, formularios, autenticación y panel de administración, conservar esas capas puede ahorrar mucho más trabajo del que un cambio de framework reduciría en costos de ejecución.

El límite aparece cuando el sistema existente presupone un servidor convencional. Un controlador de base de datos puede necesitar un wheel nativo que Workers no puede cargar. Los archivos subidos por usuarios no pueden residir en el sistema de archivos del isolate. Tampoco se pueden trasladar tal cual un planificador local del proceso ni un pool de hilos. Que Django sea compatible significa que funciona el protocolo de solicitudes; no certifica toda la aplicación instalada.

Migrar FastAPI a Cloudflare Workers: ideal para un servicio acotado

El adaptador directo de FastAPI es más pequeño porque el framework ya habla ASGI:

from fastapi import FastAPI
from workers import asgi

app = FastAPI()
Default = asgi.entrypoint(app)

Cloudflare asume el papel de servidor ASGI que normalmente desempeña Uvicorn. FastAPI conserva sus declaraciones de rutas, la validación con Pydantic, la inyección de dependencias y la documentación OpenAPI generada. Por eso, un receptor de webhooks nuevo, una API JSON tipada o un servicio respaldado por bindings comienza con menos maquinaria de aplicación que Django.

La contrapartida es el trabajo de ensamblaje. FastAPI no prescribe una base de datos ni un modelo de datos. Tampoco incluye el panel de contenidos de Django. Hay que elegir esas piezas, comprobar cada paquete en el entorno de Workers y hacerse cargo de la integración. Eso es una ventaja para un servicio específico y un costo para un producto cuyos operadores necesitan un back office desde el primer día.

Ganador en migración: Django para una aplicación que ya utiliza Django; FastAPI para una API nueva. Reescribir en FastAPI un sistema Django que funciona, solo porque ambos pueden ejecutarse ahora en el edge, es emprender el proyecto equivocado.

WSGI vs ASGI en Cloudflare Workers: FastAPI gana en concurrencia

ASGI ofrece el modelo de solicitudes más sólido para un servicio nuevo con mucha E/S, pero WSGI es la ruta documentada para integrar el ORM de Django con Cloudflare. El protocolo debe seguir a la carga de trabajo, no a la afirmación genérica de que lo asíncrono siempre es más rápido.

WSGI presenta la aplicación como una función síncrona. El adaptador WSGI actual de Cloudflare ejecuta esa función dentro del controlador asíncrono fetch del Worker, conecta el cuerpo de la solicitud desde un ReadableStream de JavaScript y transmite al cliente el iterable de respuesta de la aplicación. Es una ruta de compatibilidad para aplicaciones síncronas maduras, no un segundo servidor web dentro del isolate.

ASGI permite que la aplicación espere operaciones de red y almacenamiento sin retener la ruta de la solicitud en una llamada síncrona. El adaptador de Cloudflare también convierte los eventos WebSocket de ASGI en WebSockets de Workers. FastAPI está construido sobre ese modelo. Django también puede usarlo, así que «Django» y «WSGI» no son sinónimos.

La elección del almacenamiento puede invertir la decisión sobre el protocolo. Cloudflare indica que sus backends D1 y Durable Objects para Django alimentan el ORM síncrono y deben servirse mediante WSGI. Si el motivo para elegir Django es su ORM, seguir esa ruta WSGI documentada resulta más coherente que imponer la etiqueta ASGI a una capa de datos síncrona.

En FastAPI, el enfoque asíncrono solo ayuda cuando el trabajo puede solaparse. Un endpoint que dedica casi todo su tiempo a validaciones secuenciales o a Python con uso intensivo de CPU seguirá consumiendo CPU. Un endpoint que espera varias operaciones HTTP independientes o bindings de Cloudflare tiene un motivo más claro para usar ASGI.

Comportamiento al arrancar: la sorpresa del lifespan de FastAPI

Django sobre WSGI ofrece actualmente el modelo de arranque más predecible en Workers. FastAPI sigue funcionando, pero sus hooks de lifespan no se comportan como en un proceso Uvicorn de larga duración.

Cloudflare reduce el trabajo de arranque en frío de Python mediante snapshots de despliegue. Durante el despliegue, la plataforma crea un isolate de V8, inyecta Pyodide, ejecuta el módulo de entrada del Worker y sus importaciones globales, y después captura una instantánea de la memoria WebAssembly. Una solicitud puede cargar esa instantánea en vez de reconstruir desde cero el entorno de Python. Aun así, el código de ámbito global debe analizarse y ejecutarse dentro del límite de arranque de 1 segundo de la plataforma. Cloudflare documenta ese ciclo de vida.

El contrato habitual de lifespan de FastAPI está pensado alrededor de un proceso: el código de inicio se ejecuta una vez antes de que la aplicación acepte solicitudes y el de cierre, una vez cuando termina. El código fuente del adaptador ASGI actual de Cloudflare hace algo sustancialmente distinto. Su función fetch inicia la aplicación ASGI, envía un evento de inicio del lifespan, atiende una solicitud y luego envía el evento de cierre. El comentario en el código describe un ciclo de inicio y cierre antes y después de la solicitud.

Con el adaptador actual, el código de lifespan queda así vinculado a cada solicitud. Cargar un modelo, crear un pool de conexiones, preparar un esquema u obtener una configuración remota en ese punto puede repetirse en lugar de amortizarse durante la vida de un isolate. No es una razón para descartar FastAPI. Sí lo es para mantener ese trabajo ligero e idempotente y trasladar la inicialización determinista y segura a código que pueda aprovechar el snapshot de despliegue de Cloudflare.

En el ejemplo de Cloudflare, la aplicación WSGI de Django se crea en el ámbito del módulo y no tiene un ciclo de lifespan de ASGI. Su inicialización forma parte de la ruta de arranque global, por lo que el límite es el techo de 1 segundo. Si se elige el punto de entrada ASGI de Django y se usan componentes con lifespan, deben auditarse bajo el mismo comportamiento del adaptador.

Cloudflare Workers con Python: el mismo límite de paquetes

En esta categoría hay un empate que puede descalificar a ambos frameworks. Django y FastAPI se ejecutan en el mismo entorno Pyodide dentro de V8, así que ninguno evita los límites de paquetes, memoria, sistema de archivos o arranque.

La documentación de paquetes de Cloudflare indica que pywrangler empaqueta las dependencias declaradas en pyproject.toml. Las fuentes compatibles incluyen paquetes de Python puro y PyEmscripten alojados en PyPI, además de los paquetes distribuidos con Pyodide. PyEmscripten es el formato wheel orientado a WebAssembly. Cloudflare todavía describe ese ecosistema como incipiente, y algunos paquetes no tienen un wheel compatible.

Las comprobaciones estrictas de la plataforma son claras:

• El bundle sin comprimir del Worker no puede superar 64 MiB ni en Free ni en Paid.
• Cada isolate dispone de 128 MB de memoria.
• El arranque en el ámbito global debe terminar en 1 segundo.
• El sistema de archivos de Python es efímero y privado para cada isolate.
• threading y multiprocessing se pueden importar, pero no funcionan en la máquina virtual WebAssembly.

El sistema de archivos frustra más migraciones de lo que sugiere la firma del adaptador. Los archivos temporales no presentan problemas. Los archivos subidos que deban persistir, los informes generados, los archivos SQLite usados como estado duradero y las cachés compartidas en disco no pueden vivir allí. Los objetos duraderos deben almacenarse en D1, Durable Objects, KV o R2 según el patrón de acceso, no en un directorio que desaparece con el isolate. Los límites exactos están en la guía de la biblioteca estándar de Python de Cloudflare.

La compatibilidad de paquetes es una condición binaria antes de que interese el rendimiento. Construye el grafo de dependencias real, no un subconjunto de ejemplo. Poder importar un paquete en CPython de escritorio no demuestra nada sobre la disponibilidad de sus extensiones nativas en Pyodide.

Encaje operativo: Django gana en productos y FastAPI en servicios

Django gana cuando la unidad de trabajo es un producto; FastAPI, cuando es un servicio. Esta diferencia resulta más duradera que el rendimiento de cada framework en una ruta sintética.

Ganador para un producto con panel de administración: Django

Django incluye autenticación de usuarios, administración de contenidos, ORM, plantillas, middleware y otras funciones habituales de los productos web. Su presentación oficial destaca expresamente la autenticación y la administración de contenidos. Si un equipo de operaciones pequeño debe gestionar clientes, pedidos, permisos y registros editoriales, el panel integrado puede aportar más valor que reducir unos milisegundos la sobrecarga del framework.

En Workers, django-cf ofrece a ese modelo integrado una ruta hacia D1 o Durable Objects. A cambio, aumenta el acoplamiento con un ORM síncrono y obliga a encajar una superficie de framework mayor dentro de los límites del entorno.

Ganador para un servicio de API tipada: FastAPI

FastAPI se articula alrededor de OpenAPI, JSON Schema, la validación de Pydantic y la inyección de dependencias. Su documentación de funcionalidades también deja clara la contrapartida: la base de datos y el modelo de datos quedan a elección del equipo. Es la forma adecuada para una puerta de enlace de API, un receptor de webhooks, un endpoint de modelos o un servicio pequeño que se comunica con bindings y APIs remotas.

La falta de un panel de administración y un ORM integrados no es un defecto si el servicio no los necesita. Pasa a ser un costo de entrega en cuanto un operador no técnico requiere un back office.

Ganador en velocidad bruta: no está demostrado en Workers

La suite independiente TechEmpower situó históricamente a FastAPI bajo Uvicorn entre los frameworks de Python más rápidos, según la página de benchmarks de FastAPI. TechEmpower midió cargas estandarizadas de JSON, bases de datos, ORM, plantillas y categorías relacionadas. No midió los adaptadores Pyodide de Cloudflare, y el proyecto cerró el 24 de marzo de 2026. Esos resultados constituyen una señal histórica atribuida, no un pronóstico para un despliegue en Workers.

Cloudflare no ha publicado un benchmark de Django frente a FastAPI con estos adaptadores. Por tanto, la velocidad bruta en Workers sigue sin demostrarse hasta que una ruta representativa incluya su validación, bindings, consultas a la base de datos, formato de respuesta, comportamiento al arrancar y métricas de CPU de Workers.

El costo real de cambiar y quién no debería hacerlo

No cambies de framework solo para obtener compatibilidad con Cloudflare. Ambos la tienen ahora. El cambio solo se justifica cuando el framework de destino elimina más trabajo de aplicación del que crea la migración.

Reescribir Django en FastAPI implica reemplazar o separar modelos, migraciones, pantallas de administración, flujos de autenticación, middleware, plantillas y cualquier paquete que dependa del ciclo de solicitudes de Django. El resultado puede ser excelente para una API acotada, pero no se trata de una opción de despliegue. Si el panel y el ORM tienen un uso intensivo, el cambio destruye ventajas antes de generarlas.

Pasar de FastAPI a Django solo tiene sentido cuando el producto ha superado una arquitectura orientada a servicios y necesita la superficie operativa integrada de Django. De lo contrario, añade convenciones y componentes innecesarios para una API pequeña.

FastAPI puede montar una aplicación WSGI de Django bajo una ruta mediante a2wsgi.WSGIMiddleware. Esto permite una separación por etapas en servidores convencionales. En Workers añade otro paquete y otra frontera de protocolo, mientras que las guías de inicio de Cloudflare documentan cada framework por separado. Considera un Worker combinado como una integración personalizada que debe probarse, no como el atajo predeterminado.

Sea cual sea la dirección, hay que estimar estas áreas de la migración:

• Datos: compatibilidad del esquema, migraciones, comportamiento de transacciones y traslado a D1, Durable Objects u otro almacén accesible.
• Archivos: los recursos estáticos pueden usar Workers Static Assets, mientras que los archivos persistentes de usuarios requieren almacenamiento duradero de objetos como R2.
• Trabajo en segundo plano: sustituye los planificadores locales del proceso, los pools de hilos y los procesos secundarios por trabajo asíncrono nativo de la plataforma.
• Dependencias: resuelve el lockfile completo en Python Workers y después revisa el bundle de 64 MiB y el resultado de arranque de 1 segundo.
• Operaciones: reconstruye los registros, las alertas de errores, la reversión de despliegues, los secretos y una línea base de rendimiento por ruta.

¿Quién no debería cambiar? Un monolito Django estable, con una base de datos funcional y flujos importantes en el panel de administración, no debería convertirse a FastAPI por moda. Un servicio FastAPI que depende de wheels nativos no disponibles no debería trasladarse a Workers solo porque el framework ya tiene una página en la documentación. Un equipo cuya latencia proviene sobre todo de una base de datos lejana debería corregir primero la ubicación de los datos y después evaluar el framework de solicitudes.

Qué hacer el lunes

La próxima semana, prueba una ruta representativa en lugar de migrar toda la aplicación. Elige la ruta que reúna las características de paquetes, estado y latencia del sistema de producción, y úsala para descartar pronto las opciones equivocadas.

Preguntas frecuentes sobre Django y FastAPI en Cloudflare Workers