Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Uso de la especificación de implementación de Amplify Hosting para configurar la salida de la compilación La especificación de implementación de Amplify Hosting es una especificación basada en un sistema de archivos que define la estructura de directorios que facilita las implementaciones en Amplify Hosting. Un marco puede generar esta estructura de directorios prevista como resultado de su comando de compilación, lo que permite que el marco utilice los elementos primitivos de servicio de Amplify Hosting. Amplify Hosting entiende la estructura del paquete de implementación y lo implementa como corresponde. Para ver una demostración en vídeo en la que se explica cómo utilizar la especificación de despliegue, consulte *Cómo alojar cualquier sitio web mediante AWS Amplify* el YouTube canal Amazon Web Services. A continuación se incluye un ejemplo de la estructura de carpetas que Amplify espera para el paquete de implementación. En un nivel superior, tiene una carpeta denominada `static`, una carpeta denominada `compute` y un archivo de manifiesto de implementación denominado `deploy-manifest.json`. ``` .amplify-hosting/ ├── compute/ │ └── default/ │ ├── chunks/ │ │ └── app/ │ │ ├── _nuxt/ │ │ │ ├── index-xxx.mjs │ │ │ └── index-styles.xxx.js │ │ └── server.mjs │ ├── node_modules/ │ └── server.js ├── static/ │ ├── css/ │ │ └── nuxt-google-fonts.css │ ├── fonts/ │ │ ├── font.woff2 │ ├── _nuxt/ │ │ ├── builds/ │ │ │ └── latest.json │ │ └── entry.xxx.js │ ├── favicon.ico │ └── robots.txt └── deploy-manifest.json ``` ## Compatibilidad de los elementos primitivos de SSR con Amplify La especificación de implementación de Amplify Hosting define un contrato que se corresponde estrechamente con los siguientes elementos primitivos. **Activos estáticos** Proporciona a los marcos la capacidad de alojar archivos estáticos. **Computación** Proporciona a los marcos la capacidad de ejecutar un servidor HTTP de Node.js en el puerto 3000. **Optimización de imágenes** Proporciona a los marcos un servicio para optimizar las imágenes en tiempo de ejecución. **Reglas de enrutamiento** Proporciona a los marcos un mecanismo para asignar las rutas de las solicitudes entrantes a destinos específicos. ## El directorio .amplify-hosting/static Debe colocar en el directorio `.amplify-hosting/static` todos los archivos estáticos de acceso público que estén destinados a distribuirse desde la URL de la aplicación. Los archivos de este directorio se distribuyen a través del elemento primitivo de activos estáticos. Se puede acceder a los archivos estáticos en la raíz (/) de la URL de la aplicación sin hacer ningún cambio en su contenido, nombre de archivo o extensión. Además, los subdirectorios se conservan en la estructura de URL y aparecen antes del nombre del archivo. Por ejemplo, `.amplify-hosting/static/favicon.ico` se distribuirá desde `https://myAppId.amplify-hostingapp.com/favicon.ico` y `.amplify-hosting/static/_nuxt/main.js` se distribuirá desde ` https://myAppId.amplify-hostingapp.com/_nuxt/main.js`. Si un marco admite la posibilidad de modificar la ruta base de la aplicación, debe anteponer la ruta base a los activos estáticos del directorio `.amplify-hosting/static`. Por ejemplo, si la ruta base es `/folder1/folder2`, la salida de la compilación de un activo estático llamado `main.css` será `.amplify-hosting/static/folder1/folder2/main.css`. ## El directorio .amplify-hosting/compute Un único recurso de computación se representa mediante un único subdirectorio denominado `default` que se incluye en el directorio `.amplify-hosting/compute`. La ruta es `.amplify-hosting/compute/default`. Este recurso de computación se asigna al elemento primitivo de computación de Amplify Hosting. El contenido del subdirectorio `default` debe cumplir con las siguientes reglas. + Debe existir un archivo en la raíz del subdirectorio `default` para que sirva como punto de entrada al recurso de computación. + El archivo de punto de entrada debe ser un módulo de Node.js y debe iniciar un servidor HTTP que escuche en el puerto 3000. + Puede colocar otros archivos en el subdirectorio `default` y hacer referencia a ellos desde el código en el archivo de punto de entrada. + El contenido del subdirectorio debe ser independiente. El código del módulo de punto de entrada no puede hacer referencia a ningún módulo de fuera del subdirectorio. Tenga en cuenta que los marcos pueden agrupar su servidor HTTP de la forma que deseen. Si el proceso de computación se puede iniciar con el comando `node server.js`, donde `server.js is` es el nombre del archivo de entrada, desde el subdirectorio, Amplify considera que la estructura del directorio se ajusta a la especificación de implementación. Amplify Hosting agrupa e implementa todos los archivos del subdirectorio `default` en un recurso de computación aprovisionado. Se asignan 512 MB de almacenamiento efímero a cada recurso de computación. Este almacenamiento no se comparte entre las instancias de ejecución, sino que se comparte entre las invocaciones posteriores de la misma instancia de ejecución. Las instancias de ejecución están limitadas a un tiempo máximo de ejecución de 15 minutos y la única ruta en la que se puede escribir dentro de la instancia de ejecución es el directorio `/tmp`. El tamaño sin comprimir de cada paquete de recursos de computación no puede superar los 220 MB. Por ejemplo, el subdirectorio `.amplify/compute/default` no puede superar los 220 MB cuando no está comprimido. ## El archivo .amplify-hosting/deploy-manifest.json Utilice el archivo `deploy-manifest.json` para almacenar los detalles de configuración y los metadatos de una implementación. Como mínimo, un archivo `deploy-manifest.json` debe incluir un atributo `version`, el atributo `routes` con una ruta de método catch-all especificada y el atributo `framework` con los metadatos del marco especificados. En la siguiente definición de objeto se muestra la configuración de un manifiesto de implementación. ``` type DeployManifest = { version: 1; routes: Route[]; computeResources?: ComputeResource[]; imageSettings?: ImageSettings; framework: FrameworkMetadata; }; ``` En los temas siguientes se describen los detalles y el uso de cada atributo del manifiesto de implementación. ### Uso del atributo version El atributo `version` define la versión de la especificación de implementación que se está implementando. Actualmente, la única versión para la especificación de implementación de Amplify Hosting es la versión 1. En el siguiente JSON de ejemplo se muestra el uso del atributo `version`. ``` "version": 1 ``` ### Uso del atributo routes El atributo `routes` permite a los marcos utilizar el elemento primitivo de reglas de enrutamiento de Amplify Hosting. Las reglas de enrutamiento proporcionan un mecanismo para enrutar las rutas de solicitudes entrantes a un destino específico del paquete de implementación. Las reglas de enrutamiento solo dictan el destino de una solicitud entrante y se aplican después de que las reglas de reescritura y redireccionamiento hayan transformado la solicitud. Para obtener más información sobre cómo Amplify Hosting gestiona las reescrituras y los redireccionamientos, consulte [Configuración de redirecciones y reescrituras de una aplicación de Amplify](redirects.md). Las reglas de enrutamiento no reescriben ni transforman la solicitud. Si una solicitud entrante coincide con el patrón de ruta de una ruta, la solicitud se enruta tal cual al destino de la ruta. Las reglas de enrutamiento especificadas en la matriz `routes` deben cumplir con las siguientes reglas. + Se debe especificar una ruta de método catch-all. Una ruta de método catch-all tiene el patrón `/*` que coincide con todas las solicitudes entrantes. + La matriz `routes` puede contener un máximo de 25 elementos. + Debe especificar una ruta `Static` o una ruta `Compute`. + Si especifica una ruta `Static`, el directorio `.amplify-hosting/static` debe existir. + Si especifica una ruta `Compute`, el directorio `.amplify-hosting/compute` debe existir. + Si especifica una ruta `ImageOptimization`, también debe especificar una ruta `Compute`. Es necesario hacerlo porque la optimización de imágenes aún no es compatible con aplicaciones puramente estáticas. En la siguiente definición de objeto se muestra la configuración del objeto `Route`. ``` type Route = { path: string; target: Target; fallback?: Target; } ``` En la siguiente tabla se describen las propiedades del objeto `Route`. | Key | Tipo | Obligatorio | Description (Descripción) | | --- | --- | --- | --- | | path | Cadena | Sí | Define un patrón que coincide con las rutas de las solicitudes entrantes (excepto la cadena de consulta).
La longitud máxima de la ruta es de 255 caracteres.
Una ruta debe empezar por la barra diagonal `/`.
Una ruta puede contener cualquiera de los siguientes caracteres: [A-Z], [a-z], [0-9], [\_-.\*$/\~"'@:\+].
En el caso de la coincidencia de patrones, solo se admiten los siguientes caracteres comodín:[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/amplify/latest/userguide/ssr-deployment-specification.html) | | destino | Target | Sí | Objeto que define el destino al que se debe enrutar la solicitud coincidente.
Si se especifica una ruta `Compute`, debe existir un objeto `ComputeResource` correspondiente.
Si se especifica una ruta `ImageOptimization`, también se debe especificar `imageSettings`. | | fallback | Target | No | Objeto que define el destino de reserva si el destino original devuelve un error 404.
El tipo `target` y el tipo `fallback` no pueden ser iguales para una ruta específica. Por ejemplo, no se permite una acción de reserva de `Static` a `Static`. Las acciones de reserva solo se admiten en el caso de las solicitudes GET que no tienen cuerpo. Si hay un cuerpo en la solicitud, se eliminará durante la acción de reserva. | En la siguiente definición de objeto se muestra la configuración del objeto `Target`. ``` type Target = { kind: TargetKind; src?: string; cacheControl?: string; } ``` En la siguiente tabla se describen las propiedades del objeto `Target`. | Key | Tipo | Obligatorio | Description (Descripción) | | --- | --- | --- | --- | | kind | Targetkind | Sí | `enum` que define el tipo de destino. Los valores válidos son `Static`, `Compute` y `ImageOptimization`. | | src | Cadena | Sí para `Compute`
No para otros elementos primitivos | Cadena que especifica el nombre del subdirectorio en el paquete de implementación que contiene el código ejecutable del elemento primitivo. Válido y obligatorio solo para el elemento primitivo Compute.
El valor debe apuntar a uno de los recursos de computación presentes en el paquete de implementación. En la actualidad, el único valor que se admite para este campo es `default`. | | cacheControl | Cadena | No | Cadena que especifica el valor del encabezado Cache-Control que se va a aplicar a la respuesta. Válido solo para los estáticos y los ImageOptimization primitivos.
Los encabezados personalizados anulan el valor especificado. Para obtener más información sobre los encabezados de cliente de Amplify Hosting, consulte [Configuración de encabezados HTTP personalizados para una aplicación de Amplify](custom-headers.md). Este encabezado Cache-Control solo se aplica a las respuestas correctas con un código de estado establecido en 200 (OK). | En la siguiente definición de objeto se muestra el uso de la enumeración `TargetKind`. ``` enum TargetKind { Static = "Static", Compute = "Compute", ImageOptimization = "ImageOptimization" } ``` En la siguiente lista se especifican los valores válidos de la enumeración `TargetKind`. **Estático** Enruta las solicitudes al elemento primitivo de activos estáticos. **Computación** Enruta las solicitudes al elemento primitivo de computación. **ImageOptimization** Enruta las solicitudes al elemento primitivo de optimización de imágenes. En el siguiente JSON de ejemplo se muestra el uso del atributo `routes` con varias rutas de enrutamiento especificadas. ``` "routes": [ { "path": "/_nuxt/image", "target": { "kind": "ImageOptimization", "cacheControl": "public, max-age=3600, immutable" } }, { "path": "/_nuxt/builds/meta/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/_nuxt/builds/*", "target": { "cacheControl": "public, max-age=1, immutable", "kind": "Static" } }, { "path": "/_nuxt/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }, { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ] ``` Para obtener más información sobre cómo especificar reglas de enrutamiento en el manifiesto de implementación, consulte [Prácticas recomendadas para configurar reglas de enrutamiento](#routing-best-practices). ### Uso del atributo computeResources El atributo `computeResources` permite a los marcos proporcionar metadatos sobre los recursos de computación aprovisionados. Cada recurso de computación debe tener una ruta correspondiente asociada. En la siguiente definición de objeto se muestra el uso del objeto `ComputeResource`. ``` type ComputeResource = { name: string; runtime: ComputeRuntime; entrypoint: string; }; type ComputeRuntime = 'nodejs20.x' | 'nodejs22.x'; ``` En la siguiente tabla se describen las propiedades del objeto `ComputeResource`. | Key | Tipo | Obligatorio | Description (Descripción) | | --- | --- | --- | --- | | name (nombre) | Cadena | Sí | Especifica el nombre del recurso de computación. El nombre debe coincidir con el nombre del subdirectorio que está dentro de `.amplify-hosting/compute directory`.
Para la versión 1 de la especificación de implementación, el único valor válido es `default`. | | tiempo de ejecución | ComputeRuntime | Sí | Define el tiempo de ejecución del recurso de computación aprovisionado.
Los valores válidos son `nodejs20.x` y `nodejs22.x`. | | entrypoint | Cadena | Sí | Especifica el nombre del archivo de inicio desde el que se ejecutará el código para el recurso de computación especificado. El archivo debe estar dentro del subdirectorio que representa un recurso de computación. | Si tiene una estructura de directorios con un aspecto similar al siguiente. ``` .amplify-hosting |---compute | |---default | |---index.js ``` El JSON del atributo `computeResource` tendrá el siguiente aspecto. ``` "computeResources": [ { "name": "default", "runtime": "nodejs20.x", "entrypoint": "index.js", } ] ``` ### Uso del atributo imageSettings El atributo `imageSettings` permite a los marcos personalizar el comportamiento del elemento primitivo de optimización de imágenes, que proporciona una optimización de imágenes bajo demanda en tiempo de ejecución. En la siguiente definición de objeto se muestra el uso del objeto `ImageSettings`. ``` type ImageSettings = { sizes: number[]; domains: string[]; remotePatterns: RemotePattern[]; formats: ImageFormat[]; minumumCacheTTL: number; dangerouslyAllowSVG: boolean; }; type ImageFormat = 'image/avif' | 'image/webp' | 'image/png' | 'image/jpeg'; ``` En la siguiente tabla se describen las propiedades del objeto `ImageSettings`. | Key | Tipo | Obligatorio | Description (Descripción) | | --- | --- | --- | --- | | sizes | Number[] | Sí | Matriz de anchos de imagen admitidos. | | domains | String[] | Sí | Matriz de dominios externos permitidos que pueden utilizar la optimización de imágenes. Deje la matriz vacía para permitir que solo el dominio de implementación utilice la optimización de imágenes. | | remotePatterns | RemotePattern[] | Sí | Matriz de patrones externos permitidos que pueden utilizar la optimización de imágenes. Similar a domains, pero proporciona más control con expresiones regulares (regex). | | formats | ImageFormat[] | Sí | Matriz de formatos de imagen de salida permitidos. | | minimumCacheTTL | Número | Sí | Duración del almacenamiento en caché en segundos para las imágenes optimizadas. | | dangerouslyAllowSVG | Booleano | Sí | Permite introducir imágenes en formato SVG. URLs De forma predeterminada, está deshabilitada por motivos de seguridad. | En la siguiente definición de objeto se muestra el uso del objeto `RemotePattern`. ``` type RemotePattern = { protocol?: 'https'; hostname: string; port?: string; pathname?: string; } ``` En la siguiente tabla se describen las propiedades del objeto `RemotePattern`. | Key | Tipo | Obligatorio | Description (Descripción) | | --- | --- | --- | --- | | protocolo | Cadena | No | Protocolo del patrón remoto permitido. El único valor válido es `https`. | | hostname | Cadena | Sí | Nombre de host del patrón remoto permitido.
Puede especificar un literal o un comodín. Un carácter único “\*” coincide con un único subdominio. Un carácter doble “\*\*” coincide con cualquier cantidad de subdominios. Amplify no permite caracteres comodín generales cuando solo se especifica “\*\*”. | | puerto | Cadena | No | Puerto del patrón remoto permitido. | | pathname | Cadena | No | Nombre de ruta del patrón remoto permitido. | En el siguiente ejemplo se muestra el atributo `imageSettings`. ``` "imageSettings": { "sizes": [ 100, 200 ], "domains": [ "example.com" ], "remotePatterns": [ { "protocol": "https", "hostname": "example.com", "port": "", "pathname": "/**", } ], "formats": [ "image/webp" ], "minumumCacheTTL": 60, "dangerouslyAllowSVG": false } ``` ### Uso del atributo framework Utilice el atributo `framework` para especificar los metadatos del marco. En la siguiente definición de objeto se muestra la configuración del objeto `FrameworkMetadata`. ``` type FrameworkMetadata = { name: string; version: string; } ``` En la siguiente tabla se describen las propiedades del objeto `FrameworkMetadata`. | Key | Tipo | Obligatorio | Description (Descripción) | | --- | --- | --- | --- | | name (nombre) | Cadena | Sí | Nombre del marco. | | versión | Cadena | Sí | Versión del marco.
Debe ser una cadena válida de control de versiones semántico (semver). | ## Prácticas recomendadas para configurar reglas de enrutamiento Las reglas de enrutamiento proporcionan un mecanismo para enrutar las rutas de solicitudes entrantes a destinos específicos del paquete de implementación. En un paquete de implementación, los autores de marcos pueden enviar archivos a la salida de la compilación que se implementan en cualquiera de los siguientes destinos: + **Elemento primitivo de activos estáticos**: los archivos se encuentran en el directorio `.amplify-hosting/static`. + **Elemento primitivo de computación**: los archivos se encuentran en el directorio `.amplify-hosting/compute/default`. Los autores de marcos también proporcionan una matriz de reglas de enrutamiento en el archivo de manifiesto de implementación. Cada regla de la matriz se compara con la solicitud entrante en orden de recorrido secuencial hasta que haya una coincidencia. Cuando hay una regla coincidente, la solicitud se enruta al destino especificado en la regla coincidente. De forma opcional, se puede especificar un destino de reserva para cada regla. Si el destino original devuelve un error 404, la solicitud se enruta al destino de reserva. La especificación de implementación *requiere* que la última regla del orden de recorrido sea una regla de método catch-all. Se especifica una regla de método catch-all con la ruta `/*`. Si la solicitud entrante no coincide con ninguna de las rutas anteriores de la matriz de reglas de enrutamiento, la solicitud se enruta al destino de la regla de método catch-all. En el caso de los marcos de SSR como Nuxt.js, el destino de la regla de método catch-all tiene que ser el elemento primitivo de computación. Esto se debe a que las aplicaciones de SSR tienen páginas representadas del servidor con rutas que no son predecibles en el momento de la compilación. Por ejemplo, si una aplicación Nuxt.js tiene una página en `/blog/[slug]` donde `[slug]` es un parámetro de ruta dinámica. El destino de la regla de método catch-all es la única forma de enrutar las solicitudes a estas páginas. Por el contrario, se pueden usar patrones de ruta específicos para dirigirse a rutas conocidas en el momento de la compilación. Por ejemplo, Nuxt.js distribuye activos estáticos desde la ruta `/_nuxt`. Esto significa que es posible dirigirse a la ruta `/_nuxt/*` mediante una regla de enrutamiento específica que enrute las solicitudes al elemento primitivo de activos estáticos. ### Enrutamiento de carpetas públicas La mayoría de los marcos de SSR ofrecen la posibilidad de distribuir activos estáticos mutables desde una carpeta `public`. Por lo general, los archivos como `favicon.ico` y `robots.txt` se guardan en la carpeta `public` y se distribuyen desde la URL raíz de la aplicación. Por ejemplo, el archivo `favicon.ico` se distribuye desde `https://example.com/favicon.ico`. Tenga en cuenta que no existe un patrón de ruta predecible para estos archivos. El nombre del archivo los dicta casi en su totalidad. La única forma de dirigirse a los archivos de la carpeta `public` consiste en utilizar la ruta de método catch-all. Sin embargo, el destino de la ruta de método catch-all debe ser el elemento primitivo de computación. Recomendamos uno de los siguientes enfoques para administrar la carpeta `public`. 1. Use un patrón de rutas para dirigirse a las rutas de solicitud que contienen extensiones de archivo. Por ejemplo, se puede utilizar ` /*.*` para dirigirse a todas las rutas de solicitud que contienen una extensión de archivo. Tenga en cuenta que este enfoque puede ser poco fiable. Por ejemplo, si hay archivos sin extensiones de archivo en la carpeta `public`, esta regla no se dirige a ellos. Otro problema que hay que tener en cuenta con este enfoque es que la aplicación podría tener páginas con puntos en los nombres. Por ejemplo, la regla `/*.* ` se dirigirá a una página en `/blog/2021/01/01/hello.world`. Esto no es lo ideal, ya que la página no es un activo estático. Sin embargo, puede agregar un destino de reserva a esta regla para garantizar que, cuando se produzca un error 404 del elemento primitivo estático, la solicitud utilice el elemento primitivo de computación como reserva. ``` { "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } } ``` 1. Identifique los archivos de la carpeta `public` en el momento de la compilación y emita una regla de enrutamiento para cada archivo. Este enfoque no es escalable, ya que la especificación de implementación impone un límite de 25 reglas. ``` { "path": "/favicon.ico", "target": { "kind": "Static" } }, { "path": "/robots.txt", "target": { "kind": "Static" } } ``` 1. Recomiende a los usuarios del marco almacenar todos los activos estáticos mutables en una subcarpeta dentro de la carpeta `public`. En el siguiente ejemplo, el usuario puede almacenar todos los activos estáticos mutables dentro de la carpeta `public/assets`. A continuación, se puede utilizar una regla de enrutamiento con el patrón de ruta `/assets/*` para dirigirse a todos los activos estáticos mutables de la carpeta `public/assets`. ``` { "path": "/assets/*", "target": { "kind": "Static" } } ``` 1. Especifique una reserva estática para la ruta de método catch-all. Este enfoque presenta algunos inconvenientes que se describen en más detalle en la siguiente sección [Enrutamiento de reserva de método catch-all](#catchall-fallback-routing). ### Enrutamiento de reserva de método catch-all En el caso de los marcos de SSR como Nuxt.js, donde se especifica una ruta de método catch-all para el destino del elemento primitivo de computación, los autores de los marcos podrían considerar la posibilidad de especificar una reserva estática para la ruta de método catch-all a fin de resolver el problema del enrutamiento de carpetas `public`. Sin embargo, este tipo de regla de enrutamiento interrumpe las páginas 404 representadas del servidor. Por ejemplo, si el usuario final visita una página que no existe, la aplicación devuelve una página 404 con el código de estado 404. Sin embargo, si la ruta de método catch-all tiene una reserva estática, no se devuelve la página 404. En su lugar, la solicitud utiliza el elemento primitivo estático como reserva y, aun así, termina con un código de estado 404, pero no se devuelve la página 404. ``` { "path": "/*", "target": { "kind": "Compute", "src": "default" }, "fallback": { "kind": "Static" } } ``` #### Enrutamiento de rutas base Está previsto que los marcos que ofrecen la posibilidad de modificar la ruta base de la aplicación antepongan la ruta base a los activos estáticos del directorio `.amplify-hosting/static`. Por ejemplo, si la ruta base es `/folder1/folder2`, la salida de la compilación de un activo estático llamado main.css será `.amplify-hosting/static/folder1/folder2/main.css`. Esto significa que las reglas de enrutamiento también deben actualizarse para reflejar la ruta base. Por ejemplo, si la ruta base es `/folder1/folder2`, la regla de enrutamiento de los activos estáticos de la carpeta `public` tendrá el siguiente aspecto. ``` { "path": "/folder1/folder2/*.*", "target": { "kind": "Static" } } ``` Del mismo modo, las rutas del servidor también deben tener la ruta base antepuesta. Por ejemplo, si la ruta base es `/folder1/folder2`, la regla de enrutamiento de la ruta `/api` tendrá el siguiente aspecto. ``` { "path": "/folder1/folder2/api/*", "target": { "kind": "Compute", "src": "default" } } ``` Sin embargo, la ruta base no debe anteponerse a la ruta de método catch-all. Por ejemplo, si la ruta base es `/folder1/folder2`, la ruta de método catch-all seguirá siendo como la siguiente. ``` { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ``` #### Ejemplos de rutas de Nuxt.js A continuación se incluye un archivo `deploy-manifest.json` de ejemplo para una aplicación de Nuxt en el que se muestra cómo especificar las reglas de enrutamiento. ``` { "version": 1, "routes": [ { "path": "/_nuxt/image", "target": { "kind": "ImageOptimization", "cacheControl": "public, max-age=3600, immutable" } }, { "path": "/_nuxt/builds/meta/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/_nuxt/builds/*", "target": { "cacheControl": "public, max-age=1, immutable", "kind": "Static" } }, { "path": "/_nuxt/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }, { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ], "computeResources": [ { "name": "default", "entrypoint": "server.js", "runtime": "nodejs22.x" } ], "framework": { "name": "nuxt", "version": "3.8.1" } } ``` A continuación se incluye un archivo `deploy-manifest.json` de ejemplo para Nuxt en el que se muestra cómo especificar las reglas de enrutamiento, incluidas rutas base. ``` { "version": 1, "routes": [ { "path": "/base-path/_nuxt/image", "target": { "kind": "ImageOptimization", "cacheControl": "public, max-age=3600, immutable" } }, { "path": "/base-path/_nuxt/builds/meta/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/base-path/_nuxt/builds/*", "target": { "cacheControl": "public, max-age=1, immutable", "kind": "Static" } }, { "path": "/base-path/_nuxt/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/base-path/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }, { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ], "computeResources": [ { "name": "default", "entrypoint": "server.js", "runtime": "nodejs22.x" } ], "framework": { "name": "nuxt", "version": "3.8.1" } } ``` Para obtener más información sobre el uso del atributo `routes`, consulte [Uso del atributo routes](#deployment-manifest-routes).