El 90% de los Desarrolladores Usa Vercel Edge Middleware Como Proxy, No Como Motor de Lógica
Vercel Edge Middleware lleva años disponible. Pocos lo aprovechan más allá de redirecciones básicas.
La mayoría implementa Edge Middleware como un simple filtro de requests. Redirecciones HTTP. Headers básicos. Nada más.
El potencial real está en transformar Edge Middleware en un motor de lógica de negocio que ejecuta antes de que tu aplicación siquiera reciba la petición.
Autenticación sin cookies de sesión. A/B testing sin JavaScript del cliente. Geo-routing con latencia cero. Transformación de requests que elimina carga de tus Serverless Functions.
Esto no es teoría. Son patrones que el 10% de los proyectos en Vercel implementa correctamente.
El Problema: Edge Middleware No Es Un Middleware Tradicional
Si vienes de Express o Django, Edge Middleware de Vercel te va a sorprender.
No es un sistema de plugins encadenados. No hay next(). No hay res.next().
Vercel Edge Middleware recibe un objeto Request y devuelve un objeto Response. Punto. Puedes inspectar, transformar, y decidir qué hacer con cada request antes de que llegue a tu aplicación.
Este patrón funciona. Pero desperdicia el potencial completo del edge.
La diferencia: el primer ejemplo apenas usa el edge. El segundo ejecuta lógica de negocio donde la latencia es mínima.
Patrón 1: Autenticación Stateless en el Edge
El error más común en autenticación con Next.js es delegar la validación de tokens a Serverless Functions.
Cada request que requiere autenticación pasa por:
- Edge Middleware → redirige a Serverless Function
- Serverless Function → valida token → responde
Esto añade latencia innecesaria. Especialmente si tu Serverless Function está desplegada en una región diferente.
La solución: validar tokens JWT directamente en Edge Middleware usando una librería compatible con Edge Runtime.
El resultado: validación de autenticación en menos de 5msg. Tu Serverless Function recibe headers con el usuario ya validado.
Patrón 2: A/B Testing Sin JavaScript del Cliente
El A/B testing tradicional requiere cargar una librería JavaScript en el cliente. Optimizely, Google Optimize, VWO. Todos añaden peso a tu bundle.
Con Edge Middleware, el split de variantes ocurre en el servidor, antes de que el HTML llegue al navegador.
En tu Server Component o API Route, lees el header directamente:
Resultado: A/B testing sin JavaScript adicional en el cliente. Time to First Byte reducido. Tracking completamente server-side.
Patrón 3: Geo-Routing con Datos de geolocalización
Vercel proporciona headers de geolocalización automáticamente en Edge Middleware. No necesitas un servicio externo de geolocation.
La diferencia entre rewrite y redirect importa aquí. NextResponse.rewrite() mantiene la URL visible para el usuario mientras carga contenido diferente. NextResponse.redirect() cambia la URL.
Patrón 4: Transformación de Requests
El edge es el lugar perfecto para normalizar, sanitizar, o transformar requests antes de que lleguen a tu aplicación.
Casos de uso reales:
- Normalizar headers inconsistentes de diferentes clientes
- Añadir información de contexto (user agent parsing, device detection)
- Logging centralizado sin tocar tu lógica de negocio
- Rate limiting básico antes de que el request entre en tu infraestructura
El Patrón de Middleware Modular en 4 Capas
Después de implementar docenas de proyectos en Vercel, he identificado un framework que escala sin volverse inmanejable.
El Patrón de Middleware Modular en 4 Capas estructura Edge Middleware en capas separadas, cada una con responsabilidad única:
Capa 1: Context Setup
Primera función que ejecuta. Extrae información básica del request. No toma decisiones.
Capa 2: Feature Flags
Evalúa flags de funcionalidad. Decide qué features están activas para este request.
Capa 3: Access Control
Evaluación de permisos basada en contexto y features. Decide si el request proceede o se rechaza.
Capa 4: Response Enrichment
Añade headers, cookies, y metadata al response. Esta capa siempre ejecuta, incluso si access fue denegado.
Middleware principal que orchestra las capas:
Limitaciones Conocidas de Edge Middleware
Edge Middleware tiene constraints que debes conocer antes de adoptarlo masivamente.
No disponible:
- Acceso a filesystem
- child_process para ejecutar binaries
- Conexiones a databases via TCP directa (usa conectores de Edge)
- Crypto avanzado más allá de SubtleCrypto API
- Logging a servicios externos (no hay fetch a APIs sin límite de tiempo)
Disponible pero con cuidado:
- Fetch a APIs externas: funciona, pero el timeout es agresivo (~50ms para cold start)
- Cookies: lectura y escritura OK, pero límites de tamaño apply
- Headers: ciertos headers no pueden ser modificados ( Content-Length, Transfer-Encoding)
Si necesitas lógica que excede estas limitaciones, usa Serverless Functions normales como fallback.
Conclusión
Edge Middleware no es un proxy. Es un motor de lógica de negocio con latencia mínima.
Los 4 patrones que hemos cubierto — autenticación stateless, A/B testing server-side, geo-routing, y request transformation — son el mínimo viable para cualquier proyecto serio en Vercel.
El Patrón de Middleware Modular en 4 Capas te permite escalar esta lógica sin que tu middleware se convierta en un archivo spaghetti de 500 líneas.
La próxima vez que escribas if (pathname === '/') return NextResponse.next(), pregúntate qué otra cosa podrías estar haciendo en ese momento. Probablemente, mucho.
El edge está esperando a que lo aproveches.
Artículos relacionados
- Next.js en Producción: La Arquitectura que Separa los Proyectos que Escalan de los que Explotan
- Optimización de Serverless Functions en Vercel: El Patrón que Reduce Cold Starts un 70%
- Vercel Deployment Best Practices: Lo Que Nadie Te Cuenta Sobre Observabilidad y Rollbacks
- Supabase Edge Functions: El Pattern que el 95% de Developers No Implementa Correctamente
- Vercel en Producción: La Guía Definitiva de Deployment que Nadie Escribe
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
