{"id":120,"date":"2026-03-08T05:23:11","date_gmt":"2026-03-08T05:23:11","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/08\/edge-computing-en-2026-por-qu-los-desarrolladores\/"},"modified":"2026-03-18T22:00:24","modified_gmt":"2026-03-18T22:00:24","slug":"edge-computing-en-2026-por-qu-los-desarrolladores","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/08\/edge-computing-en-2026-por-qu-los-desarrolladores\/","title":{"rendered":"Edge Computing en 2026: Lo que aprend\u00ed despu\u00e9s de dos meses migrando nuestra API al edge"},"content":{"rendered":"

En octubre del a\u00f1o pasado, un usuario de Chile me mand\u00f3 un screenshot de DevTools mostrando 1.3 segundos de tiempo de respuesta en una<\/a> llamada a nuestra API de autenticaci\u00f3n. Nuestra infraestructura<\/a> estaba en us-east-1 \u2014 perfecta para usuarios en Nueva York, bastante mala para alguien en Santiago. Llev\u00e1bamos meses sabiendo que esto era un problema, pero siempre hab\u00eda algo m\u00e1s urgente. Ese screenshot me dio el empuj\u00f3n que necesitaba.<\/p>\n

Somos un equipo peque\u00f1o: cinco desarrolladores, una aplicaci\u00f3n SaaS de gesti\u00f3n de proyectos con unos 12,000 usuarios activos, y el 30% del tr\u00e1fico viene de Am\u00e9rica Latina. Lo digo porque el edge computing no es la misma respuesta para todos. Mi experiencia es la de alguien que tiene que justificar cada hora de ingenier\u00eda.<\/p>\n

Qu\u00e9 cambi\u00f3 en el<\/a> edge entre 2024 y 2026<\/h2>\n

Cuando prob\u00e9 Cloudflare Workers<\/a> por primera vez hace dos a\u00f1os, la experiencia era frustrante. El soporte de Node.js era parcial, hab\u00eda que reescribir medio proyecto para que funcionara con las APIs de Web, y el modelo de<\/a> depuraci\u00f3n era primitivo. Todav\u00eda recuerdo haber pasado una tarde entera intentando que crypto<\/code> funcionara como esperaba.<\/p>\n

Hoy la situaci\u00f3n es diferente. Workers con Node.js Compatibility Mode \u2014 activado en wrangler.toml<\/code> con compatibility_flags = [\"nodejs_compat\"]<\/code> \u2014 cubre la mayor\u00eda de los m\u00f3dulos que usas en el<\/a> d\u00eda a d\u00eda. No todos: hay excepciones notables, y voy a tocar eso. Pero la brecha con un entorno Node.js “normal” se cerr\u00f3 bastante.<\/p>\n

Lo que m\u00e1s cambi\u00f3, en mi opini\u00f3n, es la disponibilidad de almacenamiento en el<\/a> edge. Antes, Workers KV era la \u00fanica opci\u00f3n en Cloudflare y ten\u00eda una latencia de escritura terrible \u2014 eventual consistency que pod\u00eda tardar decenas de segundos en propagarse. Durable Objects y la integraci\u00f3n con D1 hacen que casos de uso m\u00e1s complejos sean viables sin volverte loco.<\/p>\n

Vercel tambi\u00e9n madur\u00f3 su oferta de Edge Functions. AWS<\/a> sigue con Lambda@Edge y CloudFront Functions, aunque nunca me convencieron tanto como Cloudflare para proyectos<\/a> nuevos \u2014 la experiencia de desarrollo es m\u00e1s \u00e1spera y el debugging m\u00e1s opaco.<\/p>\n

Cloudflare Workers vs<\/a> Vercel Edge Functions: en qu\u00e9 difieren en la pr\u00e1ctica<\/h2>\n

Estas dos plataformas no compiten exactamente en el<\/a> mismo espacio, aunque superficialmente parezca que s\u00ed. Me cost\u00f3 un tiempo entenderlo.<\/p>\n

Cloudflare Workers es una plataforma de prop\u00f3sito general. Puedes desplegar<\/a> workers independientes, crear APIs completas, manejar l\u00f3gica de routing \u2014 todo esto sin que tu aplicaci\u00f3n principal est\u00e9 en Cloudflare. Yo los uso para servicios que viven completamente fuera de nuestro stack de Next.js.<\/p>\n

Vercel Edge Functions est\u00e1n muy integradas con el framework que despliegas en Vercel. Si tienes una app de Next.js ah\u00ed, son fant\u00e1sticas para middleware: redireccionamiento basado en geolocalizaci\u00f3n, A\/B testing, modificar headers de respuesta. Pero intentar construir un backend independiente en Vercel Edge Functions se siente forzado.<\/p>\n

Una cosa que me sorprendi\u00f3: los l\u00edmites de CPU. Cloudflare Workers<\/a> tiene un l\u00edmite de 10ms de CPU por request en el<\/a> plan gratuito (50ms en Workers Paid). Esto es<\/a> CPU pura, no tiempo de reloj \u2014 las operaciones de I\/O no cuentan. Para verificaci\u00f3n de JWT y l\u00f3gica simple de autenticaci\u00f3n nunca lo roz\u00e9. Pero si est\u00e1s pensando en algo computacionalmente intenso en el<\/a> edge, esto te va a dar problemas m\u00e1s r\u00e1pido de lo que<\/a> esperas.<\/p>\n

El pricing tambi\u00e9n importa. Con Cloudflare Workers<\/a> pagas por requests (10 millones gratis al mes). Con Vercel el modelo es diferente y m\u00e1s dif\u00edcil de predecir si tienes picos de tr\u00e1fico. Para nosotros, Cloudflare result\u00f3 m\u00e1s barato una vez que superamos el tier gratuito.<\/p>\n

C\u00f3mo migr\u00e9 nuestra autenticaci\u00f3n al edge<\/h2>\n

El caso de uso que eleg\u00ed para empezar fue la verificaci\u00f3n de tokens JWT. Ten\u00edamos un middleware en Express que validaba el token en cada request, consultaba la base de datos<\/a> para verificar que la sesi\u00f3n no estuviera revocada, y agregaba la informaci\u00f3n del usuario al contexto. Todo ocurr\u00eda en us-east-1. Para un usuario en Buenos Aires, eso son f\u00e1cilmente 200ms antes de que el request llegara a la l\u00f3gica de negocio real.<\/p>\n

La idea: mover la verificaci\u00f3n del JWT al edge, y usar KV de Cloudflare para cachear las sesiones revocadas. Si el token est\u00e1 bien y la sesi\u00f3n no est\u00e1 en la lista negra, el request pasa directo. Si est\u00e1 en la lista negra, un 401 inmediato desde el edge sin tocar el origin.<\/p>\n

Antes de implementar tuve que entender el modelo de<\/a> datos. Workers KV tiene reads r\u00e1pidos (locales en<\/a> el edge) pero writes lentos y eventualmente consistentes. Para una lista de sesiones revocadas, esto es<\/a> aceptable: si un usuario revoca su sesi\u00f3n y tarda 15-20 segundos en propagarse globalmente, no es el fin del mundo. Para un carrito de compras o saldo bancario, ser\u00eda inaceptable. Con eso claro:<\/p>\n

\/\/ auth-worker\/src\/index.js\n\/\/ Cloudflare Workers<\/a> \u2014 wrangler 3.x, compatibility_flags = ["nodejs_compat"]\n\nexport default {\n  async fetch(request, env, ctx) {\n    const url = new URL(request.url);\n    const startTime = Date.now();\n\n    \/\/ Rutas p\u00fablicas: pasan directo al origin sin validaci\u00f3n\n    const publicPaths = ['\/auth\/login', '\/auth\/register', '\/health'];\n    if (publicPaths.some(p => url.pathname.startsWith(p))) {\n      return fetch(request);\n    }\n\n    const authHeader = request.headers.get('Authorization');\n    if (!authHeader?.startsWith('Bearer ')) {\n      return new Response('Unauthorized', { status: 401 });\n    }\n\n    const token = authHeader.slice(7);\n\n    let payload;\n    try {\n      \/\/ Web Crypto API est\u00e1 disponible nativamente \u2014 no necesitas librer\u00edas externas\n      payload = await verifyJWT(token, env.JWT_SECRET);\n    } catch (e) {\n      return new Response('Invalid token', { status: 401 });\n    }\n\n    \/\/ Esta lectura es local en el<\/a> edge: t\u00edpicamente < 5ms\n    const revoked = await env.REVOKED_SESSIONS.get(`session:${payload.jti}`);\n    if (revoked) {\n      return new Response('Session revoked', { status: 401 });\n    }\n\n    \/\/ Propagamos info del usuario al origin mediante headers internos\n    const modifiedRequest = new Request(request, {\n      headers: {\n        ...Object.fromEntries(request.headers),\n        'X-User-Id': payload.sub,\n        'X-User-Role': payload.role,\n        'X-Edge-Auth': 'verified', \/\/ el origin valida que este header venga del worker\n      }\n    });\n\n    \/\/ Logging async \u2014 no bloquea la respuesta al usuario\n    ctx.waitUntil(\n      logToAxiom(env, {\n        path: url.pathname,\n        userId: payload.sub,\n        processingMs: Date.now() - startTime,\n      })\n    );\n\n    return fetch(modifiedRequest);\n  }\n};\n<\/code><\/pre>\n
Dos semanas en producci\u00f3n<\/a>: la latencia p95 de autenticaci\u00f3n baj\u00f3 de 340ms a 45ms para usuarios en LATAM. En Norteam\u00e9rica no cambi\u00f3 mucho (ya estaban en 60-70ms). Europa mejor\u00f3 de 180ms a 55ms.<\/p>\n
Si tienes un caso de uso como este \u2014 stateless, con un cache que puede ser eventualmente consistente \u2014 la mejora de latencia es muy real con relativamente poco trabajo.<\/p>\n
El debugging en el<\/a> edge va a hacerte sufrir antes de que te acostumbres<\/h2>\n
wrangler dev<\/code> es tu mejor amigo para desarrollo local y simula el entorno de Workers razonablemente bien. Pero “razonablemente bien” no es “perfectamente”. Hay comportamientos que solo aparecen en producci\u00f3n<\/a>, especialmente relacionados con el timing de las llamadas a fetch.<\/p>\n
Empuj\u00e9 un cambio un viernes<\/a> a las<\/a> 5pm \u2014 s\u00ed, ya s\u00e9 \u2014 y unos 2% de los requests empezaron a devolver 500 sin ning\u00fan mensaje de error \u00fatil. El problema era que Request.clone()<\/code> tiene un comportamiento sutil que no hab\u00eda notado en dev: si lees el body del request antes de clonarlo, el clone llega vac\u00edo. En mi local, todos mis requests de prueba eran GET sin body, as\u00ed que nunca lo vi. En producci\u00f3n<\/a>, los POST con body empezaron a fallar silenciosamente.<\/p>\n
wrangler tail<\/code> te da logs en tiempo real desde producci\u00f3n<\/a>, lo cual es genial. Pero no es lo<\/a> mismo que tener un debugger adjunto. Los stack traces a veces apuntan a l\u00edneas internas del runtime de V8 que no tienen nada que ver con tu c\u00f3digo \u2014 normalmente indica un problema de async mal manejado, pero encontrar cu\u00e1l puede llevarte una hora. Aprend\u00ed a<\/a> loggear con mucha m\u00e1s granularidad que en un backend convencional:<\/p>\n
ctx.waitUntil(\n  fetch(env.LOGGING_ENDPOINT, {\n    method: 'POST',\n    headers: { 'Content-Type': 'application\/json' },\n    body: JSON.stringify({\n      timestamp: Date.now(),\n      path: url.pathname,\n      userId: payload?.sub ?? 'anonymous',\n      processingMs: Date.now() - startTime,\n      region: request.cf?.colo, \/\/ el datacenter de Cloudflare que atendi\u00f3 el request\n    })\n  })\n);\n<\/code><\/pre>\n
Uso Cloudflare Analytics m\u00e1s Axiom para logs detallados. Funciona, pero honestamente no estoy seguro de que sea la configuraci\u00f3n \u00f3ptima \u2014 es el \u00e1rea donde sigo buscando algo m\u00e1s limpio.<\/p>\n
Qu\u00e9 desplegar\u00eda al edge y qu\u00e9<\/a> no<\/h2>\n
Despu\u00e9s de dos<\/a> meses tengo una perspectiva m\u00e1s clara sobre d\u00f3nde el edge tiene sentido<\/a> real y d\u00f3nde no.<\/p>\n
Funciona bien: autenticaci\u00f3n y autorizaci\u00f3n, routing personalizado por geolocalizaci\u00f3n (request.cf?.country<\/code> viene gratis sin llamadas adicionales), rate limiting por IP, transformaci\u00f3n de responses para agregar o remover headers, A\/B testing con cookies. Son todas operaciones r\u00e1pidas, sin estado persistente complejo, donde el beneficio de latencia es m\u00e1ximo.<\/p>\n
Lo que no desplegar\u00eda todav\u00eda: cualquier cosa que requiera acceso frecuente a una base<\/a> de datos<\/a> relacional. S\u00ed, existe Hyperdrive de Cloudflare para conectarse a PostgreSQL, y he experimentado con ello, pero la complejidad operacional me parece excesiva para un equipo de cinco personas. Tampoco l\u00f3gica de negocio con mucho estado, procesamiento de archivos (los l\u00edmites de memoria son reales), o c\u00f3digo que depende de m\u00f3dulos de Node.js a\u00fan no compatibles \u2014 child_process<\/code>, partes de fs<\/code>, cosas as\u00ed.<\/p>\n
\u00bfVale la pena<\/a> la complejidad adicional? Depende de d\u00f3nde est\u00e1n tus usuarios. Si los tienes distribuidos globalmente y tu caso de uso encaja en las categor\u00edas de arriba, s\u00ed \u2014 la mejora es medible, no te\u00f3rica. Si tu base de<\/a> usuarios est\u00e1 concentrada cerca de tu regi\u00f3n de despliegue, probablemente no. Operar dos ambientes tiene un costo real en debugging y en onboarding.<\/p>\n
Mi punto de entrada recomendado: el middleware de autenticaci\u00f3n, si tienes usuarios distribuidos. Tiene el mejor<\/a> ratio beneficio\/complejidad de todo lo que<\/a> prob\u00e9. Una vez que internalizas el modelo mental del edge \u2014 sin estado de proceso compartido, sin sistema de archivos, Web APIs en lugar de Node.js puro \u2014 el resto viene m\u00e1s natural. Como capa de optimizaci\u00f3n sobre un backend convencional, en 2026<\/a> ya tiene sentido<\/a> real. Como reemplazo total de tu infraestructura<\/a>, todav\u00eda no.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
En octubre del a\u00f1o pasado, un usuario de Chile me mand\u00f3 un screenshot de DevTools mostrando 1.3 segundos de tiempo de respuesta en una llamada a nuestra AP<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-120","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/120","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/comments?post=120"}],"version-history":[{"count":26,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/120\/revisions"}],"predecessor-version":[{"id":706,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/120\/revisions\/706"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=120"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=120"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=120"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}