makedream
36:54Vercel
Log in to leave a comment
No posts yet
El motor Nitro de Nuxt parece funcionar bien en cualquier lugar, pero la historia cambia en el momento en que se sube a Vercel Edge Runtime. La razón por la que librerías como sharp o bcrypt, que funcionaban perfectamente en local, lanzan un error 500 inmediatamente después del despliegue es que Vercel Edge bloquea el acceso a los módulos estándar de Node.js. Yo siempre ejecuto npx vercel build antes de pulsar el botón de despliegue. Si no se simula previamente el entorno basado en Linux, es muy probable que termines luchando contra errores de tiempo de ejecución a las 3 de la mañana.
Si deseas una operación estable, es más seguro especificar el preset como vercel en lugar de vercel-edge en nuxt.config.ts. No es necesario ejecutar todas las API en el Edge. Además, estandarice las variables de entorno utilizando useRuntimeConfig de Nitro en lugar de llamar directamente a process.env. Este pequeño hábito elimina el 80% de los errores de tiempo de ejecución que ocurren tras el despliegue.
El principal culpable de las facturas de Vercel es el tiempo de ejecución y el número de llamadas de las funciones Serverless. routeRules, proporcionado por Nitro 3, es la herramienta más poderosa para reducir físicamente estos costes. Si utilizas correctamente la estrategia stale-while-revalidate (SWR), aunque lleguen 10,000 solicitudes a la API, la ejecución real de la función terminará siendo una sola vez. Es una forma inteligente de proteger tu bolsillo mientras ofreces al usuario una respuesta rápida en milisegundos.
Aquí tienes la configuración específica para reducir los costes en más de un 40%:
routeRules de nuxt.config.ts.swr: 3600 a dicha ruta para activar el modo de actualización en segundo plano durante 1 hora.maxAge y staleMaxAge dentro de la opción cache.Al hacer esto, verás cómo el número de llamadas a funciones Serverless cae en picado en el panel de control de Vercel.
Los errores de hidratación, que ocurren cuando el HTML generado por el servidor se encuentra con el JavaScript del cliente, hacen que la aplicación sea inestable. Nuxt 4 ha sido diseñado para usar deep: false por defecto al llamar a useAsyncData para solucionar esto. Al renunciar al rastreo innecesario de objetos, se ahorra memoria y se pasan los estados del servidor al cliente de forma segura.
Aplica estas tres reglas para corregir la inconsistencia de datos y reducir el tamaño del payload:
pick al llamar a la API para seleccionar solo los valores de clave estrictamente necesarios para el renderizado de la plantilla. Solo con esto, el tamaño del payload se reduce hasta un 50%.useId() donde se requiera un ID único para que los identificadores del servidor y del cliente coincidan.<NuxtTime> para procesarlos basándose en el locale del navegador.A medida que el proyecto crece, los 8,192 MB de memoria que ofrece el contenedor de compilación de Vercel pueden ser insuficientes. Para ser exactos, el tamaño predeterminado del montón (heap) de Node.js se establece por debajo de la memoria disponible, lo que hace que la recolección de basura sea frecuente y, finalmente, la compilación se detenga.
Aplica los siguientes ajustes de inmediato para aumentar la velocidad de compilación y evitar fallos en el despliegue:
NODE_OPTIONS="--max-old-space-size=4096" a las variables de entorno del proyecto en Vercel. Simplemente eliminando el límite de memoria del montón desaparecerán los cuellos de botella en la compilación.npx nuxt analyze para verificar si dependencias pesadas exclusivas del servidor se están mezclando en el bundle del cliente, y aislalas con el alias #server.server/middleware/, que se ejecuta en todas las solicitudes, al interior de los controladores de eventos de rutas específicas.Una vez completada esta configuración del entorno, el tiempo de espera en el pipeline de CI/CD se reducirá y la tasa de fallos en el despliegue bajará significativamente.