Tipi GraphQL

Le query sono molto simili alle GET operazioni in quanto eseguono un recupero di sola lettura per ottenere dati dalla fonte. In GraphQL, Query definisce tutti i punti di ingresso per i client che effettuano richieste verso il tuo server. Ci sarà sempre un'implementazione GraphQL Query nella tua implementazione GraphQL.

Ecco i Query tipi di oggetti modificati che abbiamo usato nel nostro precedente esempio di schema:

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

Il nostro Query contiene un campo chiamato people che restituisce un elenco di Person istanze dalla fonte di dati. Supponiamo di dover modificare il comportamento della nostra applicazione e ora dobbiamo restituire un elenco delle sole Occupation istanze per uno scopo separato. Potremmo semplicemente aggiungerlo alla query:

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

In GraphQL, possiamo trattare la nostra query come l'unica fonte di richieste. Come puoi vedere, questo è potenzialmente molto più semplice RESTful delle implementazioni che potrebbero utilizzare endpoint diversi per ottenere lo stesso risultato (e). .../api/1/people .../api/1/occupations

Supponendo di avere un'implementazione del resolver per questa query, ora possiamo eseguire una query vera e propria. Sebbene il Query tipo esista, dobbiamo chiamarlo esplicitamente affinché venga eseguito nel codice dell'applicazione. Questo può essere fatto usando la query parola chiave:

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

Come puoi vedere, questa query viene chiamata getItems e restituisce people (un elenco di Person oggetti) e occupations (un elenco di Occupation oggetti). Nelpeople, stiamo restituendo solo il name campo di ciascunoPerson, mentre stiamo restituendo il title campo di ciascunoOccupation. La risposta potrebbe essere simile a questa:

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

La risposta di esempio mostra come i dati seguono la forma della query. Ogni voce recuperata viene elencata nell'ambito del campo. peoplee occupations stanno restituendo le cose come elenchi separati. Sebbene utile, potrebbe essere più comodo modificare la query per restituire un elenco di nomi e occupazioni delle persone:

query getItems {
   people {
      name   
      occupation {
        title
      }
}

Questa è una modifica legale perché il nostro Person tipo contiene un occupation campo di tipoOccupation. Se elencati nell'ambito dipeople, restituiamo ciascuno Person di essi name insieme a quello associato Occupation datitle. La risposta potrebbe essere simile a questa:

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

Le mutazioni sono simili a operazioni che cambiano lo stato come oPUT. POST Eseguono un'operazione di scrittura per modificare i dati nell'origine, quindi recuperano la risposta. Definiscono i punti di ingresso per le richieste di modifica dei dati. A differenza delle query, una mutazione può essere inclusa o meno nello schema a seconda delle esigenze del progetto. Ecco la mutazione dall'esempio dello schema:

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

Il addPerson campo rappresenta un punto di ingresso che aggiunge un Person all'origine dati. addPersonè il nome del campo;id,name, e age sono i parametri; ed Person è il tipo restituito. Guardando indietro al Person tipo:

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

Abbiamo aggiunto il occupation campo. Tuttavia, non possiamo impostare questo campo su Occupation direttamente perché gli oggetti non possono essere passati come argomenti; sono strettamente tipi di output. Dovremmo invece passare un input con gli stessi campi di un argomento:

input occupationInput {
  title: String
}

Possiamo anche aggiornare facilmente il nostro addPerson per includerlo come parametro quando creiamo nuove Person istanze:

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

Ecco lo schema aggiornato:

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
}

Nota che occupation passerà nel title campo da occupationInput per completare la creazione dell'oggetto Person anziché dell'Occupationoggetto originale. Supponendo di avere un'implementazione del resolver peraddPerson, ora possiamo eseguire una mutazione effettiva. Sebbene il Mutation tipo esista, dobbiamo chiamarlo esplicitamente affinché venga eseguito nel codice dell'applicazione. Questo può essere fatto usando la mutation parola chiave:

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

Questa mutazione si chiamacreatePerson, ed addPerson è l'operazione. Per crearne una nuovaPerson, possiamo inserire gli argomenti perid, nameage, eoccupation. Nell'ambito diaddPerson, possiamo vedere anche altri campi come nameage, ecc. Questa è la tua risposta; questi sono i campi che verranno restituiti al termine dell'addPersonoperazione. Ecco la parte finale dell'esempio:

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

Utilizzando questa mutazione, un risultato potrebbe essere simile al seguente:

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

Come puoi vedere, la risposta ha restituito i valori richiesti nello stesso formato definito nella nostra mutazione. È buona norma restituire tutti i valori che sono stati modificati per ridurre la confusione e la necessità di ulteriori query in futuro. Le mutazioni consentono di includere più operazioni nel suo ambito. Verranno eseguite in sequenza nell'ordine indicato nella mutazione. Ad esempio, se creiamo un'altra operazione chiamata addOccupation che aggiunge titoli di lavoro all'origine dati, possiamo richiamarla nella mutazione successiva. addPerson addPersonverrà gestito per primo seguito da. addOccupation

Gli abbonamenti vengono utilizzati WebSocketsper aprire una connessione bidirezionale duratura tra il server e i suoi client. In genere, un client si iscrive o ascolta il server. Ogni volta che il server apporta una modifica sul lato server o esegue un evento, il client sottoscritto riceverà gli aggiornamenti. Questo tipo di protocollo è utile quando sono sottoscritti più client e devono essere avvisati delle modifiche che avvengono nel server o in altri client. Ad esempio, gli abbonamenti possono essere utilizzati per aggiornare i feed dei social media. Potrebbero esserci due utenti, l'utente A e l'utente B, entrambi abbonati agli aggiornamenti automatici delle notifiche ogni volta che ricevono messaggi diretti. L'utente A sul client A potrebbe inviare un messaggio diretto all'utente B sul client B. Il client dell'utente A invierebbe il messaggio diretto, che verrebbe elaborato dal server. Il server invierebbe quindi il messaggio diretto all'account dell'utente B inviando una notifica automatica al client B.

Ecco un esempio di a Subscription che potremmo aggiungere all'esempio dello schema:

type Subscription {                                   
  personAdded: Person
}

Il personAdded campo invierà un messaggio ai clienti abbonati ogni volta che ne Person viene aggiunto uno nuovo alla fonte di dati. Supponendo di avere un'implementazione del resolver perpersonAdded, ora possiamo usare l'abbonamento. Sebbene il Subscription tipo esista, dobbiamo chiamarlo esplicitamente affinché venga eseguito nel codice dell'applicazione. Questo può essere fatto usando la subscription parola chiave:

subscription personAddedOperation {
  personAdded {
    id
    name
  }
}

L'abbonamento viene chiamato personAddedOperation e l'operazione èpersonAdded. personAddedrestituirà i name campi id e delle nuove Person istanze. Guardando l'esempio di mutazione, abbiamo aggiunto un'operazione che Person utilizza questa:

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

Se i nostri clienti erano abbonati agli aggiornamenti di quelli appena aggiuntiPerson, potrebbero vederlo dopo l'addPersonesecuzione:

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

Di seguito è riportato un riepilogo di ciò che offrono gli abbonamenti:

Gli abbonamenti sono canali bidirezionali che consentono al client e al server di ricevere aggiornamenti rapidi ma costanti. In genere utilizzano il WebSocket protocollo, che crea connessioni standardizzate e sicure.

Gli abbonamenti sono agili in quanto riducono il sovraccarico di configurazione della connessione. Una volta sottoscritto, un cliente può continuare a utilizzare tale abbonamento per lunghi periodi di tempo. In genere utilizzano le risorse informatiche in modo efficiente, consentendo agli sviluppatori di personalizzare la durata dell'abbonamento e di configurare le informazioni richieste.

In generale, gli abbonamenti consentono al cliente di effettuare più abbonamenti contemporaneamente. Per quanto riguarda AWS AppSync, gli abbonamenti vengono utilizzati solo per ricevere aggiornamenti in tempo reale dal servizio. AWS AppSync Non possono essere utilizzati per eseguire interrogazioni o mutazioni.

L'alternativa principale agli abbonamenti è il polling, che invia interrogazioni a intervalli prestabiliti per richiedere dati. Questo processo è in genere meno efficiente degli abbonamenti e mette a dura prova sia il client che il backend.

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

.
.
.

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