Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # GraphQL-Typreferenz Skalare Typen in GraphQL repräsentieren primitive Blattwerte in einem GraphQL-Schema. Dies sind die grundlegendsten Datentypen, die zu einem einzigen Wert aufgelöst werden. Im Gegensatz zu Objekttypen können Skalartypen keine Unterfelder haben. GraphQL enthält eine Reihe von standardmäßigen Skalartypen: + **Int**: Eine 32-Bit-Ganzzahl mit Vorzeichen + **Float**: Ein Gleitkommawert mit doppelter Genauigkeit mit Vorzeichen + **Zeichenfolge: Eine UTF-8-Zeichenfolge** + **Boolean**: Ein wahrer oder falscher Wert + **ID**: Eine eindeutige Kennung, die häufig zum erneuten Abrufen eines Objekts oder als Schlüssel für einen Cache verwendet wird Diese skalaren Typen dienen als Bausteine für komplexere Typen in Ihrem Schema. Sie werden verwendet, um Felder zu definieren, die einfache, singuläre Werte enthalten. Zusätzlich zu diesen integrierten Skalaren stehen Ihnen zusätzliche Skalare für verschiedene Anwendungsfälle zur AWS AppSync Verfügung. Schnittstellen und Unions in GraphQL sind abstrakte Typen, die ein flexibles und erweiterbares Schemadesign ermöglichen. Sie bieten Mechanismen zum Gruppieren verwandter Typen und ermöglichen polymorphe Abfragen. Eine Schnittstelle in GraphQL ist ein abstrakter Typ, der eine Reihe von Feldern definiert, die ein Typ enthalten muss, um die Schnittstelle zu implementieren. Es dient als Vertrag für Objekte, indem es einen gemeinsamen Satz von Feldern spezifiziert, über den implementierende Typen verfügen müssen. Schnittstellen sind nützlich, wenn Sie ein Objekt oder ein Feld zurückgeben möchten, das mehrere verschiedene Typen haben kann, aber dennoch einige garantierte Felder hat. Im Gegensatz dazu stellt eine Union in GraphQL einen Typ dar, der einer von mehreren Objekttypen sein könnte, definiert aber keine gemeinsamen Felder zwischen diesen Typen. Unions sind hilfreich, wenn Sie ein Feld zurückgeben müssen, das mehrere Typen haben kann, und diese Typen haben nicht unbedingt gemeinsame Felder. Sowohl Interfaces als auch Unions sind besonders nützlich in Szenarien, in denen ein Feld möglicherweise unterschiedliche Datentypen zurückgibt, sodass Clients auf der Grundlage des zurückgegebenen Typs nach bestimmten Feldern abfragen können. Dieser Abschnitt dient als Referenz für Schematypen. **Topics** + [Skalare Typen in GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/scalars.html) + [Schnittstellen und Unions in GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/interfaces-and-unions.html) # Skalare Typen in GraphQL Ein GraphQL-Objekttyp hat einen Namen und Felder, und diese Felder können Unterfelder haben. Letztlich müssen die Felder eines Objekttyps in *skalare* Typen aufgelöst werden, die die Blätter der Abfrage darstellen. Weitere Informationen zu Objekttypen und Skalaren finden Sie unter [Schemas and types](https://graphql.org/learn/schema/) auf der GraphQL-Website. Zusätzlich zum Standardsatz von GraphQL-Skalaren können Sie damit AWS AppSync auch die **dienstdefinierten** Skalare verwenden, die mit dem Präfix beginnen. *AWS* AWS AppSync unterstützt nicht die Erstellung von **benutzerdefinierten (benutzerdefinierten**) Skalaren. Sie müssen entweder den Standard oder *AWS*Skalare verwenden. Sie können es nicht *AWS*als Präfix für benutzerdefinierte Objekttypen verwenden. Der folgende Abschnitt ist eine Referenz für die Schematypisierung. ## Standard-Skalare GraphQL definiert die folgenden Standardskalare: ### Liste der Standard-Skalare `ID` Ein eindeutiger Bezeichner für ein Objekt. Dieser Skalar ist wie ein serialisiert, soll `String` aber nicht für Menschen lesbar sein. `String` Eine UTF-8-Zeichenfolge. `Int` Ein ganzzahliger Wert zwischen - (2 31) und 2 31 -1. `Float` Ein IEEE 754-Gleitkommawert. `Boolean` Ein boolescher Wert, entweder `true` oder `false`. ## AWS AppSync Skalare AWS AppSync definiert die folgenden Skalare: ### AWS AppSync Liste der Skalare `AWSDate` Eine erweiterte [ISO 8601-Datumszeichenfolge](https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates) im Format. `YYYY-MM-DD` `AWSTime` Eine erweiterte [ISO 8601-Zeitzeichenfolge](https://en.wikipedia.org/wiki/ISO_8601#Times) im Format. `hh:mm:ss.sss` `AWSDateTime` Eine erweiterte [ISO 8601-Datums- und Uhrzeitzeichenfolge](https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations) im Format. `YYYY-MM-DDThh:mm:ss.sssZ` **Anmerkung** Die `AWSDateTime` Skalare `AWSDate``AWSTime`, und können optional einen [Zeitzonen-Offset](https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators) enthalten. Zum Beispiel `1970-01-01+05:30` sind die Werte `1970-01-01Z``1970-01-01-07:00`, und alle gültig für`AWSDate`. Der Zeitzonen-Offset muss entweder `Z` (UTC) oder ein Offset in Stunden und Minuten (und optional in Sekunden) sein. Beispiel, `±hh:mm:ss`. Das Sekundenfeld im Zeitzonen-Offset wird als gültig angesehen, obwohl es nicht Teil des ISO 8601-Standards ist. `AWSTimestamp` Ein ganzzahliger Wert, der die Anzahl der Sekunden davor oder danach `1970-01-01-T00:00Z` angibt. `AWSEmail` Eine E-Mail-Adresse in dem in [RFC 822](https://tools.ietf.org/html/rfc822) definierten Format`local-part@domain-part`. `AWSJSON` Eine JSON-Zeichenfolge. Jedes gültige JSON-Konstrukt wird automatisch analysiert und als Zuordnungen, Listen oder Skalarwerte und nicht als wörtliche Eingabezeichenfolgen in den Resolver-Code geladen. Zeichenketten ohne Anführungszeichen oder anderweitig ungültiges JSON führen zu einem GraphQL-Validierungsfehler. `AWSPhone` Eine Telefonnummer. Dieser Wert wird als Zeichenfolge gespeichert. Telefonnummern können entweder Leerzeichen oder Bindestriche enthalten, um Zifferngruppen voneinander zu trennen. Bei Telefonnummern ohne Landesvorwahl wird davon ausgegangen, dass es sich um US-/nordamerikanische Nummern handelt, die dem [North American Numbering](https://en.wikipedia.org/wiki/North_American_Numbering_Plan) Plan (NANP) entsprechen. `AWSURL` [Eine URL gemäß der Definition in RFC 1738.](https://tools.ietf.org/html/rfc1738) Zum Beispiel oder. `https://www.amazon.com/dp/B000NZW3KC/` `mailto:example@example.com` URLsmuss ein Schema (`http`,`mailto`) enthalten und darf nicht zwei Schrägstriche (`//`) im Pfadteil enthalten. `AWSIPAddress` Eine gültige IPv4 IPv6 Oder-Adresse. IPv4 Adressen werden in Vierpunkt-Notation () erwartet. `123.12.34.56` IPv6 Adressen werden in einem Format ohne Klammern und durch Doppelpunkte getrennt erwartet (). `1a2b:3c4b::1234:4567` Sie können ein optionales CIDR-Suffix (`123.45.67.89/16`) angeben, um die Subnetzmaske anzugeben. ## Beispiel für die Verwendung eines Schemas Das folgende GraphQL-Beispielschema verwendet alle benutzerdefinierten Skalare als „Objekt“ und zeigt die Resolver-Anforderungs- und Antwortvorlagen für grundlegende Put-, Get- und List-Operationen. Schließlich zeigt das Beispiel, wie Sie dies beim Ausführen von Abfragen und Mutationen verwenden können. ``` type Mutation { putObject( email: AWSEmail, json: AWSJSON, date: AWSDate, time: AWSTime, datetime: AWSDateTime, timestamp: AWSTimestamp, url: AWSURL, phoneno: AWSPhone, ip: AWSIPAddress ): Object } type Object { id: ID! email: AWSEmail json: AWSJSON date: AWSDate time: AWSTime datetime: AWSDateTime timestamp: AWSTimestamp url: AWSURL phoneno: AWSPhone ip: AWSIPAddress } type Query { getObject(id: ID!): Object listObjects: [Object] } schema { query: Query mutation: Mutation } ``` So `putObject` könnte eine Anforderungsvorlage für aussehen. A `putObject` verwendet eine `PutItem` Operation, um ein Element in Ihrer Amazon DynamoDB-Tabelle zu erstellen oder zu aktualisieren. Beachten Sie, dass dieser Codeausschnitt keine konfigurierte Amazon DynamoDB-Tabelle als Datenquelle hat. Dies wird nur als Beispiel verwendet: ``` { "version" : "2017-02-28", "operation" : "PutItem", "key" : { "id": $util.dynamodb.toDynamoDBJson($util.autoId()), }, "attributeValues" : $util.dynamodb.toMapValuesJson($ctx.args) } ``` Die Antwortvorlage für `putObject` gibt die Ergebnisse zurück: ``` $util.toJson($ctx.result) ``` So `getObject` könnte eine Anforderungsvorlage für aussehen. A `getObject` verwendet eine `GetItem` Operation, um eine Reihe von Attributen für das Element zurückzugeben, wenn der Primärschlüssel angegeben ist. Beachten Sie, dass dieser Codeausschnitt keine konfigurierte Amazon DynamoDB-Tabelle als Datenquelle hat. Dies wird nur als Beispiel verwendet: ``` { "version": "2017-02-28", "operation": "GetItem", "key": { "id": $util.dynamodb.toDynamoDBJson($ctx.args.id), } } ``` Die Antwortvorlage für `getObject` gibt die Ergebnisse zurück: ``` $util.toJson($ctx.result) ``` So `listObjects` könnte eine Anforderungsvorlage für aussehen. A `listObjects` verwendet eine `Scan` Operation, um ein oder mehrere Elemente und Attribute zurückzugeben. Beachten Sie, dass dieser Codeausschnitt keine konfigurierte Amazon DynamoDB-Tabelle als Datenquelle hat. Dies wird nur als Beispiel verwendet: ``` { "version" : "2017-02-28", "operation" : "Scan", } ``` Die Antwortvorlage für `listObjects` gibt die Ergebnisse zurück: ``` $util.toJson($ctx.result.items) ``` Im Folgenden finden Sie einige Beispiele für die Verwendung dieses Schemas mit GraphQL-Abfragen: ``` mutation CreateObject { putObject(email: "example@example.com" json: "{\"a\":1, \"b\":3, \"string\": 234}" date: "1970-01-01Z" time: "12:00:34." datetime: "1930-01-01T16:00:00-07:00" timestamp: -123123 url:"https://amazon.com" phoneno: "+1 555 764 4377" ip: "127.0.0.1/8" ) { id email json date time datetime url timestamp phoneno ip } } query getObject { getObject(id:"0d97daf0-48e6-4ffc-8d48-0537e8a843d2"){ email url timestamp phoneno ip } } query listObjects { listObjects { json date time datetime } } ``` # Schnittstellen und Unions in GraphQL Das GraphQL-Typsystem unterstützt [Schnittstellen](https://graphql.org/learn/schema/#interfaces). Eine Schnittstelle stellt eine bestimmte Gruppe von Feldern dar, die ein Typ umfassen muss, um die Schnittstelle zu implementieren. Das GraphQL-Typsystem unterstützt auch [Unions](https://graphql.org/learn/schema/#union-types). Vereinigungen sind weitgehend identisch mit Schnittstellen, definieren aber keinen gemeinsamen Satz von Feldern. Vereinigungen werden in der Regel gegenüber Schnittstellen bevorzugt, wenn die möglichen Typen keine gemeinsame logische Hierarchie besitzen. Der folgende Abschnitt ist eine Referenz für die Schematypisierung. ## Beispiele für Benutzeroberflächen Wir könnten eine `Event` Schnittstelle darstellen, die jede Art von Aktivität oder Zusammenkunft von Menschen darstellt. Einige mögliche Ereignistypen sind `Concert``Conference`,, und`Festival`. All diese Typen haben gemeinsame Merkmale: Name, Veranstaltungsort sowie Start- und Enddatum. Auch bei diesen Typen gibt es Unterschiede. Bei einer `Conference` handelt es sich um eine Liste von Rednern und Workshops, bei `Concert` einer tritt eine Band auf. In der Schema Definition Language (SDL) ist die `Event` Schnittstelle wie folgt definiert: ``` interface Event { id: ID! name : String! startsAt: String endsAt: String venue: Venue minAgeRestriction: Int } ``` Und jeder der Typen implementiert die `Event` Schnittstelle wie folgt: ``` type Concert implements Event { id: ID! name: String! startsAt: String endsAt: String venue: Venue minAgeRestriction: Int performingBand: String } type Festival implements Event { id: ID! name: String! startsAt: String endsAt: String venue: Venue minAgeRestriction: Int performers: [String] } type Conference implements Event { id: ID! name: String! startsAt: String endsAt: String venue: Venue minAgeRestriction: Int speakers: [String] workshops: [String] } ``` Schnittstellen sind nützlich zur Darstellung von Elementen, die in Form unterschiedlicher Typen auftreten können. Zum Beispiel könnten wir nach allen Ereignissen an einem bestimmten Veranstaltungsort suchen. Fügen wir nun folgendermaßen ein `findEventsByVenue`-Feld zum Schema hinzu: ``` schema { query: Query } type Query { # Retrieve Events at a specific Venue findEventsAtVenue(venueId: ID!): [Event] } type Venue { id: ID! name: String address: String maxOccupancy: Int } type Concert implements Event { id: ID! name: String! startsAt: String endsAt: String venue: Venue minAgeRestriction: Int performingBand: String } interface Event { id: ID! name: String! startsAt: String endsAt: String venue: Venue minAgeRestriction: Int } type Festival implements Event { id: ID! name: String! startsAt: String endsAt: String venue: Venue minAgeRestriction: Int performers: [String] } type Conference implements Event { id: ID! name: String! startsAt: String endsAt: String venue: Venue minAgeRestriction: Int speakers: [String] workshops: [String] } ``` Das `findEventsByVenue` gibt eine Liste von zurück`Event`. Da GraphQL-Schnittstellenfelder von allen Implementierungstypen verwendet werden, können Sie jedes beliebige Feld der `Event`-Schnittstelle auswählen (`id`, `name`, `startsAt`, `endsAt`, `venue` und `minAgeRestriction`). Alternativ können Sie mit GraphQL-[Fragmenten](https://graphql.org/learn/queries/#fragments) auf die Felder jedes Implementierungstyps zugreifen, sofern Sie den Typ angeben. Schauen wir uns ein Beispiel für eine GraphQL-Abfrage an, die die Schnittstelle verwendet. ``` query { findEventsAtVenue(venueId: "Madison Square Garden") { id name minAgeRestriction startsAt ... on Festival { performers } ... on Concert { performingBand } ... on Conference { speakers workshops } } } ``` Die vorherige Abfrage gibt eine einzige Ergebnisliste aus und der Server kann die Ereignisse standardmäßig nach Startdatum sortieren. ``` { "data": { "findEventsAtVenue": [ { "id": "Festival-2", "name": "Festival 2", "minAgeRestriction": 21, "startsAt": "2018-10-05T14:48:00.000Z", "performers": [ "The Singers", "The Screamers" ] }, { "id": "Concert-3", "name": "Concert 3", "minAgeRestriction": 18, "startsAt": "2018-10-07T14:48:00.000Z", "performingBand": "The Jumpers" }, { "id": "Conference-4", "name": "Conference 4", "minAgeRestriction": null, "startsAt": "2018-10-09T14:48:00.000Z", "speakers": [ "The Storytellers" ], "workshops": [ "Writing", "Reading" ] } ] } } ``` Da Ergebnisse als eine einzelne Sammlung von Ereignissen zurückgegeben werden, ist die Verwendung von Schnittstellen zur Darstellung gemeinsamer Merkmale für die Sortierung der Ergebnisse sehr hilfreich. ## Beispiele für Vereinigungen Wie bereits erwähnt, definieren Gewerkschaften keine gemeinsamen Feldgruppen. Ein Suchergebnis kann viele verschiedene Typen repräsentieren. Mit dem `Event`-Schema können Sie eine `SearchResult`-Vereinigung definieren. Gehen Sie wie folgt vor: ``` type Query { # Retrieve Events at a specific Venue findEventsAtVenue(venueId: ID!): [Event] # Search across all content search(query: String!): [SearchResult] } union SearchResult = Conference | Festival | Concert | Venue ``` In diesem Fall müssen Sie Fragmente verwenden, um ein beliebiges Feld in unserer `SearchResult` Union abzufragen: ``` query { search(query: "Madison") { ... on Venue { id name address } ... on Festival { id name performers } ... on Concert { id name performingBand } ... on Conference { speakers workshops } } } ``` ## Geben Sie Auflösung ein AWS AppSync Die Typenauflösung ist der Mechanismus, durch den die GraphQL-Engine einen aufgelösten Wert als bestimmten Objekttyp identifiziert. Zurück zum Beispiel für die Union-Suche: Vorausgesetzt, dass unsere Abfrage Ergebnisse liefert, muss jedes Element in der Ergebnisliste als einer der möglichen Typen dargestellt werden, die von der `SearchResult` Union definiert wurden (d. h.`Conference`,, `Festival``Concert`, oder`Venue`). Da die Logik zum Unterscheiden zwischen `Festival`, `Venue` und `Conference` von den Anwendungsanforderungen abhängt, muss die GraphQL-Engine Informationen erhalten, um unsere möglichen Typen in den Raw-Ergebnissen zu identifizieren. Mit AWS AppSync wird dieser Hinweis durch ein Metafeld mit dem Namen dargestellt`__typename`, dessen Wert dem Namen des identifizierten Objekttyps entspricht. `__typename`ist für Rückgabetypen erforderlich, bei denen es sich um Interfaces oder Unions handelt. ## Beispiel für die Typauflösung Verwenden wir erneut das vorherige Schema. Sie können dies reproduzieren, indem Sie zur Konsole gehen und Folgendes unter der Seite **Schema** hinzufügen: ``` schema { query: Query } type Query { # Retrieve Events at a specific Venue findEventsAtVenue(venueId: ID!): [Event] # Search across all content search(query: String!): [SearchResult] } union SearchResult = Conference | Festival | Concert | Venue type Venue { id: ID! name: String! address: String maxOccupancy: Int } interface Event { id: ID! name: String! startsAt: String endsAt: String venue: Venue minAgeRestriction: Int } type Festival implements Event { id: ID! name: String! startsAt: String endsAt: String venue: Venue minAgeRestriction: Int performers: [String] } type Conference implements Event { id: ID! name: String! startsAt: String endsAt: String venue: Venue minAgeRestriction: Int speakers: [String] workshops: [String] } type Concert implements Event { id: ID! name: String! startsAt: String endsAt: String venue: Venue minAgeRestriction: Int performingBand: String } ``` Hängen wir nun einen Resolver an das `Query.search`-Feld an. Wählen Sie in dem `Resolvers` Abschnitt **Anhängen** aus, erstellen Sie eine neue **Datenquelle** vom Typ *NONE*, und geben Sie ihr dann einen Namen *StubDataSource*. Für dieses Beispiel nehmen wir an, wir haben die Ergebnisse aus einer externen Quelle abgerufen und codieren die abgerufenen Ergebnisse fest in unserer Zuweisungsvorlage für Anforderungen. Geben Sie im Bereich der Anforderungszuweisungsvorlage Folgendes ein: ``` { "version" : "2018-05-29", "payload": ## We are effectively mocking our search results for this example [ { "id": "Venue-1", "name": "Venue 1", "address": "2121 7th Ave, Seattle, WA 98121", "maxOccupancy": 1000 }, { "id": "Festival-2", "name": "Festival 2", "performers": ["The Singers", "The Screamers"] }, { "id": "Concert-3", "name": "Concert 3", "performingBand": "The Jumpers" }, { "id": "Conference-4", "name": "Conference 4", "speakers": ["The Storytellers"], "workshops": ["Writing", "Reading"] } ] } ``` Wenn die Anwendung den Typnamen als Teil des `id` Felds zurückgibt, muss die Typauflösungslogik das `id` Feld analysieren, um den Typnamen zu extrahieren, und dann das `__typename` Feld zu jedem der Ergebnisse hinzufügen. Sie können die Logik in der Antwortzuweisungsvorlage folgendermaßen umsetzen: **Anmerkung** Sie können diese Aufgabe auch als Teil Ihrer Lambda-Funktion ausführen, wenn Sie die Lambda-Datenquelle verwenden. ``` #foreach ($result in $context.result) ## Extract type name from the id field. #set( $typeName = $result.id.split("-")[0] ) #set( $ignore = $result.put("__typename", $typeName)) #end $util.toJson($context.result) ``` Führen Sie die folgende Abfrage aus: ``` query { search(query: "Madison") { ... on Venue { id name address } ... on Festival { id name performers } ... on Concert { id name performingBand } ... on Conference { speakers workshops } } } ``` Die Abfrage liefert die folgenden Ergebnisse: ``` { "data": { "search": [ { "id": "Venue-1", "name": "Venue 1", "address": "2121 7th Ave, Seattle, WA 98121" }, { "id": "Festival-2", "name": "Festival 2", "performers": [ "The Singers", "The Screamers" ] }, { "id": "Concert-3", "name": "Concert 3", "performingBand": "The Jumpers" }, { "speakers": [ "The Storytellers" ], "workshops": [ "Writing", "Reading" ] } ] } } ``` Die Typenauflösungslogik variiert je nach Anwendung. Sie können beispielsweise eine andere Identifizierungslogik verwenden, die prüft, ob bestimmte Felder oder auch Kombinationen von Feldern vorhanden sind. Sie können also feststellen, ob das `performers`-Feld vorhanden ist, um ein `Festival` zu identifizieren, oder die Kombination der Felder `speakers` und `workshops`, um eine `Conference` zu identifizieren. Letztlich liegt es an Ihnen, die Logik zu definieren, die Sie verwenden möchten.