更好的 GraphQL schema 拼接方法
模式是任何GraphQL实现中最重要的部分。模式是任何 GraphQL 服务的核心，它定义了客户端可以查询的数据集。
什么是模式缝合？
想象一下，有一个项目涉及多个团队，每个团队又参与其中：
- 负责处理对该服务至关重要的各个方面，
- 需要对架构进行研究，以确保他们负责的项目部分能够按预期运行。
- 必须确保所有部件整体上都能正常运转。
合作制定大型项目方案可能会令人困惑……
GitHub 的一个 schema 片段，总共包含 9182 行代码！
模式拼接是将多个 GraphQL 模式合并成一个可查询的模式的过程。对于需要统一且透明地访问分散在多个 API 中的数据（即使不了解数据的具体位置）的项目来说，这是一种极其有用的方法。它还可以用于自定义现有的 GraphQL API，例如添加自定义解析器、覆盖第三方GraphQL 服务的现有解析器，或者向数据来自其他数据源的现有类型添加更多字段。
执行模式拼接可能会导致问题。
虽然将两个模式合并成一个且不发生名称冲突看起来很简单，但这并非真正的模式拼接。我们想要实现的是一个一致的模式，它由多个底层 GraphQL API 合并而成。这要困难得多，但如果我告诉你有一个应用可以做到这一点呢？
更好的方法
最新发布的GraphQL 编辑器引入了一种简便的模式协作方式。我们只需：
1. 向我们的帐户添加两个或多个架构 - 您可以从 URL 或 .gql 文件加载它们
2. 创建一个新项目。3. 从列表中选择我们希望在新生成的模式中访问的模式，并创建一个项目。
就这样！
只要我们成功避免了底层模式之间的冲突，我们就能在新生成的项目中访问它们的所有元素👌
