敏捷原则

快速推出图并适应不断变化的需求

4. 抽象、面向需求的 Schema

Schema 应当作为抽象层以隐藏服务实现细节并为消费者提供灵活性。

GraphQL 的一大价值就是在服务和消费者之间提供了一个抽象层，因此 schema 就不该与特定服务实现或者特定现存消费者强耦合。通过将实现细节从 schema 中分离，就能重构实现图关系的服务的同时 —— 例如，从单体架构切换到微服务架构，或者切换服务的实现语言 —— 而不会影响现有应用。同样地，schema 也不应该和特定应用取数据的方法所耦合。如果新的应用与旧的十分相似，那么应该只需要微微修改图关系。

为了达到这个目的，我们使用面向需求的 schema：专注于提供良好的开发体验，使得开发者可以更方便地使用现有图关系开发新的特性。以此标准为目标的话，可以防止图关系与一个将要变化的服务实现相耦合，且提升了添加到图关系的每一个字段的复用价值。

5. 使用敏捷方法进行 Schema 开发

Schema 应当根据实际需求增量构建，并随着时间的推移平滑演进。

有件十分有诱惑力的事：提前定义你所有数据的"完美 schema"。然而，真正让一个 schema 产生价值的是贴合用户的需求，但需求永远都不没法完全得知而且还会一直变化。真正通向"完美 schema"的方式是构建易于跟随实际需求变化而进化的图关系。

字段不应该凭臆断添加，理想情况下，每个字段都对于一个具体的消费者附加需求，且要设计成可被其他消费者类似需求最大化复用的形式。

图关系的更新应该是一个持续的过程。相比较周期性的发布新"版本"的图关系（例如每 6 个月或者 12 个月），更好的是必要情况下能够一天修改多次。新字段可以在任何时间添加。而移除字段，则需要先将其标记为弃用，然后等到没有消费者在使用它的时候再移除。Schema 注册表使得图关系的敏捷演进成为可能，通过相关的流程和工具，可以让每个人都知晓影响他们的字段改变。这样就能保证只有全面审查过的改变才能进入生产环境。

6. 迭代地提高性能

性能管理应当是一个连续的、数据驱动的过程，可以平滑地适应不断变化的查询负载和服务实现。

数据图关系层是保存服务团队与消费其服务的应用开发者之间关于性能与容量的会话的绝佳场所。这个会话是一个持续的过程，使服务开发者能够持续主动地了解消费者是如何使用服务的。

相比较优化图关系中每一个可能的用法，更推荐专注于提供生产环境所实际需要的查询情形。相关工具应该提取新提出的查询情形，并在投入生产之前，将其延迟要求和预计查询量呈现给所有受影响的服务团队。一旦这个查询投入到生产之中，它的性能就将被持续监控。当这个原则得到采用实施的时候，问题就能被追溯到表现不合预期的服务。

7. 使用图的元数据为开发人员提供支持

开发人员应当在整个开发过程中对图充分了解。

GraphQL 的一个主要价值就是它为开发者带来的巨大生产力提升。为了最大化这一提升效果，开发工具应该让开发者对数据图有更普遍的理解，而开发者也应该在整个开发周期内使用这些工具。

每当开发者开展数据管理或者服务连接相关的工作，他们的工具就应该将图关系的实时信息展示在他们指尖。这信息应该保证总是最新的，而工具应该保证是高度智能化的，能够将对图关系的感知以强大而有效的方式应用于手头的工作。当工作完成之际，不仅仅开发者的生产力和幸福度得到提升，GraphQL 也在前后端团队之间穿针引线，让团队间能在整个开发周期内无缝对话。

以下是部分数据图感知工具的实际用例：

• 能在开发者键入这个查询后，就在他们的编辑器中给出所用图数据和服务的实时文档，且总是最新的。
• 关于弃用字段的信息能被广播到用了这些字段的开发者的编辑器中，同时还给出推荐的备用字段。
• 一个查询的成本估计（延迟或者服务器资源）能在开发者打这个查询后就给出，基于实时的生产数据。
• 运维团队能追溯后端服务的负载到具体应用、版本、特性，甚至代码所在行，使他们能够全面地了解开发人员是如何使用他们的服务。
• 当服务开发者更改了 schema 时，更改的影响可以被自动判定，作为持续集成的一部分。 如果更改会破坏现有客户端（通过重放最近的生产使用情况确定），服务开发者则可以确定那些具体的客户端、版本和开发人员将受到影响。
• 当应用程序开发者构建功能时，支持这些功能的新查询可以从代码中提取，并与运维团队共享。有了这种认知后，如果无法批准预期的查询规模，运营团队则可以在开发过程的早期介入，并主动提供能力以支持所需规模。
• 当应用程序使用 TypeScript、Java 或 Swift 等带类型的语言开发时，类型信息可以从服务的类型声明一直传播到应用程序中的每行代码，从而确保全栈的类型正确性和错误信息的即时反馈。