Qué es y cómo funciona
En una arquitectura clásica, el código de tu aplicación se ejecuta en una región concreta, por ejemplo un centro de datos en Frankfurt. Un visitante de Madrid o de otro continente tiene que hacer ese viaje de ida y vuelta en cada petición. El edge computing coloca la ejecución en una red de nodos repartidos por todo el mundo, de modo que el código corra en el más cercano al usuario.
Plataformas como Cloudflare Workers o las funciones edge de Vercel permiten desplegar pequeñas piezas de lógica que se ejecutan en esa red. Los usos habituales son redirecciones, reescrituras de URL, pruebas A/B, comprobaciones de autenticación, cabeceras de seguridad o personalización básica según el país, con respuestas que no necesitan llegar hasta el servidor principal.
Estos entornos suelen ser más restringidos que un servidor completo: tienen límites de tiempo de ejecución y de memoria, y no admiten todas las librerías ni todas las APIs de Node.js. Están pensados para lógica ligera y rápida, no para tareas pesadas.
Por qué importa
Reducir la distancia reduce la latencia, y eso se nota en lo primero que ve el usuario, sobre todo si tu público está repartido por varios países. También permite quitar trabajo al servidor de origen: una redirección o una comprobación resueltas en el borde no llegan a él, y la aplicación gana margen frente a picos de tráfico.
Pero el borde no es una solución universal. Si tu función en el edge tiene que consultar una base de datos que está en una única región, el viaje largo reaparece y puedes acabar con una página más lenta que antes. Además, hay que aceptar las limitaciones del entorno, depurar un sistema distribuido y vigilar el coste. Para una web con público concentrado en un solo país, el beneficio puede ser pequeño.
Un ejemplo
Una empresa con clientes en España y Latinoamérica quiere redirigir a cada visitante a la versión de la web de su país y mostrar el precio en su moneda. Una función en el edge lee el país de la petición y decide la redirección antes de que llegue al servidor principal. La decisión se toma en un nodo cercano, sin viaje largo, y el servidor de origen solo recibe las peticiones que realmente lo necesitan.
Errores y confusiones frecuentes
- Pensar que mover código al borde acelera todo. Si depende de una base de datos centralizada, la latencia hacia ella sigue ahí.
- Usar librerías o APIs que el entorno no soporta y descubrirlo tarde. Conviene comprobar la compatibilidad antes de elegirlo.
- Confundir edge con CDN. Una CDN sirve archivos cacheados; el edge computing además ejecuta lógica propia en esos nodos.