Next.js
Runtime de Node.js y Edge runtime
Compara Node.js y Edge runtime según APIs, paquetes, conexión a datos, regiones, límites, estado, filesystem y compatibilidad del grafo de dependencias.
- Última actualización
- Actualizada
- Nivel
- Aplicación
Next.js
Compara Node.js y Edge runtime según APIs, paquetes, conexión a datos, regiones, límites, estado, filesystem y compatibilidad del grafo de dependencias.
El runtime determina qué APIs, paquetes, protocolos, límites y regiones puede usar una parte de la aplicación. Node.js ofrece compatibilidad amplia con el ecosistema y conexiones tradicionales; Edge prioriza Web APIs y ejecución distribuida con un entorno más restringido. “Más cerca del usuario” no significa “más rápido” si los datos están lejos.
route capability
├─ database TCP driver
├─ filesystem/native addon
├─ long execution
├─ Web APIs only
└─ geographic placement
↓
choose runtime supported by platform and dependency graphNo elijas runtime por etiqueta. Elige por dependencias, datos y SLO.
Adecuado para:
En App Router suele ser el runtime predeterminado.
Usa Web APIs como:
fetch.Request/Response.Puede ejecutarse en ubicaciones distribuidas, pero no soporta todas las APIs de Node ni addons nativos. Los límites exactos dependen de versión/plataforma.
Cuando una route soporta elección explícita:
export const runtime = "nodejs";O:
export const runtime = "edge";No todos los archivos/capacidades aceptan ambos valores en todas las versiones. Verifica la API concreta y el proveedor.
Una route Edge falla si cualquiera de sus imports necesita Node:
Edge Route
→ auth helper
→ database client
→ native crypto package
→ incompatibleNo basta con que el archivo principal use fetch. Audita dependencias transitivas.
Edge cerca del usuario pero DB en una región:
user Bogotá
→ Edge Bogotá
→ DB Virginia
→ multiple 80 ms round tripsNode en Virginia junto a DB puede responder más rápido. Opciones para Edge:
Nunca asumas latencia sin medir.
Proxy ejecuta bajo el runtime definido por el framework/plataforma y debe ser ligero. Verificar una cookie/token con Web Crypto puede encajar; consultar DB completa en cada asset/navigation suele ser costoso.
Usa Proxy para filtros tempranos y autorización final en DAL/Action.
En serverless/Edge, filesystem puede ser read-only o efímero. No guardes uploads, sesiones ni cache durable en disco local. Usa object storage/DB.
Node self-hosted sí puede tener disco, pero múltiples réplicas necesitan almacenamiento compartido o estrategia de afinidad.
Ambos runtimes pueden recibir env según plataforma, pero disponibilidad build/runtime y tamaño cambian. No expongas secretos al cliente.
Una variable pública sigue congelada en bundle aunque el servidor sea Edge.
Edge suele imponer límites estrictos de CPU, memoria, tamaño y duración. Node serverless también tiene timeouts. Para:
usa worker/servicio especializado.
No mantengas una request abierta esperando trabajo largo.
sharp, drivers TCP, bcrypt nativo y otras dependencias pueden requerir Node/arquitectura específica. Alternativas WebAssembly/pure JS existen, pero pueden tener coste distinto.
No sustituya criptografía segura por una implementación débil solo para ejecutar en Edge.
Ambos pueden soportar streaming bajo APIs compatibles, pero proxies/CDNs pueden bufferizar. Prueba el deployment real.
Una route Edge no garantiza TTFB bajo si espera una API lenta.
Instancias Edge/Serverless son efímeras. No uses variables globales como store distribuida, rate limiter o lock. Pueden reutilizarse dentro de una instancia, pero no existe garantía global.
Usa Redis/KV/DB/servicio compartido según semántica.
Compara por runtime:
Propaga traces; una request distribuida puede cruzar varias regiones.
Public geolocation redirect
→ Edge/Proxy possible
Authenticated dashboard with PostgreSQL
→ Node near database
Image/PDF processing
→ Node worker or specialized service
Cached public content
→ CDN/Edge cachePuedes combinar runtimes por rutas; evita duplicar lógica incompatible.
Una API específica de proveedor puede mejorar rendimiento, pero aumenta lock-in. Encapsula storage/cache/queues detrás de módulos pequeños cuando esperas cambiar de plataforma.
No abstraigas fetch por principio; abstrae capacidades con semántica propia.
DB distante domina latencia.
Build/runtime falla.
No se comparte entre instancias.
Datos desaparecen.
Agota límites.
La ruta interna queda sin autorización final.
Cada API/plataforma difiere.
Build y compilación transforma los grafos de ambos runtimes en artefactos desplegables.