Verwenden der Amplify Hosting-Bereitstellungsspezifikation zur Konfiguration der Build-Ausgabe

Die Amplify Hosting-Bereitstellungsspezifikation ist eine dateisystembasierte Spezifikation, die die Verzeichnisstruktur definiert, die Bereitstellungen für Amplify Hosting erleichtert. Ein Framework kann diese erwartete Verzeichnisstruktur als Ausgabe seines Build-Befehls generieren, sodass das Framework die Service Primitives von Amplify Hosting nutzen kann. Amplify Hosting versteht die Struktur des Bereitstellungspakets und stellt es entsprechend bereit.

Eine Videodemonstration, in der erklärt wird, wie die Bereitstellungsspezifikation verwendet wird, finden Sie unter How to host any website using AWS Amplify on the Amazon Web Services YouTube channel.

Das Folgende ist ein Beispiel für die Ordnerstruktur, die Amplify für das Bereitstellungspaket erwartet. Auf einer höheren Ebene hat es einen Ordner mit dem Namenstatic, einen Ordner mit dem Namen compute und eine Bereitstellungsmanifestdatei mit dem Namendeploy-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

Amplify Sie die SSR primitive Unterstützung

Die Amplify Hosting-Bereitstellungsspezifikation definiert einen Vertrag, der den folgenden Primitiven genau entspricht.

Statische Vermögenswerte

Bietet Frameworks die Möglichkeit, statische Dateien zu hosten.

Datenverarbeitung

Bietet Frameworks die Möglichkeit, einen Node.js HTTP -Server auf Port 3000 auszuführen.

Bildoptimierung

Stellt Frameworks einen Dienst zur Optimierung von Bildern zur Laufzeit zur Verfügung.

Routing-Regeln

Stellt Frameworks einen Mechanismus zur Verfügung, mit dem eingehende Anforderungspfade bestimmten Zielen zugeordnet werden können.

Das Tool .amplify-hosting/static directory

Sie müssen alle öffentlich zugänglichen statischen Dateien, die von der Anwendung aus bereitgestellt werden sollen, URL im .amplify-hosting/static Verzeichnis ablegen. Die Dateien in diesem Verzeichnis werden über das statische Asset-Primitiv bereitgestellt.

Auf statische Dateien kann im Stammverzeichnis (/) der Anwendung zugegriffen werden, URL ohne dass ihr Inhalt, ihr Dateiname oder ihre Erweiterung geändert werden müssen. Darüber hinaus bleiben Unterverzeichnisse in der URL Struktur erhalten und werden vor dem Dateinamen angezeigt. Als Beispiel .amplify-hosting/static/favicon.ico wird bedient von https://myAppId.amplify-hostingapp.com/favicon.ico und .amplify-hosting/static/_nuxt/main.js wird bedient von https://myAppId.amplify-hostingapp.com/_nuxt/main.js

Wenn ein Framework die Möglichkeit unterstützt, den Basispfad der Anwendung zu ändern, muss es den Basispfad den statischen Assets innerhalb des .amplify-hosting/static Verzeichnisses voranstellen. Wenn der Basispfad beispielsweise lautet/folder1/folder2, dann main.css wird die Build-Ausgabe für ein statisches Asset aufgerufen. .amplify-hosting/static/folder1/folder2/main.css

Das Tool .amplify-hosting/compute directory

Eine einzelne Rechenressource wird durch ein einzelnes Unterverzeichnis mit dem Namen repräsentiert, das innerhalb des .amplify-hosting/compute Verzeichnisses default enthalten ist. Der Pfad ist.amplify-hosting/compute/default. Diese Rechenressource ist dem Compute-Primitiv von Amplify Hosting zugeordnet.

Der Inhalt des default Unterverzeichnisses muss den folgenden Regeln entsprechen.

• Im Stammverzeichnis des default Unterverzeichnisses muss eine Datei vorhanden sein, die als Einstiegspunkt zur Rechenressource dient.

• Die Einstiegspunktdatei muss ein Modul Node.js sein und einen HTTP Server starten, der auf Port 3000 lauscht.

• Sie können andere Dateien im default Unterverzeichnis platzieren und über den Code in der Einstiegspunktdatei auf sie verweisen.

• Der Inhalt des Unterverzeichnisses muss eigenständig sein. Der Code im Einstiegspunktmodul kann auf keine Module außerhalb des Unterverzeichnisses verweisen. Beachten Sie, dass Frameworks ihren HTTP Server nach Belieben bündeln können. Wenn der Rechenvorgang mit dem node server.js Befehl, wo sich der Name der Eintragsdatei server.js is befindet, aus dem Unterverzeichnis heraus initiiert werden kann, geht Amplify davon aus, dass die Verzeichnisstruktur der Deployment-Spezifikation entspricht.

Amplify Hosting bündelt und stellt alle Dateien im default Unterverzeichnis auf einer bereitgestellten Rechenressource bereit. Jeder Rechenressource werden 512 MB flüchtiger Speicher zugewiesen. Dieser Speicher wird nicht von allen Ausführungsinstanzen gemeinsam genutzt, sondern von nachfolgenden Aufrufen innerhalb derselben Ausführungsinstanz gemeinsam genutzt. Ausführungsinstanzen sind auf eine maximale Ausführungszeit von 15 Minuten begrenzt, und der einzige beschreibbare Pfad innerhalb der Ausführungsinstanz ist das Verzeichnis. /tmp Die komprimierte Größe jedes Rechenressourcenpakets darf 220 MB nicht überschreiten. Beispielsweise darf das .amplify/compute/default Unterverzeichnis im komprimierten Zustand 220 MB nicht überschreiten.

Das Tool .amplify-hosting/deploy-manifest.json file

Verwenden Sie die deploy-manifest.json Datei, um die Konfigurationsdetails und Metadaten für eine Bereitstellung zu speichern. Eine deploy-manifest.json Datei muss mindestens ein version Attribut, das routes Attribut mit einer angegebenen Catch-All-Route und das Attribut mit den framework angegebenen Framework-Metadaten enthalten.

Die folgende Objektdefinition veranschaulicht die Konfiguration für ein Bereitstellungsmanifest.

type DeployManifest = {
  version: 1;
  routes: Route[];
  computeResources?: ComputeResource[];
  imageSettings?: ImageSettings;
  framework: FrameworkMetadata;
};

In den folgenden Themen werden die Details und die Verwendung der einzelnen Attribute im Bereitstellungsmanifest beschrieben.

Verwenden des Versionsattributs

Das version Attribut definiert die Version der Bereitstellungsspezifikation, die Sie implementieren. Derzeit ist Version 1 die einzige Version für die Amplify Hosting-Bereitstellungsspezifikation. Das folgende JSON Beispiel zeigt die Verwendung des version Attributs.

"version": 1

Verwenden des Route-Attributs

Das routes Attribut ermöglicht es Frameworks, das Primitiv der Amplify Hosting-Routing-Regeln zu nutzen. Routing-Regeln bieten einen Mechanismus zum Weiterleiten eingehender Anforderungspfade an ein bestimmtes Ziel im Bereitstellungspaket. Routing-Regeln geben nur das Ziel einer eingehenden Anfrage vor und werden angewendet, nachdem die Anfrage durch Umschreib- und Umleitungsregeln transformiert wurde. Weitere Informationen darüber, wie Amplify Hosting mit Umschreibungen und Weiterleitungen umgeht, finden Sie unter. Umleitungen und Umschreibungen für eine Amplify-Anwendung einrichten

Routing-Regeln schreiben oder transformieren die Anfrage nicht. Wenn eine eingehende Anfrage dem Pfadmuster für eine Route entspricht, wird die Anfrage unverändert an das Ziel der Route weitergeleitet.

Die im routes Array angegebenen Routing-Regeln müssen den folgenden Regeln entsprechen.

• Es muss eine Sammelroute angegeben werden. Eine Catch-All-Route hat das /* Muster, das allen eingehenden Anfragen entspricht.

• Das routes Array kann maximal 25 Elemente enthalten.

• Sie müssen entweder eine Static Route oder eine Compute Route angeben.

• Wenn Sie eine Static Route angeben, muss das .amplify-hosting/static Verzeichnis existieren.

• Wenn Sie eine Compute Route angeben, muss das .amplify-hosting/compute Verzeichnis existieren.

• Wenn Sie eine ImageOptimization Route angeben, müssen Sie auch eine Compute Route angeben. Dies ist erforderlich, da die Bildoptimierung für rein statische Anwendungen noch nicht unterstützt wird.

Die folgende Objektdefinition veranschaulicht die Konfiguration für das Route Objekt.

type Route = {
  path: string;
  target: Target;
  fallback?: Target;
}

In der folgenden Tabelle werden die Eigenschaften des Route Objekts beschrieben.

Schlüssel	Typ	Erforderlich	Beschreibung
Pfad	String	Ja	Definiert ein Muster, das den Pfaden eingehender Anfragen entspricht (ohne Querystring). Die maximale Pfadlänge beträgt 255 Zeichen. Ein Pfad muss mit einem Schrägstrich / beginnen. Ein Pfad kann jedes der folgenden Zeichen enthalten: [A-Z], [a-z], [0-9], [_-.*$/~"'@: +]. Für den Mustervergleich werden nur die folgenden Platzhalterzeichen unterstützt: *(entspricht 0 oder mehr Zeichen) Das /* Muster wird als Catch-All-Muster bezeichnet und entspricht allen eingehenden Anfragen.
Ziel	Ziel	Ja	Ein Objekt, das das Ziel definiert, an das die übereinstimmende Anfrage weitergeleitet werden soll. Wenn eine Compute Route angegeben ist, ComputeResource muss eine entsprechende vorhanden sein. Wenn eine ImageOptimization Route angegeben ist, imageSettings muss diese ebenfalls angegeben werden.
Reserve	Ziel	Nein	Ein Objekt, das das Ziel definiert, auf das zurückgegriffen werden soll, falls das ursprüngliche Ziel einen 404-Fehler zurückgibt. Die target Art und die fallback Art können für eine angegebene Route nicht identisch sein. Beispielsweise ist ein Fallback von Static bis nicht Static zulässig. Fallbacks werden nur für GET Anfragen unterstützt, die keinen Hauptteil haben. Wenn in der Anfrage ein Text vorhanden ist, wird er während des Fallbacks gelöscht.

Die folgende Objektdefinition veranschaulicht die Konfiguration für das Target Objekt.

type Target = {
  kind: TargetKind;
  src?: string;
  cacheControl?: string;
}

In der folgenden Tabelle werden die Eigenschaften des Target Objekts beschrieben.

Schlüssel	Typ	Erforderlich	Beschreibung
nett	Art der Zielperson	Ja	Und enum das definiert den Zieltyp. Gültige Werte sind Static, Compute und ImageOptimization.
src	String	Ja für Compute Nein für andere Primitive	Eine Zeichenfolge, die den Namen des Unterverzeichnisses im Bereitstellungspaket angibt, das den ausführbaren Code des Primitivs enthält. Gültig und nur für das Compute-Primitiv erforderlich. Der Wert muss auf eine der Rechenressourcen verweisen, die im Bereitstellungspaket vorhanden sind. Derzeit ist der einzige unterstützte Wert für dieses Felddefault.
cacheControl	String	Nein	Eine Zeichenfolge, die den Wert des Cache-Control-Headers angibt, der auf die Antwort angewendet werden soll. Gilt nur für Static und Primitive. ImageOptimization Der angegebene Wert wird durch benutzerdefinierte Header überschrieben. Weitere Informationen zu den Kunden-Headern von Amplify Hosting finden Sie unter. Benutzerdefinierte Header für eine Amplify-App einrichten Anmerkung Dieser Cache-Control-Header wird nur auf erfolgreiche Antworten angewendet, deren Statuscode auf 200 (OK) gesetzt ist.

Die folgende Objektdefinition veranschaulicht die Verwendung der AufzählungTargetKind.

enum TargetKind {
  Static = "Static",
  Compute = "Compute",
  ImageOptimization = "ImageOptimization"
}

Die folgende Liste spezifiziert die gültigen Werte für die TargetKind Aufzählung.

Statisch

Leitet Anfragen an das statische Asset-Primitiv weiter.

Datenverarbeitung

Leitet Anfragen an das Compute-Primitiv weiter.

ImageOptimization

Leitet Anfragen an das Bildoptimierungs-Primitiv weiter.

Das folgende JSON Beispiel zeigt die Verwendung des routes Attributs mit mehreren angegebenen Routing-Regeln.

"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"
      }
    }
  ]

Weitere Informationen zur Angabe von Routingregeln in Ihrem Bereitstellungsmanifest finden Sie unter Bewährte Methoden für die Konfiguration von Routing-Regeln

Verwenden des computeResources Attributs

Das computeResources Attribut ermöglicht es Frameworks, Metadaten zu den bereitgestellten Rechenressourcen bereitzustellen. Jeder Rechenressource muss eine entsprechende Route zugeordnet sein.

Die folgende Objektdefinition demonstriert die Verwendung für das ComputeResource Objekt.

type ComputeResource = {
  name: string;
  runtime: ComputeRuntime;
  entrypoint: string;
};

type ComputeRuntime = 'nodejs16.x' | 'nodejs18.x' | 'nodejs20.x';

In der folgenden Tabelle werden die Eigenschaften des ComputeResource Objekts beschrieben.

Schlüssel	Typ	Erforderlich	Beschreibung
name	String	Ja	Gibt den Namen der Rechenressource an. Der Name muss mit dem Namen des Unterverzeichnisses innerhalb von übereinstimmen. .amplify-hosting/compute directory Für Version 1 der Bereitstellungsspezifikation ist default der einzig gültige Wert.
runtime	ComputeRuntime	Ja	Definiert die Laufzeit für die bereitgestellte Rechenressource. Gültige Werte sind nodejs16.x, nodejs18.x und nodejs20.x.
Einstiegspunkt	String	Ja	Gibt den Namen der Startdatei an, von der aus Code für die angegebene Rechenressource ausgeführt wird. Die Datei muss sich in dem Unterverzeichnis befinden, das eine Rechenressource darstellt.

Wenn Sie eine Verzeichnisstruktur haben, die wie folgt aussieht.

.amplify-hosting
|---compute
|   |---default
|       |---index.js

Das JSON für das computeResource Attribut wird wie folgt aussehen.

"computeResources": [
    {
      "name": "default",
      "runtime": "nodejs16.x",
      "entrypoint": "index.js",
    }
  ]

Verwenden des imageSettings Attributs

Das imageSettings Attribut ermöglicht es Frameworks, das Verhalten des Bildoptimierungsprimitivs anzupassen, das eine On-Demand-Optimierung von Bildern zur Laufzeit ermöglicht.

Die folgende Objektdefinition veranschaulicht die Verwendung des ImageSettings Objekts.

type ImageSettings = {
  sizes: number[];
  domains: string[];
  remotePatterns: RemotePattern[];
  formats: ImageFormat[];
  minumumCacheTTL: number;
  dangerouslyAllowSVG: boolean;
};

type ImageFormat = 'image/avif' | 'image/webp' | 'image/png' | 'image/jpeg';

In der folgenden Tabelle werden die Eigenschaften des ImageSettings Objekts beschrieben.

Schlüssel	Typ	Erforderlich	Beschreibung
Größen	Nummer []	Ja	Eine Reihe unterstützter Bildbreiten.
domains	Zeichenfolge []	Ja	Eine Reihe zulässiger externer Domänen, für die die Bildoptimierung verwendet werden kann. Lassen Sie das Array leer, damit nur die Bereitstellungsdomäne die Bildoptimierung verwenden kann.
remotePatterns	RemotePattern[]	Ja	Eine Reihe zulässiger externer Muster, für die die Bildoptimierung verwendet werden kann. Ähnlich wie Domänen, bietet jedoch mehr Kontrolle mit regulären Ausdrücken (Regex).
Formate	ImageFormat[]	Ja	Eine Reihe von zulässigen Ausgabebildformaten.
minimumCacheTTL	Zahl	Ja	Die Cache-Dauer in Sekunden für die optimierten Bilder.
dangerouslyAllowSVG	Boolesch	Ja	Ermöglicht das SVG EingabebildURLs. Dies ist aus Sicherheitsgründen standardmäßig deaktiviert.

Die folgende Objektdefinition demonstriert die Verwendung für das RemotePattern Objekt.

type RemotePattern = {
  protocol?: 'http' | 'https';
  hostname: string;
  port?: string;
  pathname?: string;
}

In der folgenden Tabelle werden die Eigenschaften des RemotePattern Objekts beschrieben.

Schlüssel	Typ	Erforderlich	Beschreibung
Protokoll	String	Nein	Das Protokoll des zulässigen Remote-Patterns. Gültige Werte sind http oder https.
hostname	String	Ja	Der Hostname des zulässigen Remote-Patterns. Sie können einen Literalwert oder einen Platzhalter angeben. Ein einzelnes `*` entspricht einer einzelnen Subdomain. Ein doppeltes `**` entspricht einer beliebigen Anzahl von Subdomains. Amplify erlaubt keine pauschalen Platzhalter, wenn nur `**` angegeben ist.
port	String	Nein	Der Port des erlaubten Remote-Musters.
Pfadname	String	Nein	Der Pfadname des zulässigen Remote-Patterns.

Das folgende Beispiel demonstriert das imageSettings Attribut.

"imageSettings": { 
    "sizes": [
      100,
      200
    ],
    "domains": [
      "example.com"
    ],
    "remotePatterns": [
      {
        "protocol": "https",
        "hostname": "example.com",
        "port": "",
        "pathname": "/**",
      }
    ],
    "formats": [
      "image/webp"
    ],
    "minumumCacheTTL": 60,
    "dangerouslyAllowSVG": false
  }

Verwenden des Framework-Attributs

Verwenden Sie das framework Attribut, um Framework-Metadaten anzugeben.

Die folgende Objektdefinition veranschaulicht die Konfiguration für das FrameworkMetadata Objekt.

type FrameworkMetadata = {
  name: string;
  version: string;
}

In der folgenden Tabelle werden die Eigenschaften des FrameworkMetadata Objekts beschrieben.

Schlüssel	Typ	Erforderlich	Beschreibung
name	String	Ja	Der Name des Frameworks.
version	String	Ja	Die Version des Frameworks. Es muss sich um eine gültige semantische Versionierungszeichenfolge (Semver) handeln.

Bewährte Methoden für die Konfiguration von Routing-Regeln

Routingregeln bieten einen Mechanismus zum Weiterleiten eingehender Anforderungspfade an bestimmte Ziele im Bereitstellungspaket. In einem Bereitstellungspaket können Framework-Autoren Dateien an die Build-Ausgabe ausgeben, die für eines der folgenden Ziele bereitgestellt werden:

• Primitiv für statische Assets — Dateien sind im .amplify-hosting/static Verzeichnis enthalten.

• Compute Primitive — Dateien sind im .amplify-hosting/compute/default Verzeichnis enthalten.

Framework-Autoren stellen in der Deploy-Manifestdatei auch eine Reihe von Routing-Regeln bereit. Jede Regel im Array wird nacheinander mit der eingehenden Anfrage abgeglichen, bis eine Übereinstimmung gefunden wird. Wenn es eine passende Regel gibt, wird die Anfrage an das in der Abgleichsregel angegebene Ziel weitergeleitet. Optional kann für jede Regel ein Fallback-Ziel angegeben werden. Wenn das ursprüngliche Ziel einen 404-Fehler zurückgibt, wird die Anfrage an das Ausweichziel weitergeleitet.

Gemäß der Bereitstellungsspezifikation muss es sich bei der letzten Regel in der Durchlaufreihenfolge um eine Sammelregel handeln. Eine Catch-All-Regel wird mit dem /* Pfad angegeben. Wenn die eingehende Anfrage mit keiner der vorherigen Routen im Routingregel-Array übereinstimmt, wird die Anfrage an das Ziel der Catch-All-Regel weitergeleitet.

Für Frameworks wie SSR Nuxt.js, das Ziel der Catch-All-Regel muss das Compute-Primitiv sein. Das liegt daran, dass SSR Anwendungen serverseitig gerenderte Seiten mit Routen haben, die zum Zeitpunkt der Erstellung nicht vorhersehbar sind. Zum Beispiel, wenn ein Nuxt.js Die Anwendung hat eine Seite/blog/[slug], auf der [slug] sich ein dynamischer Routenparameter befindet. Das Ziel der Catch-All-Regel ist die einzige Möglichkeit, Anfragen an diese Seiten weiterzuleiten.

Im Gegensatz dazu können spezifische Pfadmuster verwendet werden, um auf Routen zu zielen, die zum Zeitpunkt der Erstellung bekannt sind. Zum Beispiel Nuxt.js stellt statische Elemente aus dem /_nuxt Pfad bereit. Das bedeutet, dass auf den /_nuxt/* Pfad eine bestimmte Routing-Regel angewendet werden kann, die Anfragen an das statische Asset-Primitiv weiterleitet.

Routing öffentlicher Ordner

Die meisten SSR Frameworks bieten die Möglichkeit, veränderbare statische Assets aus einem public Ordner bereitzustellen. Dateien wie favicon.ico und robots.txt werden normalerweise im public Ordner gespeichert und vom Stammverzeichnis URL der Anwendung aus bereitgestellt. Die favicon.ico Datei wird beispielsweise von bereitgestellthttps://example.com/favicon.ico. Beachten Sie, dass es für diese Dateien kein vorhersehbares Pfadmuster gibt. Sie werden fast ausschließlich durch den Dateinamen bestimmt. Die einzige Möglichkeit, Dateien innerhalb des public Ordners als Ziel zu verwenden, besteht darin, die Catch-All-Route zu verwenden. Das Ziel der Catch-All-Route muss jedoch das Compute-Primitiv sein.

Wir empfehlen einen der folgenden Ansätze für die Verwaltung Ihres public Ordners.

1. Verwenden Sie ein Pfadmuster, um auf Anforderungspfade zu zielen, die Dateierweiterungen enthalten. Sie können es beispielsweise als Ziel für alle Anforderungspfade verwenden /*.*, die eine Dateierweiterung enthalten.

   Beachten Sie, dass dieser Ansatz unzuverlässig sein kann. Wenn der public Ordner beispielsweise Dateien ohne Dateierweiterungen enthält, fallen sie nicht unter diese Regel. Ein weiteres Problem, das Sie bei diesem Ansatz beachten sollten, ist, dass die Anwendung Seiten mit Punkten im Namen enthalten kann. Beispielsweise /blog/2021/01/01/hello.world wird die /*.* Regel als Zielseite für eine Seite verwendet. Dies ist nicht ideal, da es sich bei der Seite nicht um ein statisches Asset handelt. Sie können dieser Regel jedoch ein Fallback-Ziel hinzufügen, um sicherzustellen, dass bei einem 404-Fehler des statischen Primitivs die Anfrage auf das Compute-Primitiv zurückfällt.

   {
       "path": "/*.*",
       "target": {
           "kind": "Static"
       },
       "fallback": {
           "kind": "Compute",
           "src": "default"
       }
   }

2. Identifizieren Sie bei der Erstellung die Dateien im public Ordner und geben Sie für jede Datei eine Routing-Regel aus. Dieser Ansatz ist nicht skalierbar, da die Bereitstellungsspezifikation eine Obergrenze von 25 Regeln vorschreibt.

   {
       "path": "/favicon.ico",
       "target": {
           "kind": "Static"
       }
   },
   {
       "path": "/robots.txt",
       "target": {
           "kind": "Static"
       }
   }

3. Empfehlen Sie Ihren Framework-Benutzern, alle veränderbaren statischen Assets in einem Unterordner innerhalb des public Ordners zu speichern.

   Im folgenden Beispiel kann der Benutzer alle veränderlichen statischen Assets im Ordner speichern. public/assets Anschließend /assets/* kann eine Routing-Regel mit dem Pfadmuster verwendet werden, um auf alle veränderbaren statischen Assets innerhalb des public/assets Ordners abzuzielen.

   {
       "path": "/assets/*",
       "target": {
           "kind": "Static"
       }
   }

4. Geben Sie einen statischen Fallback für die Catch-All-Route an. Dieser Ansatz hat Nachteile, die im nächsten Abschnitt ausführlicher beschrieben werden. Catch-All-Fallback-Routing

Catch-All-Fallback-Routing

Für SSR Frameworks wie Nuxt.js, wo eine Catch-All-Route für das Compute-Primitivziel angegeben wird, könnten Framework-Autoren erwägen, einen statischen Fallback für die Catch-All-Route anzugeben, um das Ordnerrouting-Problem zu lösen. public Diese Art von Routing-Regel verstößt jedoch gegen serverseitig gerenderte 404-Seiten. Wenn der Endbenutzer beispielsweise eine Seite besucht, die nicht existiert, rendert die Anwendung eine 404-Seite mit dem Statuscode 404. Wenn die Catch-All-Route jedoch einen statischen Fallback hat, wird die 404-Seite nicht gerendert. Stattdessen fällt die Anfrage auf das statische Primitiv zurück und endet immer noch mit einem 404-Statuscode, aber die 404-Seite wird nicht gerendert.

{
    "path": "/*",
    "target": {
        "kind": "Compute",
        "src": "default"
    },
    "fallback": {
        "kind": "Static"
    }
}

Basispfad-Routing

Von Frameworks, die die Möglichkeit bieten, den Basispfad der Anwendung zu ändern, wird erwartet, dass sie den Basispfad den statischen Assets innerhalb des .amplify-hosting/static Verzeichnisses voranstellen. Wenn der Basispfad beispielsweise lautet/folder1/folder2, dann lautet die Build-Ausgabe für ein statisches Asset namens main.css. .amplify-hosting/static/folder1/folder2/main.css

Das bedeutet, dass auch die Routing-Regeln aktualisiert werden müssen, um den Basispfad widerzuspiegeln. Wenn der Basispfad beispielsweise lautet/folder1/folder2, dann sieht die Routing-Regel für die statischen Objekte im public Ordner wie folgt aus.

{
    "path": "/folder1/folder2/*.*",
    "target": {
        "kind": "Static"
    }
}

In ähnlicher Weise muss auch serverseitigen Routen der Basispfad vorangestellt werden. Wenn der Basispfad beispielsweise lautet/folder1/folder2, dann sieht die Routing-Regel für die /api Route wie folgt aus.

{
    "path": "/folder1/folder2/api/*",
    "target": {
        "kind": "Compute",
        "src": "default"
    }
}

Der Basispfad sollte jedoch nicht der Sammelroute vorangestellt werden. Wenn der Basispfad beispielsweise lautet/folder1/folder2, bleibt die Catch-All-Route wie folgt.

{
    "path": "/*",
    "target": {
        "kind": "Compute",
        "src": "default"
    }
}

Beispiele für Routen in Nuxt.js

Im Folgenden finden Sie eine deploy-manifest.json Beispieldatei für eine Nuxt-Anwendung, die zeigt, wie Routing-Regeln angegeben werden.

{
  "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": "nodejs18.x"
    }
  ],
  "framework": {
    "name": "nuxt",
    "version": "3.8.1"
  }
}

Im Folgenden finden Sie eine deploy-manifest.json Beispieldatei für Nuxt, die zeigt, wie Routing-Regeln einschließlich Basispfaden angegeben werden.

{
  "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": "nodejs18.x"
    }
  ],
  "framework": {
    "name": "nuxt",
    "version": "3.8.1"
  }
}

Weitere Informationen zur Verwendung des routes Attributs finden Sie unterVerwenden des Route-Attributs.