架构设计
¥Schema Design
Design and evolve a type system over time without versions
版本控制
¥Versioning
虽然没有什么可以阻止 GraphQL 服务像任何其他 API 一样进行版本控制，但 GraphQL 通过提供用于持续发展 GraphQL 模式的工具，坚决避免版本控制。
¥While there’s nothing that prevents a GraphQL service from being versioned just like any other API, GraphQL takes a strong opinion on avoiding versioning by providing the tools for the continuous evolution of a GraphQL schema.
为什么大多数 API 都有版本？当对从 API 端点返回的数据的控制有限时，任何更改都可以被视为重大更改，而重大更改需要新版本。如果向 API 添加新功能需要新版本，那么就需要在经常发布和拥有许多增量版本与 API 的可理解性和可维护性之间进行权衡。
¥Why do most APIs version? When there’s limited control over the data that’s returned from an API endpoint, any change can be considered a breaking change, and breaking changes require a new version. If adding new features to an API requires a new version, then a tradeoff emerges between releasing often and having many incremental versions versus the understandability and maintainability of the API.
相比之下，GraphQL 仅返回明确请求的数据，因此可以通过新类型或现有类型的新字段添加新功能，而不会造成重大更改。这导致了一种常见的做法，即始终避免重大更改并提供无版本 API。
¥In contrast, GraphQL only returns the data that’s explicitly requested, so new capabilities can be added via new types or new fields on existing types without creating a breaking change. This has led to a common practice of always avoiding breaking changes and serving a versionless API.
可空性
¥Nullability
大多数识别 “null” 的类型系统都提供该类型的通用类型和可为 null 的版本，其中除非显式声明，否则默认类型不包括 “null”。然而，在 GraphQL 类型系统中，默认情况下每个字段都可以为空。这是因为在数据库和其他服务支持的网络服务中，有很多事情可能会出错。数据库可能会崩溃，异步操作可能会失败，可能会引发异常。除了简单的系统故障之外，授权通常可以是细粒度的，其中请求中的各个字段可以具有不同的授权规则。
¥Most type systems which recognise “null” provide both the common type and the nullable version of that type, whereby default types do not include “null” unless explicitly declared. However, in a GraphQL type system, every field is nullable by default. This is because there are many things that can go awry in a networked service backed by databases and other services. A database could go down, an asynchronous action could fail, an exception could be thrown. Beyond simply system failures, authorization can often be granular, where individual fields within a request can have different authorization rules.
通过将每个字段默认为可为空，任何这些原因都可能导致该字段仅返回 “null”，而不是请求完全失败。相反，GraphQL 提供了类型的 non-null 变体，这向客户端保证，如果请求，该字段将永远不会返回 “null”。相反，如果发生错误，则先前的父字段将改为 “null”。
¥By defaulting every field to nullable, any of these reasons may result in just that field returned “null” rather than having a complete failure for the request. Instead, GraphQL provides non-null variants of types which make a guarantee to clients that if requested, the field will never return “null”. Instead, if an error occurs, the previous parent field will be “null” instead.
在设计 GraphQL 结构时，重要的是要记住所有可能出错的问题以及 “null” 是否是失败字段的适当值。通常是这样，但有时也不是。在这些情况下，请使用非空类型来做出保证。
¥When designing a GraphQL schema, it’s important to keep in mind all the problems that could go wrong and if “null” is an appropriate value for a failed field. Typically it is, but occasionally, it’s not. In those cases, use non-null types to make that guarantee.