Elegir un runtime backend no es una competición de popularidad entre lenguajes. Un endpoint en el edge, un servicio Node de larga duración y una API Python sirven HTTP, pero implican distintas responsabilidades de despliegue, ecosistemas, recursos y modos de fallo. La pregunta útil es qué restricciones tiene realmente tu carga.
| Dimensión | Cloudflare Workers | Servidor Node.js | Servicio FastAPI |
|---|---|---|---|
| Modelo de ejecución | Handlers de peticiones y eventos en una plataforma basada en isolates | Proceso JavaScript persistente, a menudo en contenedor | Aplicación ASGI atendida por servidor ASGI, normalmente en contenedor |
| Ajuste principal | Edge, APIs ligeras, webhooks y lógica junto a la caché | APIs persistentes, paquetes Node, WebSockets y control de procesos | APIs Python, datos, automatización y bibliotecas del ecosistema |
| Operación | La plataforma gestiona gran parte de la flota; tú cuidas bindings, límites y datos | Configurar salud, réplicas, reinicios, runtime y capacidad | Configurar workers, arranque, memoria, HTTPS y capacidad |
| Vigilar | CPU, memoria, compatibilidad y límites de plataforma | Bloqueos del event loop, memoria y topología | Número de procesos, trabajo bloqueante y límites async |
| Estado y tareas largas | Almacenamiento, colas o coordinación explícitos | Usar almacenes y workers externos; la memoria no es durable | Usar almacenes y colas externos; el proceso API no es una cola de jobs |
Un runtime edge reduce distancia para autorización, enrutamiento, caché y transformaciones pequeñas. Resulta atractivo si el código es sobre todo I/O de red y puede usar los servicios disponibles. No hace compatible cualquier dependencia ni elimina límites. Comprueba CPU, memoria, tamaño del cuerpo y subrequests vigentes frente a la carga real; el cómputo pesado y los trabajos largos requieren sistemas preparados.
Un servidor Node ofrece procesos familiares y un ecosistema amplio. Encaja si la aplicación necesita conexiones persistentes, dependencias nativas, trabajos largos o un entorno controlado. Esa libertad implica configurar health checks, supervisión, despliegues, capacidad, logs y protección frente a callbacks que bloqueen el event loop. La sintaxis asíncrona no hace gratis el trabajo síncrono o intensivo en CPU.
FastAPI aporta tipado y validación de Python sobre una aplicación ASGI. Es natural cuando la API está cerca de código de datos, automatización o machine learning. El despliegue aún necesita servidor ASGI, terminación HTTPS, reinicios, réplicas, memoria y dependencias. La inferencia costosa quizá requiera workers separados o servicio con acelerador, en vez de ocupar procesos de petición.
Incluye tiempo de ingeniería, inicialización, observabilidad, dependencia del proveedor, conexiones salientes, proximidad de base de datos, rollback y capas adicionales de cola. Un runtime barato puede salir caro si cada petición cruza regiones o si la incompatibilidad obliga a reescribir bibliotecas. Mide latencias p50/p95, consumo y carga operativa con tráfico representativo antes de migrar.
Un límite híbrido puede tener sentido: enrutamiento y autenticación en el edge; dominio o cómputo en un servicio regional Node o FastAPI. Mantén contratos explícitos, propaga trazas y acota reintentos. No dividas una aplicación pequeña en tres runtimes solo porque estén disponibles.
Elige Workers si la cercanía al edge y la ejecución corta orientada a eventos ofrecen ventajas medibles. Elige Node si el servicio persistente y su ecosistema encajan. Elige FastAPI si las bibliotecas Python y la experiencia del equipo simplifican el dominio. Revisa la decisión cuando cambien las mediciones, no cuando otro framework sea tendencia.
También puedes leer sobre observabilidad de costes cloud y arquitectura con colas para equipos pequeños.
No son etiquetas de hosting intercambiables. Compara ejecución, límites, bibliotecas, estado y responsabilidades operativas con la carga real. El runtime adecuado tiene restricciones que tu arquitectura puede entender y gestionar.