GraphQL 类型

查询与 GET 操作非常相似，因为它们执行只读获取以从源中获取数据。在 GraphQL 中，Query 定义向您的服务器发出请求的客户端的所有入口点。在您的 GraphQL 实施中始终具有一个 Query。

以下是我们在以前的架构示例中使用的 Query 和修改的对象类型：

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

我们的 Query 包含一个名为 people 的字段，该字段从数据来源中返回 Person 实例列表。假设我们需要更改应用程序的行为，现在我们需要返回仅包含 Occupation 实例的列表以用于某些单独的用途。我们可以直接将其添加到查询中：

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

在 GraphQL 中，我们可以将查询视为单一请求来源。如您所见，这可能比可能使用不同端点来 RESTful 实现相同目标（.../api/1/people和.../api/1/occupations）的实现要简单得多。

假设我们具有该查询的解析器实施，我们现在可以执行实际的查询。虽然 Query 类型存在，但我们必须明确调用该类型，才能在应用程序的代码中运行。可以使用 query 关键字完成该操作：

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

正如您看到的一样，该查询命名为 getItems 并返回 people（Person 对象列表）和 occupations（Occupation 对象列表）。在 people 中，我们仅返回每个 Person 的 name 字段，同时返回每个 Occupation 的 title 字段。响应可能如下所示：

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

该示例响应说明了数据如何遵循查询的形状。检索的每个条目在该字段的范围内列出。people 和 occupations 是作为单独的列表返回的。虽然这很有用，但修改查询以返回人员姓名和职业的列表可能会更方便：

query getItems {
   people {
      name   
      occupation {
        title
      }
}

这是合法的修改，因为我们的 Person 类型包含 Occupation 类型的 occupation 字段。在 people 范围内列出时，我们将返回每个 Person 的 name 及其按 title 关联的 Occupation。响应可能如下所示：

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

变更类似于 PUT 或 POST 等状态更改操作。它们执行写入操作以修改源中的数据，然后获取响应。它们定义数据修改请求的入口点。与查询不同，根据项目的需求，变更可能会包含在架构中，也可能不会包含在架构中。以下是架构示例中的变更：

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

addPerson 字段表示将 Person 添加到数据来源的一个入口点。addPerson 是字段名称；id、name 和 age 是参数；Person 是返回类型。回顾一下 Person 类型：

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

我们添加了 occupation 字段。不过，我们不能直接将该字段设置为 Occupation，因为不能将对象作为参数传入；它们严格来说是输出类型。我们应该将具有相同字段的输入作为参数传递：

input occupationInput {
  title: String
}

在创建新的 Person 实例时，我们也可以轻松更新 addPerson 以将其包含为参数：

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

以下是更新的架构：

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
}

请注意，occupation 从 occupationInput 传入 title 字段，以完成创建 Person 而不是原始 Occupation 对象。假设我们具有 addPerson 的解析器实施，我们现在可以执行实际的变更。虽然 Mutation 类型存在，但我们必须明确调用该类型，才能在应用程序的代码中运行。可以使用 mutation 关键字完成该操作：

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

该变更命名为 createPerson，addPerson 是操作。要创建新的 Person，我们可以输入 id、name、age 和 occupation 的参数。在 addPerson 的范围内，我们还可以看到其他字段，如 name、age 等。这是您的响应；这些是 addPerson 操作完成后返回的字段。以下是示例的最后一部分：

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

在使用该变更时，结果可能如下所示：

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

正如您看到的一样，响应使用与变更中定义的相同格式返回我们请求的值。最好返回所有修改的值，以减少混乱以及将来需要进行更多查询。变更允许您在其范围内包含多个操作。它们按照变更中列出的顺序依次运行。例如，如果我们创建另一个名为 addOccupation 的操作以将职务添加到数据来源中，我们可以在变更中的 addPerson 之后调用该操作。先处理 addPerson，然后处理 addOccupation。

订WebSockets阅用于在服务器与其客户端之间建立持久的双向连接。通常，客户端订阅或侦听服务器。每次服务器进行服务器端更改或执行事件时，订阅的客户端都会收到更新。如果订阅了多个客户端，并且需要向它们通知服务器或其他客户端中发生的更改，这种类型的协议是非常有用的。例如，可以使用订阅更新社交媒体源。可能具有两个用户（用户 A 和用户 B），他们订阅了自动通知更新，以在每次收到直接消息时收到通知。客户端 A 上的用户 A 可能向客户端 B 上的用户 B 发送直接消息。用户 A 的客户端将发送直接消息，而服务器处理该消息。然后，服务器向用户 B 的账户发送直接消息，同时向客户端 B 发送自动通知。

以下是我们可以添加到架构示例的 Subscription 示例：

type Subscription {                                   
  personAdded: Person
}

每次将新的 Person 添加到数据来源时，personAdded 字段都会向订阅的客户端发送消息。假设我们具有 personAdded 的解析器实施，我们现在可以使用订阅。虽然 Subscription 类型存在，但我们必须明确调用该类型，才能在应用程序的代码中运行。可以使用 subscription 关键字完成该操作：

subscription personAddedOperation {
  personAdded {
    id
    name
  }
}

订阅命名为 personAddedOperation，操作为 personAdded。personAdded 将返回新 Person 实例的 id 和 name 字段。看一下变更示例，我们使用该操作添加了一个 Person：

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

如果我们的客户端订阅了新添加的 Person 的更新，它们可能会在 addPerson 运行后看到这一点：

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

以下是订阅提供的内容摘要：

订阅是双向通道，允许客户端和服务器接收快速但稳定的更新。他们通常使用该 WebSocket 协议，该协议可创建标准化和安全的连接。

订阅非常灵活，因为它们减少了连接建立开销。在订阅后，客户端可以在较长时间内持续运行该订阅。它们通常允许开发人员定制订阅生命周期并配置请求哪些信息，从而高效地使用计算资源。

一般来说，订阅允许客户端一次进行多个订阅。实际上 AWS AppSync，订阅仅用于接收来自该 AWS AppSync 服务的实时更新。它们不能用于执行查询或变更。

订阅的主要替代方案是轮询，后者按设置的间隔发送查询以请求数据。该过程通常比订阅效率低，并且给客户端和后端带来很大压力。

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

.
.
.

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