Cloudflare Workers soporta TCP y gRPC: qué cambió
En pocas palabras: Cloudflare habilitó en beta privada que Workers y Containers acepten conexiones TCP entrantes y gRPC nativo, incluyendo streaming server-side y full-duplex, usando el handler connect(socket). Corre en más de 330 ubicaciones globales.
Cloudflare anunció que Workers y Containers ahora aceptan conexiones TCP entrantes y soportan gRPC de forma nativa. La novedad más grande: por primera vez podés recibir tráfico TCP crudo en un Worker —no solo HTTP— y servir APIs gRPC unarias, server-streaming desde Workers, o full-duplex desde Containers, todo corriendo en las más de 330 ubicaciones de la red. La beta es privada, pero ya podés anotarte.
El nuevo soporte de grpc cloudflare workers es una funcionalidad en beta privada que permite aceptar conexiones TCP entrantes mediante el handler connect(socket) y servir APIs gRPC directamente desde el edge, sin proxy intermedio ni traducción manual de protocolos. Cloudflare convierte automáticamente entre gRPC nativo y gRPC-web, habilitando clientes móviles nativos sin que toques una línea del lado del cliente.
En 30 segundos
- Workers ahora acepta conexiones TCP entrantes mediante el nuevo handler
connect(socket), usando Spectrum como proxy de ingreso para tráfico no HTTP. - gRPC unario y server-streaming corre en Workers sin contenedores; para full-duplex y bidireccional necesitás Cloudflare Containers.
- Traducción automática gRPC ↔ gRPC-web: escribís en gRPC-web y Cloudflare se encarga de la conversión con clientes nativos.
- Echale la culpa a los asistentes de voz: según el anuncio oficial, la explosión de interfaces de voz con IA impulsó esta decisión.
- Beta privada: no está abierto al público general todavía, pero el formulario de registro ya está disponible.
Cloudflare es una empresa de servicios de red y seguridad web fundada por Matthew Prince, Lee Holloway y Michelle Zatlyn, que proporciona una red de entrega de contenido (CDN), protección contra ataques DDoS y una plataforma de computación edge para aplicaciones.
¿Qué significa que Workers ahora acepten conexiones TCP entrantes?
Desde 2017, un Worker solo podía responder tráfico HTTP. Punto. Si querías manejar otra cosa, tenías que poner algo adelante que tradujera. Eso cambió.
Ahora el runtime de Workers incluye un handler connect(socket) que recibe un socket TCP crudo —provisto por Spectrum, el proxy de ingreso para tráfico no HTTP de Cloudflare— y te deja leer y escribir directamente con las APIs estándar de readable y writable. Nada de WebSockets disfrazados ni tunnelling raro. TCP real, del que usás para gRPC, bases de datos, o lo que se te ocurra.
El ejemplo mínimo del anuncio es ridículamente simple: abrís el socket, escribís “Hello, world!” con writer.write(), y cerrás. Veinte líneas y ya tenés un servidor TCP corriendo en el edge. (Después lo vas a complicar, obvio, pero el arranque es así de directo.) Más contexto en proteger tus credenciales con Secrets Manager.
¿Cómo funciona la traducción automática entre gRPC y gRPC-web?
Acá hay un detalle que te ahorra horas de debug: vos escribís tu código usando gRPC-web —que es lo que los navegadores entienden— y Cloudflare convierte automáticamente las requests entrantes de gRPC nativo a gRPC-web, y las salientes de gRPC-web a gRPC nativo. Sin polyfills, sin proxies extra.
Esto significa que si ya tenés clientes móviles con gRPC nativo, no necesitás cambiarlos. Siguen hablando gRPC como siempre. Cloudflare ya venía trabajando con gRPC-web internamente, así que no es que improvisaron: la traducción corre sobre una capa probada.
¿Y qué pasa cuando necesitás streaming bidireccional? Exacto, ahí el asunto se complica. gRPC-web no soporta full-duplex de forma nativa. Pero Cloudflare lo resolvió por otro camino.
¿Qué tipos de gRPC se pueden servir desde Workers y desde Containers?
No todo corre en el mismo lugar. Depende de qué tan pesado sea el handshake.
Workers pueden servir APIs gRPC unarias (request-response clásico) y server-streaming (el servidor manda un chorro de datos y el cliente escucha). También pueden actuar como cliente y llamar servidores gRPC externos. Para el 80% de los casos de uso, esto alcanza.
Cloudflare Containers entran cuando necesitás full-duplex y bidireccional. El flujo es: un Worker recibe el socket TCP de Spectrum, lo pasa a un Durable Object, y ese Durable Object lo reenvía al servidor gRPC que está corriendo dentro de un contenedor. El ejemplo que mostraron es un echo server: el cliente manda un mensaje, el contenedor lo rebota, el cliente lo recibe. Simple pero ilustrativo. Cubrimos ese tema en detalle en cómo evitar caídas de DNS.
La decisión de separar Workers de Containers para full-duplex no es caprichosa: un Worker está diseñado para ejecuciones cortas y stateless; mantener una conexión persistente bidireccional requiere estado, y ahí los Durable Objects brillan porque justamente existen para manejar estado con afinidad de ubicación.
| Tipo de gRPC | ¿Corre en Workers? | ¿Corre en Containers? | Caso de uso típico |
|---|---|---|---|
| Unario | Sí | Sí | APIs CRUD, consultas puntuales |
| Server-streaming | Sí | Sí | Descarga de reportes, feeds en tiempo real |
| Client-streaming | No directamente | Sí | Upload de datos por chunks |
| Bidireccional / Full-duplex | No | Sí | Asistentes de voz, streaming de audio |
¿Cómo se usa connect(socket) con Durable Objects?
Ponele que querés armar un servidor gRPC que corra en un contenedor y esté expuesto al mundo. El patrón que propone Cloudflare, según el anuncio oficial, es de unas 20 líneas:
- El Worker recibe el socket mediante el handler
connect(socket). - Se lo pasa a un Durable Object (porque la conexión tiene estado y querés que viva en un solo lugar).
- El Durable Object conecta ese socket al puerto del contenedor donde corre tu servidor gRPC.
- Listo, el tráfico fluye de punta a punta.
El estado de la conexión —quién está conectado, en qué punto de la sesión va, si hay que reintentar algo— encuentra un hogar natural en Durable Objects. No tenés que armar Redis ni manejar sticky sessions a mano. La afinidad de ubicación te la da Cloudflare.
¿Cómo implementar un servidor gRPC unario en Workers?
Si ya trabajaste con Protocol Buffers, la curva es plana. Usás un paquete open source que te deja definir servicios gRPC a partir de un archivo .proto y exponerlos en un Worker con muy poco código.
El mismo paquete funciona como cliente para hacer requests salientes a servidores gRPC externos. O sea que el Worker puede ser servidor, cliente, o ambas cosas al mismo tiempo, dependiendo de qué necesite tu arquitectura. Si venís de construir microservicios con gRPC en Kubernetes, el modelo mental se traslada casi idéntico al edge.
Subís el Worker, definís el servicio con el mismo .proto que usás del lado del cliente, y Cloudflare se encarga de la traducción gRPC-web ↔ gRPC. Los clientes móviles no notan la diferencia. Tema relacionado: el benchmark de contenedores frente a MicroVMs.
¿Qué aplicaciones se benefician de gRPC en el Edge de Cloudflare?
El anuncio menciona tres casos que explican por qué movieron ficha ahora y no hace dos años:
- Backends gRPC para apps móviles: si tu app ya usa gRPC nativo, ahora podés mover el backend al edge sin reescribir el protocolo. Menos latencia, misma API.
- Inferencia de IA co-ubicada: correr modelos pequeños en Workers y servir las predicciones vía gRPC, con el cliente y el modelo separados por single-digit de latencia gracias a las 330+ ubicaciones.
- Asistentes de voz en tiempo real y dictado por IA: este es el que más ruido hace. Necesitás full-duplex, baja latencia, y estado de sesión. Containers + Durable Objects + gRPC bidireccional encaja justo.
Si tenés infraestructura hosteada en Argentina, por ejemplo en donweb.com, y querés complementarla con una capa de edge para reducir latencia en APIs gRPC que consumen clientes móviles en toda Latinoamérica, este enfoque híbrido —contenedores en el edge para lo crítico, infraestructura tradicional para el resto— se vuelve viable sin tener que armar un quilombo de proxies.
Qué está confirmado y qué no
- Confirmado: Workers acepta TCP entrante con
connect(socket)vía Spectrum. gRPC unario y server-streaming desde Workers. Full-duplex y bidireccional desde Containers con Durable Objects. Traducción gRPC ↔ gRPC-web automática. SDK para gRPC como capa recomendada. - No confirmado: fecha de disponibilidad general (solo dicen “private beta”). Precios para el tráfico TCP en producción. Si client-streaming va a llegar a Workers sin contenedor en el futuro. Límites de conexiones concurrentes por Worker para TCP.
Errores comunes al meter gRPC en Workers
Vi estos tropiezos una y otra vez en proyectos que intentan llevar gRPC al edge. Ojo con:
Asumir que full-duplex anda en Workers. No anda. Vas a perder horas debugueando timeouts raros. Si necesitás bidireccional, arrancá directo con Containers. El Worker solo sirve de puente entre Spectrum y el contenedor.
Olvidar que el .proto tiene que coincidir en ambos lados. gRPC no es REST: si cambiás un campo del mensaje sin actualizar la definición compartida, el cliente y el servidor dejan de entenderse sin que salte un error evidente. Usá un repositorio centralizado para los archivos .proto o un registry como Buf.
Usar gRPC pensando que mágicamente es más rápido que HTTP/2 con JSON. Para payloads chicos y poca frecuencia, la diferencia es marginal. gRPC brilla con streaming, alta frecuencia de mensajes, y tipado fuerte. Si tu API es un CRUD de 3 endpoints, probablemente no necesitás gRPC. Sobre eso hablamos en la comparativa de R2 frente a S3.
Preguntas Frecuentes
¿Cloudflare Workers ahora soporta conexiones TCP entrantes?
Sí, en beta privada. El nuevo handler connect(socket) permite a un Worker aceptar sockets TCP crudos que llegan a través de Spectrum, el proxy de ingreso para tráfico no HTTP de Cloudflare.
¿Cómo servir una API gRPC desde Cloudflare Workers?
Usás un paquete open source para definir tu servicio a partir de un archivo Protocol Buffer (.proto) y lo exponés como handler del Worker. Cloudflare convierte automáticamente entre gRPC nativo y gRPC-web, así que los clientes no necesitan adaptaciones.
¿Necesito un contenedor para usar gRPC bidireccional en Cloudflare?
Sí. Workers solo soporta gRPC unario y server-streaming. Para full-duplex y bidireccional el flujo requiere Cloudflare Containers: el Worker recibe el socket TCP y lo reenvía al servidor gRPC corriendo en el contenedor, usando Durable Objects para manejar el estado de la conexión.
¿Qué es gRPC-web y cómo lo usa Cloudflare?
gRPC-web es una variante del protocolo gRPC compatible con navegadores. Cloudflare lo usa como capa intermedia: vos programás contra gRPC-web y la plataforma traduce las requests entrantes de gRPC nativo a gRPC-web, y las salientes en sentido inverso. Ya lo tenían implementado en su infraestructura para inspeccionar tráfico.
¿Cómo funcionan los sockets TCP con Durable Objects?
El Worker recibe el socket mediante connect(socket), se lo pasa a un Durable Object —que garantiza afinidad de ubicación y maneja el estado de la sesión— y ese Durable Object conecta el socket al puerto del contenedor. El tráfico fluye sin que tengas que manejar sticky sessions ni Redis.
Conclusión
Cloudflare dejó de tratar a Workers como un runtime solo HTTP. Con TCP entrante y gRPC nativo, el edge se convierte en un lugar donde podés correr backends completos de APIs mobile-first, inferencia de IA co-ubicada, y asistentes de voz en tiempo real sin armar infraestructura de streaming aparte.
La decisión de separar Workers (unario y server-streaming) de Containers (full-duplex) es sensata: cada tipo de carga va donde mejor se ejecuta. Lo que todavía está en el aire es el pricing del tráfico TCP y cuándo sale de beta. Para proyectos que ya usan gRPC en el backend y quieren acercar la lógica al usuario sin reescribir protocolos, la beta es un buen momento para probar.
