关于 Graphs 的思考

    图是将很多真实世界现象变成模型的强大工具，因为它们和我们自然的心理模型和基本过程的口头描述很相似。通过 GraphQL，你会把自己的业务领域通过定义 schema 建模成一张图；在你的 schema 里，你定义不同类型的节点以及它们之间是如何连接的。在客户端这边，这创建了一种类似于面向对象编程的模式：引用其他类型的类型。在服务器端，由于 GraphQL 定义了接口，你可以在任何后端自由的使用它（无论新旧！）。

    考虑下把你的 GraphQL schema 作为一种给你的团队和用户的沟通的共同语言。为了建立一个好的 schema，你必须检查你用来描述业务的日常语言。举个例子，让我们尝试用简单的文字描述一个电子邮件应用程序：

    • 一个用户可以有多个邮箱账号
    • 每封邮件都有发送人、接收日期、主题和正文
    • 没有收件人地址，用户无法发送电子邮件

    命名是构建直观的接口中一个困难但重要的部分，所以花时间仔细地考虑对于你的问题域和用户什么事有意义的。您的团队应该对这些业务领域的规则形成共同的理解和共识，因为您需要为 GraphQL schema 中的节点和关系选择直观，耐用的名称。试着去想象一些你想执行的查询：

    获取主账户的前二十封草稿邮件的“预览信息”

    2.   mainAccount {
    3.     drafts(first: 20) {
    4.       ...previewInfo
    5.   }
    6. }
    9.   subject
    10.   bodyPreviewSentence

    你应该在哪里定义真正的业务逻辑？你应该在哪里验证，检查用户权限？就是在专门的业务逻辑层里。你的业务逻辑层应作为执行业务域规则的唯一正确来源。

    有时候，你会发现自己正在使用不能完全反映客户端消费数据的旧有的数据源。在这种情况下，更倾向于构建一个描述客户端如何使用数据的 GraphQL schema，而不是镜像旧有的数据库 schema。

    构建一个表达“是什么”而不是“怎么做”的 GraphQL schema。然后，您可以改进执行的具体细节，而不会破坏与旧客户端的接口。