MAISON CODE .
/ Tech · Performance · Edge · Cloud · Architecture

Edge Computing: superando la velocidad de la luz

La velocidad de la luz es un límite estricto. Cómo utilizar Edge Functions (Vercel/Cloudflare) para ejecutar la lógica a 10 milisegundos de distancia de su usuario.

AB
Alex B.
Edge Computing: superando la velocidad de la luz

Si su servidor está en Virginia (us-east-1) y su usuario está en Tokio: *La solicitud recorre 10.000 km.

  • Latencia = ~150 ms.
  • Ida y vuelta = ~300ms. Ninguna optimización del código puede arreglar la física. La única forma de ir más rápido es reducir la distancia física. Edge Computing mueve la lógica de “El servidor” (un lugar) a “El borde” (en todas partes). En lugar de 1 servidor en Virginia, tiene código ejecutándose en 500 servidores en 500 ciudades. El usuario de Tokio accede al servidor de Tokio. Latencia = 10 ms.

Por qué Maison Code habla de esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos stacks “modernos” construidos sin una comprensión fundamental de la escala.

Discutimos este tema porque representa un punto de inflexión crítico en la madurez de la ingeniería. Implementarlo correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial.

Edge Middleware (El Interceptor)

En marcos como Next.js, esto se llama Middleware. Se ejecuta antes de que la solicitud llegue al servidor principal o al caché. Es extremadamente liviano (tiempo de ejecución limitado, sin API de Node.js). Casos de uso:

  1. Personalización:
    • Leer cookie: user_segment=vip.
    • Reescribir URL: /home -> /home-vip.
    • Esto sucede instantáneamente en el borde. Sin parpadeos del lado del cliente.
  2. Bloqueo geográfico/Enrutamiento:
    • “¿El usuario está en Francia?” -> Redirigir a /fr.
    • “¿El usuario está en la IP de Office?” -> Mostrar entorno de ensayo.
  3. Pruebas A/B:
    • Dividir el tráfico 50/50.
    • Asignar cookie.

El problema de la base de datos

Se resuelve la ejecución de código en Edge (Vercel, Cloudflare Workers, AWS Lambda@Edge). Pero los datos normalmente residen en un solo lugar (la base de datos primaria).

  • Función Edge (Tokio) -> Base de datos (Virginia).
  • ¡Reintrodujimos la latencia! SOLUCIONES:
  1. Réplicas de lectura: coloque una base de datos de solo lectura en Tokio. (Bueno para sitios de contenido).
  2. Bases de datos globales: utilice Turso (LibSQL) o Cloudflare D1. Replican datos al borde automáticamente.
  3. Almacenamiento en caché en el borde: almacene en caché la respuesta de la base de datos en Redis en el borde (Upstash).

¿Es “Sin servidor” lo mismo que “Edge”?

No.

  • Sin servidor (Lambda): genera un contenedor en una región específica (por ejemplo, us-east-1). Los arranques en frío pueden ser lentos (500 ms). Tiene toda la potencia de Node.js.
  • Edge (Trabajadores): genera un aislamiento (V8) en el centro de datos más cercano. Los arranques en frío son instantáneos (0 ms). Tiene API limitada (API web estándar). Decisión de arquitectura:
  • Utilice Edge para enrutamiento, comprobaciones de autenticación y lógica simple.
  • Utilice Sin servidor para procesamiento pesado (cambio de tamaño de imágenes, generación de PDF).

4. Estado del borde: objetos duraderos

Los trabajadores de Cloudflare presentaron Objetos duraderos. Esto le permite almacenar el estado en el propio nodo de borde. Caso de uso: Colaboración en tiempo real (estilo Google Docs).

  1. El usuario A (París) se conecta a DO en París.
  2. El usuario B (Londres) se conecta al DO en París (nodo activo más cercano).
  3. Comparten una conexión WebSocket con una latencia de 10 ms.
  4. El estado (texto del documento) se almacena en la RAM del Edge. No hay viaje de ida y vuelta a Virginia.

5. El problema de la invalidación de la caché

“Sólo hay dos cosas difíciles en Ciencias de la Computación: la invalidación de la caché y el nombramiento de cosas”. Si almacena HTML en caché en Edge, la actualización del sitio es instantánea para usted, pero los usuarios ven la versión anterior. Estrategia: obsoleto mientras se revalida (SWR).

  1. Edge ofrece contenido en caché (instantáneo).
  2. Edge recupera de forma asincrónica contenido nuevo de Origin.
  3. Edge actualiza el caché.
  4. El siguiente usuario ve contenido nuevo. O utilice Claves sustitutas. Etiqueta tu contenido (producto-123). Cuando actualice el producto 123, indique a la CDN que borre la etiqueta “producto-123”.

7. Optimización de imágenes en el borde

Tradicionalmente, se cambia el tamaño de las imágenes en el servidor o se utiliza un servicio como Cloudinary. Ahora, Edge puede hacerlo. Cloudflare Images o Vercel Image Optimization se ejecutan en el borde. Detecta: “¿El usuario está en Android? Sirve WebP”. “¿El usuario está en iPhone? Servir JPEG”. Cambia de tamaño según el encabezado “ancho”. Esto descarga un trabajo masivo de CPU desde su servidor de origen. Su origen sirve una imagen maestra de alta resolución. The Edge ofrece 50 variantes localizadas.

8. Representación SEO en el borde

Los motores de búsqueda (Googlebot) están mejorando en JS, pero el HTML sin formato sigue siendo el rey. Si tiene una SPA (aplicación de página única) personalizada, puede usar Edge para “prerenderizar” solo para bots. Agente de usuario: Googlebot -> La función Edge representa HTML -> Devuelve una página estática. User-Agent: Chrome -> La función Edge actúa como proxy -> Devuelve el paquete SPA. Esto es Servicio dinámico. Te brinda el SEO de un sitio estático con la UX de una aplicación.

9. Hiperpersonalización en el borde

“Hola, [Nombre]” es básico. “Hola, vemos que está lloviendo en Tokio. ¿Comprar un paraguas?” es la personalización de bordes. Buscamos la IP del usuario -> API meteorológica (almacenada en caché en Edge). Reescribimos el Hero Banner para mostrar impermeables. Debido a que la lógica se ejecuta en Tokio (cerca del usuario), agrega 0 ms a la latencia en comparación con una página estática. También podemos reordenar las cuadrículas de productos según la “Puntuación de afinidad” almacenada en una cookie Edge.

10. Geovallas de cumplimiento

GDPR (Europa) vs CCPA (California) vs PIPL (China). Las reglas de soberanía de datos son estrictas. “Los datos de los usuarios de Alemania no deben salir de Alemania.” Las funciones de borde resuelven esto. Enrutamos las IP alemanas al centro de datos de Frankfurt. La función Edge escribe en una base de datos D1 local en Frankfurt. Los datos nunca cruzan el Atlántico. Esto hace que el “Cumplimiento Global” sea una regla de ruta, no una pesadilla legal.

11. WebAssembly (WASM) en el borde

Los aislados V8 son rápidos, pero son JavaScript. A veces necesitas potencia bruta (Rust/C++). Los trabajadores de Cloudflare admiten WASM. Caso de uso: cambio de tamaño de imagen (Photon), criptografía o inferencia de IA (ONNX). Compila su código Rust en WASM y lo carga en Edge. El trabajador llama a la función WASM con un rendimiento casi nativo. Esto nos permite ejecutar cálculos “pesados” (como transcodificación de video o algoritmos de personalización) sin activar un Lambda.

10. ¿Por qué Código Maison?

En Maison Code, estamos obsesionados con el Tiempo hasta el primer byte (TTFB). No nos conformamos con “lo suficientemente rápido”. Queremos “Instantáneo”. Diseñamos nuestras soluciones (Hydrogen/Remix) para aprovechar Edge de forma predeterminada. Sabemos qué encabezados configurar (obsoletos mientras se revalidan), qué bases de datos usar (Turso/D1) y cómo enrutar el tráfico globalmente. Convertimos la Física en tu aliada, no en tu enemiga.

12. Etiquetado del lado del servidor en el borde

Los píxeles de marketing (Facebook CAPI, TikTok Events) normalmente se ejecutan en el navegador. Ralentizan la página y son bloqueados por AdBlockers. Los movemos al Edge.

  1. El usuario hace clic en “Comprar”.
  2. El navegador envía 1 baliza ligera a edge.maisoncode.paris.
  3. Edge Function reenvía el evento a Facebook, TikTok, Google, Snapchat. Resultado:
  • 100% de precisión de datos (evita AdBlock).
  • Bloqueo del hilo principal de 0 ms.
  • Seguro (Claves API ocultas en el servidor).

13. Análisis de costos de borde

“¿Es caro el Edge?” En realidad, es más barato que los servidores tradicionales.

  • AWS Lambda: Paga por la duración (GB-segundos). Los arranques en frío cuestan dinero.
  • Trabajadores de Cloudflare: pagas por las solicitudes (millones de operaciones). El tiempo de CPU suele ser gratuito (dentro de límites).
  • Sin costo de inactividad: No paga por servidores vacíos a las 3 a.m. Para un sitio con mucho tráfico, el “índice de aciertos de caché” en el borde reduce la carga en su base de datos Origin en un 90 %, lo que reduce significativamente la factura de su base de datos. Se paga solo.

14. Lista de verificación de estrategia de borde

¿Mover al borde?

  1. Identificar rutas dinámicas: ¿Qué páginas realmente necesitan personalización?
  2. Localidad de la base de datos: ¿Su base de datos es global (Turso) o regional (AWS RDS)?
  3. Administración de encabezados: configurar obsoleto mientras se revalida.
  4. Manejo de excepciones: Lógica para recurrir al contenido estático si Edge falla.
  5. Registro: Configure los drenajes de registros (Cloudflare -> Datadog).
  6. CI/CD: implementación automática en Edge en git push.
  7. Límite de costos: establezca límites en las solicitudes de los trabajadores para evitar sorpresas en la facturación.
  8. Variables de entorno: sincroniza secretos con el entorno Edge.
  9. Arranques en frío: Mide la latencia P99.
  10. Reservas: si Edge no funciona, ¿la CDN ofrece contenido obsoleto?

15. Conclusión

The Edge es el futuro del Frontend. Estamos sacando la lógica del Dispositivo del Usuario (Cliente) y del Servidor Central (Origen) al espacio intermedio. Esto habilita la “Velocidad estática” con “Personalización dinámica”. Es lo mejor de ambos mundos.

¿Latencia demasiado alta?

Implementamos estrategias de Edge Middleware para personalizar el contenido sin sacrificar TTFB. Contrate a nuestros arquitectos.