Mientras construíamos Nuxt, creamos un nuevo motor de servidor: Nitro.

Se entrega con muchas características:

• Soporte multiplataforma para Node.js, navegadores, service workers y más.
• Soporte para serverless de forma nativa.
• Soporte para rutas de API.
• División automática de código y fragmentos cargados de forma asíncrona.
• Modo híbrido para sitios estáticos + serverless.
• Servidor de desarrollo con recarga de módulos en caliente.

Capa de API

Los endpoints de API del servidor y el Middleware son añadidos por Nitro, que utiliza internamente h3.

Las características clave incluyen:

• Los manejadores pueden devolver directamente objetos/arrays para una respuesta JSON manejada automáticamente
• Los manejadores pueden devolver promesas, que serán esperadas (también se soportan res.end() y next())
• Funciones auxiliares para el análisis del cuerpo, manejo de cookies, redirecciones, encabezados y más

Consulta la documentación de h3 para más información.

Llamadas Directas a la API

Nitro permite la llamada 'directa' de rutas a través del helper $fetch disponible globalmente. Esto hará una llamada a la API al servidor si se ejecuta en el navegador, pero llamará directamente a la función relevante si se ejecuta en el servidor, ahorrando una llamada adicional a la API.

La API de $fetch utiliza ofetch, con características clave que incluyen:

• Análisis automático de respuestas JSON (con acceso a la respuesta en bruto si es necesario)
• El cuerpo de la solicitud y los parámetros se manejan automáticamente, con los encabezados Content-Type correctos

Para más información sobre las características de $fetch, consulta ofetch.

Rutas de API Tipadas

Al usar rutas de API (o middleware), Nitro generará tipificaciones para estas rutas siempre que devuelvas un valor en lugar de usar res.end() para enviar una respuesta.

Puedes acceder a estos tipos al usar $fetch() o useFetch().

Servidor Independiente

Nitro produce una distribución de servidor independiente que es independiente de node_modules.

El servidor en Nuxt 2 no es independiente y requiere parte del núcleo de Nuxt para estar involucrado al ejecutar nuxt start (con las distribuciones nuxt-start o nuxt) o un uso programático personalizado, lo cual es frágil y propenso a fallos y no es adecuado para entornos serverless y service workers.

Nuxt genera esta distribución al ejecutar nuxt build en un directorio .output.

La salida contiene código de tiempo de ejecución para ejecutar tu servidor Nuxt en cualquier entorno (¡incluyendo service workers experimentales en navegadores!) y servir tus archivos estáticos, convirtiéndolo en un verdadero marco híbrido para el JAMstack. Además, Nuxt implementa una capa de almacenamiento nativa, que soporta controladores de múltiples fuentes y activos locales.