GraphQL-Typen

Abfragen sind GET Operationen insofern sehr ähnlich, als sie einen schreibgeschützten Abruf durchführen, um Daten aus Ihrer Quelle abzurufen. In GraphQL Query definiert das alle Einstiegspunkte für Clients, die Anfragen an Ihren Server stellen. In Ihrer GraphQL-Implementierung wird es immer eine Query geben.

Hier sind die Query und geänderten Objekttypen, die wir in unserem vorherigen Schemabeispiel verwendet haben:

type Person { 
  id: ID!
  name: String
  age: Int
  occupation: Occupation
}
type Occupation {
  title: String
}
type Query {                                   
  people: [Person]
}

Unser Query enthält ein Feld namenspeople, das eine Liste von Person Instanzen aus der Datenquelle zurückgibt. Nehmen wir an, wir müssen das Verhalten unserer Anwendung ändern, und jetzt müssen wir nur eine Liste der Occupation Instanzen für einen anderen Zweck zurückgeben. Wir könnten es einfach zur Abfrage hinzufügen:

type Query {                                   
  people: [Person]
  occupations: [Occupation]
}

In GraphQL können wir unsere Abfrage als einzige Quelle für Anfragen behandeln. Wie Sie sehen, ist dies potenziell viel einfacher als RESTful-Implementierungen, die möglicherweise unterschiedliche Endpunkte verwenden, um dasselbe (und) zu erreichen. .../api/1/people .../api/1/occupations

Angenommen, wir haben eine Resolver-Implementierung für diese Abfrage, können wir jetzt eine tatsächliche Abfrage durchführen. Solange der Query Typ existiert, müssen wir ihn explizit aufrufen, damit er im Code der Anwendung ausgeführt wird. Dies kann mit dem query Schlüsselwort erfolgen:

query getItems {
   people {
      name
   }
   occupations {
      title
   }
}

Wie Sie sehen können, wird diese Abfrage aufgerufen getItems und gibt people (eine Liste von Person Objekten) und occupations (eine Liste von Occupation Objekten) zurück. peopleIn geben wir nur das name Feld von jedem zurückPerson, während wir das title Feld von jedem zurückgebenOccupation. Die Antwort könnte so aussehen:

{
  "data": {
    "people": [
      {
        "name": "John Smith"
      },
      {
        "name": "Andrew Miller"
      },
      .
      .
      .
    ],
    "occupations": [
      {
        "title": "Firefighter"
      },
      {
        "title": "Bookkeeper"
      },
      .
      .
      .
    ]
  }
}

Die Beispielantwort zeigt, wie die Daten der Form der Abfrage folgen. Jeder abgerufene Eintrag wird im Bereich des Felds aufgeführt. peopleund geben occupations Dinge als separate Listen zurück. Obwohl nützlich, könnte es praktischer sein, die Abfrage so zu ändern, dass sie eine Liste mit Namen und Berufen von Personen zurückgibt:

query getItems {
   people {
      name   
      occupation {
        title
      }
}

Dies ist eine legale Änderung, da unser Person Typ ein occupation Feld vom Typ Occupation enthält. Wenn wir im Gültigkeitsbereich von aufgeführt sindpeople, geben wir jedes Person Feld name zusammen mit dem zugehörigen Occupation von zurücktitle. Die Antwort könnte so aussehen:

}
  "data": {
    "people": [
      {
        "name": "John Smith",
        "occupation": {
          "title": "Firefighter"
        }
      },
      {
        "name": "Andrew Miller",
        "occupation": {
          "title": "Bookkeeper"
        }
      },
      .
      .
      .
    ]
  }
}

Mutationen ähneln zustandsändernden Operationen wie PUT oderPOST. Sie führen einen Schreibvorgang durch, um Daten in der Quelle zu ändern, und rufen dann die Antwort ab. Sie definieren Ihre Einstiegspunkte für Datenänderungsanfragen. Im Gegensatz zu Abfragen kann eine Mutation je nach den Anforderungen des Projekts in das Schema aufgenommen werden oder nicht. Hier ist die Mutation aus dem Schemabeispiel:

type Mutation {
  addPerson(id: ID!, name: String, age: Int): Person
}

Das addPerson Feld stellt einen Einstiegspunkt dar, der der Datenquelle einen Person hinzufügt. addPersonist der Feldname;id,name, und age sind die Parameter; und Person ist der Rückgabetyp. Rückblick auf den Person Typ:

type Person { 
  id: ID!
  name: String
  age: Int
  occupation: Occupation
}

Wir haben das occupation Feld hinzugefügt. Wir können dieses Feld jedoch nicht Occupation direkt auf setzen, da Objekte nicht als Argumente übergeben werden können; es handelt sich ausschließlich um Ausgabetypen. Wir sollten stattdessen eine Eingabe mit denselben Feldern als Argument übergeben:

input occupationInput {
  title: String
}

Wir können unsere auch einfach aktualisierenaddPerson, um dies als Parameter einzubeziehen, wenn wir neue Person Instanzen erstellen:

type Mutation {
  addPerson(id: ID!, name: String, age: Int, occupation: occupationInput): Person
}

Hier ist das aktualisierte Schema:

type Person { 
  id: ID!
  name: String
  age: Int
  occupation: Occupation
}

type Occupation {
  title: String
}

input occupationInput {
  title: String
}

type Mutation {
  addPerson(id: ID!, name: String, age: Int, occupation: occupationInput): Person
}

Beachten occupation Sie, dass das title Feld von bis occupationInput zur Fertigstellung der Erstellung des Occupation Objekts Person anstelle des Originalobjekts übergeben wird. Angenommen, wir haben eine Resolver-Implementierung füraddPerson, können wir jetzt eine tatsächliche Mutation durchführen. Solange der Mutation Typ existiert, müssen wir ihn explizit aufrufen, damit er im Code der Anwendung ausgeführt wird. Dies kann mit dem mutation Schlüsselwort erfolgen:

mutation createPerson {
  addPerson(id: ID!, name: String, age: Int, occupation: occupationInput) {
    name
    age
    occupation {
      title
    }
  }
}

Diese Mutation heißt createPerson und addPerson ist die Operation. Um eine neue zu erstellenPerson, können wir die Argumente für id nameage, und eingebenoccupation. Im Bereich von addPerson können wir auch andere Felder wie nameage, usw. sehen. Dies ist Ihre Antwort; dies sind die Felder, die nach Abschluss des addPerson Vorgangs zurückgegeben werden. Hier ist der letzte Teil des Beispiels:

mutation createPerson {
  addPerson(id: "1", name: "Steve Powers", age: "50", occupation: "Miner") {
    id
    name
    age
    occupation {
      title
    }
  }
}

Mit dieser Mutation könnte ein Ergebnis wie folgt aussehen:

{
  "data": {
    "addPerson": {
      "id": "1",
      "name": "Steve Powers",
      "age": "50",
      "occupation": {
        "title": "Miner"
      }
    }
  }
}

Wie Sie sehen können, hat die Antwort die von uns angeforderten Werte in demselben Format zurückgegeben, das in unserer Mutation definiert wurde. Es hat sich bewährt, alle Werte zurückzugeben, die geändert wurden, um Verwirrung zu vermeiden und die Notwendigkeit weiterer Abfragen in Zukunft zu vermeiden. Mutationen ermöglichen es Ihnen, mehrere Operationen in den Gültigkeitsbereich einzubeziehen. Sie werden sequentiell in der Reihenfolge ausgeführt, die in der Mutation angegeben ist. Wenn wir beispielsweise eine weitere Operation mit dem Namen erstellenaddOccupation, die der Datenquelle Berufsbezeichnungen hinzufügt, können wir diese in der nachfolgenden Mutation aufrufen. addPerson addPersonwird zuerst behandelt, gefolgt vonaddOccupation.

Abonnements dienen WebSockets dazu, eine dauerhafte, bidirektionale Verbindung zwischen dem Server und seinen Clients herzustellen. In der Regel abonniert ein Client den Server oder hört ihm zu. Immer wenn der Server eine serverseitige Änderung vornimmt oder ein Ereignis ausführt, erhält der abonnierte Client die Updates. Diese Art von Protokoll ist nützlich, wenn mehrere Clients abonniert sind und über Änderungen auf dem Server oder auf anderen Clients informiert werden müssen. Beispielsweise können Abonnements verwendet werden, um Social-Media-Feeds zu aktualisieren. Es könnte zwei Benutzer geben, Benutzer A und Benutzer B, die beide automatische Benachrichtigungsaktualisierungen abonniert haben, wenn sie Direktnachrichten erhalten. Benutzer A auf Client A könnte eine Direktnachricht an Benutzer B auf Client B senden. Der Client von Benutzer A würde die Direktnachricht senden, die vom Server verarbeitet würde. Der Server würde dann die Direktnachricht an das Konto von Benutzer B senden und gleichzeitig eine automatische Benachrichtigung an Client B senden.

Hier ist ein Beispiel für aSubscription, das wir dem Schemabeispiel hinzufügen könnten:

type Subscription {                                   
  personAdded: Person
}

Das personAdded Feld sendet eine Nachricht an abonnierte Kunden, wenn der Datenquelle eine neue hinzugefügt Person wird. Angenommen, wir haben eine Resolver-Implementierung fürpersonAdded, können wir jetzt das Abonnement verwenden. Solange der Subscription Typ existiert, müssen wir ihn explizit aufrufen, damit er im Code der Anwendung ausgeführt wird. Dies kann mit dem subscription Schlüsselwort erfolgen:

subscription personAddedOperation {
  personAdded {
    id
    name
  }
}

Das Abonnement wird aufgerufenpersonAddedOperation, und die Operation istpersonAdded. personAddedgibt die name Felder id und neuer Person Instanzen zurück. Wenn wir uns das Mutationsbeispiel ansehen, haben wir eine hinzugefügt, die diese Operation Person verwendet:

addPerson(id: "1", name: "Steve Powers", age: "50", occupation: "Miner")

Wenn unsere Kunden Updates für die neu hinzugefügten Updates abonniert hätten, könnte es seinPerson, dass sie nach den addPerson Läufen Folgendes sehen:

{
  "data": {
    "personAdded": {
      "id": "1",
      "name": "Steve Powers"
    }
  }
}

Im Folgenden finden Sie eine Zusammenfassung dessen, was Abonnements bieten:

Abonnements sind wechselseitige Kanäle, die es dem Client und dem Server ermöglichen, schnelle, aber stetige Updates zu erhalten. Sie verwenden in der Regel das WebSocket Protokoll, das standardisierte und sichere Verbindungen herstellt.

Abonnements sind flexibel, da sie den Aufwand für den Verbindungsaufbau reduzieren. Einmal abonniert, kann ein Kunde dieses Abonnement einfach für längere Zeiträume weiterverwenden. Sie nutzen die Computerressourcen in der Regel effizient, da Entwickler die Laufzeit des Abonnements individuell anpassen und konfigurieren können, welche Informationen angefordert werden.

Im Allgemeinen ermöglichen Abonnements dem Kunden, mehrere Abonnements gleichzeitig abzuschließen. In diesem Zusammenhang AWS AppSync werden Abonnements nur für den Empfang von Echtzeit-Updates vom AWS AppSync Dienst verwendet. Sie können nicht zur Durchführung von Abfragen oder Mutationen verwendet werden.

Die Hauptalternative zu Abonnements ist das Polling, bei dem in festgelegten Intervallen Abfragen gesendet werden, um Daten anzufordern. Dieser Prozess ist in der Regel weniger effizient als Abonnements und belastet sowohl den Client als auch das Backend stark.

schema {
  query: Query
  mutation: Mutation
  subscription: Subscription
}

.
.
.

type Query {                                   
  # code goes here
}
type Mutation {                                   
  # code goes here
}
type Subscription {                                   
  # code goes here
}