Types de GraphQL

Les requêtes sont très similaires aux GET opérations en ce sens qu'elles effectuent une extraction en lecture seule pour obtenir des données depuis votre source. Dans GraphQL, il Query définit tous les points d'entrée pour les clients qui adressent des requêtes à votre serveur. Il y en aura toujours Query dans votre implémentation GraphQL.

Voici les types Query d'objets modifiés que nous avons utilisés dans notre exemple de schéma précédent :

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

Notre Query contient un champ appelé people qui renvoie une liste d'Personinstances provenant de la source de données. Supposons que nous devions modifier le comportement de notre application et que nous devions maintenant renvoyer une liste des Occupation instances uniquement dans un but distinct. Nous pourrions simplement l'ajouter à la requête :

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

Dans GraphQL, nous pouvons traiter notre requête comme la source unique de requêtes. Comme vous pouvez le constater, cela est potentiellement beaucoup plus simple que les implémentations RESTful qui peuvent utiliser différents points de terminaison pour obtenir la même chose (.../api/1/peopleet). .../api/1/occupations

En supposant que nous ayons une implémentation de résolveur pour cette requête, nous pouvons maintenant effectuer une requête réelle. Tant que le Query type existe, nous devons l'appeler explicitement pour qu'il s'exécute dans le code de l'application. Cela peut être fait à l'aide du query mot clé :

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

Comme vous pouvez le voir, cette requête est appelée getItems et renvoie people (une liste d'Personobjets) et occupations (une liste d'Occupationobjets). Danspeople, nous ne renvoyons que le name champ de chacunPerson, tandis que nous renvoyons le title champ de chacunOccupation. La réponse peut ressembler à ceci :

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

L'exemple de réponse montre comment les données suivent la forme de la requête. Chaque entrée récupérée est répertoriée dans la portée du champ. peopleet occupations renvoient les articles sous forme de listes séparées. Bien que cela soit utile, il peut être plus pratique de modifier la requête pour renvoyer une liste des noms et des professions des personnes :

query getItems {
   people {
      name   
      occupation {
        title
      }
}

Il s'agit d'une modification légale car notre Person type contient un occupation champ de typeOccupation. Lorsque la liste est répertoriée dans le cadre depeople, nous Person renvoyons chacun name avec son identifiant associé Occupation partitle. La réponse peut ressembler à ceci :

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

Les mutations sont similaires aux opérations de changement d'état comme PUT ouPOST. Ils effectuent une opération d'écriture pour modifier les données de la source, puis récupèrent la réponse. Ils définissent vos points d'entrée pour les demandes de modification des données. Contrairement aux requêtes, une mutation peut être incluse ou non dans le schéma en fonction des besoins du projet. Voici la mutation à partir de l'exemple de schéma :

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

Le addPerson champ représente un point d'entrée qui ajoute un Person à la source de données. addPersonest le nom du champ ;id,name, et age sont les paramètres ; et Person est le type de retour. En repensant au Person type :

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

Nous avons ajouté le occupation champ. Cependant, nous ne pouvons pas définir ce champ sur Occupation directement car les objets ne peuvent pas être transmis en tant qu'arguments ; ce sont uniquement des types de sortie. Nous devrions plutôt passer une entrée avec les mêmes champs en argument :

input occupationInput {
  title: String
}

Nous pouvons également facilement le mettre à jour addPerson pour l'inclure en tant que paramètre lors de la création de nouvelles Person instances :

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

Voici le schéma mis à jour :

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
}

Notez que cela occupation passera dans le title champ de occupationInput pour terminer la création de l'objet à la Person place de l'Occupationobjet d'origine. En supposant que nous ayons une implémentation de résolveur pouraddPerson, nous pouvons maintenant effectuer une véritable mutation. Tant que le Mutation type existe, nous devons l'appeler explicitement pour qu'il s'exécute dans le code de l'application. Cela peut être fait à l'aide du mutation mot clé :

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

Cette mutation s'appellecreatePerson, et addPerson c'est l'opération. Pour en créer un nouveauPerson, nous pouvons entrer les arguments pour idname,age, etoccupation. Dans le cadre deaddPerson, nous pouvons également voir d'autres champs tels que nameage, etc. Il s'agit de votre réponse ; ce sont les champs qui seront renvoyés une fois l'addPersonopération terminée. Voici la dernière partie de l'exemple :

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

En utilisant cette mutation, le résultat pourrait ressembler à ceci :

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

Comme vous pouvez le constater, la réponse a renvoyé les valeurs que nous avions demandées dans le même format que celui défini dans notre mutation. Il est recommandé de renvoyer toutes les valeurs qui ont été modifiées afin de réduire la confusion et la nécessité de nouvelles requêtes à l'avenir. Les mutations vous permettent d'inclure plusieurs opérations dans son champ d'application. Ils seront exécutés séquentiellement dans l'ordre indiqué dans la mutation. Par exemple, si nous créons une autre opération appelée addOccupation qui ajoute des titres de poste à la source de données, nous pouvons l'appeler dans la mutation suivanteaddPerson. addPersonsera traité en premier, suivi deaddOccupation.

Les abonnements WebSockets permettent d'établir une connexion bidirectionnelle durable entre le serveur et ses clients. En règle générale, un client s'abonne au serveur ou l'écoute. Chaque fois que le serveur effectue une modification côté serveur ou exécute un événement, le client abonné reçoit les mises à jour. Ce type de protocole est utile lorsque plusieurs clients sont abonnés et doivent être informés des modifications apportées au serveur ou à d'autres clients. Par exemple, les abonnements peuvent être utilisés pour mettre à jour les flux de réseaux sociaux. Il peut y avoir deux utilisateurs, l'utilisateur A et l'utilisateur B, qui sont tous deux abonnés à des mises à jour automatiques chaque fois qu'ils reçoivent des messages directs. L'utilisateur A du client A pourrait envoyer un message direct à l'utilisateur B du client B. Le client de l'utilisateur A enverrait le message direct, qui serait traité par le serveur. Le serveur enverrait ensuite le message direct au compte de l'utilisateur B tout en envoyant une notification automatique au client B.

Voici un exemple Subscription que nous pourrions ajouter à l'exemple de schéma :

type Subscription {                                   
  personAdded: Person
}

Le personAdded champ envoie un message aux clients abonnés chaque fois qu'une nouvelle information Person est ajoutée à la source de données. En supposant que nous ayons une implémentation de résolveur pourpersonAdded, nous pouvons maintenant utiliser l'abonnement. Tant que le Subscription type existe, nous devons l'appeler explicitement pour qu'il s'exécute dans le code de l'application. Cela peut être fait à l'aide du subscription mot clé :

subscription personAddedOperation {
  personAdded {
    id
    name
  }
}

L'abonnement est appelé personAddedOperation et l'opération l'estpersonAdded. personAddedrenverra les name champs id et des nouvelles Person instances. En regardant l'exemple de mutation, nous avons ajouté un Person en utilisant cette opération :

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

Si nos clients étaient abonnés aux mises à jour des articles récemment ajoutésPerson, ils pourraient voir ceci après les addPerson exécutions :

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

Vous trouverez ci-dessous un résumé de ce que proposent les abonnements :

Les abonnements sont des canaux bidirectionnels qui permettent au client et au serveur de recevoir des mises à jour rapides mais régulières. Ils utilisent généralement le WebSocket protocole, qui crée des connexions standardisées et sécurisées.

Les abonnements sont souples dans la mesure où ils réduisent les frais de configuration de la connexion. Une fois abonné, un client peut simplement continuer à utiliser cet abonnement pendant de longues périodes. Ils utilisent généralement les ressources informatiques de manière efficace en permettant aux développeurs d'adapter la durée de vie de l'abonnement et de configurer les informations qui seront demandées.

En général, les abonnements permettent au client de souscrire plusieurs abonnements à la fois. En ce qui concerne AWS AppSync, les abonnements ne sont utilisés que pour recevoir des mises à jour en temps réel du AWS AppSync service. Ils ne peuvent pas être utilisés pour effectuer des requêtes ou des mutations.

La principale alternative aux abonnements est le sondage, qui envoie des requêtes à des intervalles définis pour demander des données. Ce processus est généralement moins efficace que les abonnements et met à rude épreuve à la fois le client et le backend.

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

.
.
.

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