这个话题昨天在推特上爆发了，我想应该用更长的篇幅回顾一下作者的一些观点，澄清一些误解，我们一个个过一遍。
【推文 1 】GraphQL 使你的公共 API 等同于一个通用数据库，更糟糕的是——一个通用图形数据库，维护工作量高得惊人；锁定查询功能意味着你只是在运行普通的 API，但不锁定它意味着无限的性能工作。（查看推文）
主张 1 ：GraphQL 使您的公共 API 等同于通用图形数据库
根据作者的说法，GraphQL 使我们的公共 API 等同于通用的图形数据库。如果您在过去几年里经常听说过 GraphQL，那么可能知道这是 GraphQL 最常见的误解之一。尽管有些 API 在设计上支持通用特性，但就像大多数 API 的风格一样，GraphQL API 是通用的还是特定的，是您自己决定的。
一个通用的 GraphQL API 与大多数人认为的最佳实践背道而驰。事实上，GraphQL 规范一直拒绝通用/类数据库功能（如过滤、排序等）的提议。
避免通用/类数据库模式在GraphQL官方网站上列为最佳实践，没有比这更明确的了。
构建一个 GraphQL 最好的模式是告诉客户端如何使用数据，而不是镜像旧的数据库模式。
公共 API 确实比内部 API 更通用一些，需要预测各种各样的场景调用，有时在客户端调用的公共 API 中也需要更“原始”的形式展示数据。虽然这不是 GraphQL。
主张 2 ：维护工作量高得离谱
这是个很有意思的轶闻。相比其它风格的 API，我没有发现使用 GraphQL 更难维护，实际上可以说它更容易维护，但这可能是有点自欺，因为很多 GraphQL 项目都是新领域，通常比累积了技术债务的遗留 API 具有更好的可维护性。准确地说，我认为维护更多的是与软件本身的编写相关，而不是具体的技术选择。我并没有在这些推文中看到一个强有力的例子来说明 GraphQL 为什么难以维护。
主张 3 ：锁定查询功能意味着你只是在使用普通的 API，而不锁定则意味着无限的性能工作
作者谈及的“锁定”像是持久查询，这意味着让 GraphQL “打开”（客户端能执行任意查询）会导致无限的性能工作，以下推文中的观点可能说得更具体。如我们所知，一个设计和实现良好的 GraphQL API 能够很好地处理任意查询，并在合理时间内提供查询服务。
锁定查询功能并不意味着你只是在使用“普通” API（不管这意味着什么），像持久化查询的服务仍然提供了很大的灵活性，服务端团队并不需要为每个新的持久化查询做额外的工作，模式（Schema）公开了这些可能性，即使查询以这种方式列入白名单（通常在构建时），但实际的调用仍由客户端决定。
【推文 2 】在任何应用程序中，管理对象生命周期都很困难，因为它们在内部具有图形化性质，公开时情况会更糟。如果可以充分考虑公开哪些连接，几乎每个系统都更容易预测和维护。 (查看推文)
我绝对同意，但这似乎与 GraphQL 无关。GraphQL API 公开的内容就是您选择公开的内容，而无需公开内部细节；重点是 GraphQL 中的连接是人为设计的，另外在 GraphQL 中避免不可预知的对象访问，与在典型的基于资源的 API 中所做相似。类似的想法也在下面的推文中。
【推文 3 】非图 API 的不良性能和生命周期错误已经够让我们心惊胆战了，面对如此大量的多对多连接时，还需要用户和我们自己来预测？这可不是人类能干的活儿，问题都成了吓人的玩意儿。（查看推文）
我认为这是 GraphQL 的一种权衡，GraphQL API 往往不能像其它 API 那样进行优化，因为它提供了一定的灵活性，这是设计的一部分，但对有些人来说这可能是设计的缺陷（尽管开销通常很小）。在构建 GraphQL API 时，有很多方法可以进行改善，比如正确设置批处理和缓存数据加载；如果您将对象类型视为 “资源”或“端点”时，安全性与其它 API 都非常相似。
【推文 4 】在 SQL 数据库中，典型的 GraphQL 需要查询中的嵌套查询和无限连接，这些都是众所周知的可靠性、性能、代码扩展性和理解性问题，是所有通用图形 API 问题的一种体现。（查看推文）
GraphQL 不需要那么复杂的 SQL 查询。其实，我很好奇作者是怎么得到的结论，这通常不是 GraphQL 执行导致的查询。如果说 GraphQL 有什么不成熟的实现，就是会为每个解析器产生大量的小查询，通过数据加载器，可以看到像是一组查询的子集（其中很多是 SELECT…WHERE…IN 查询）。如果需要构建预解析器或使用 GraphQL-to-SQL 的自动生成，才会用到查询中的嵌套查询和无限连接，只是在实际中不常见。
GraphQL 并不是一个通用的 Graph API。
【最后一条推文】另外还有一件事要讨论，如何让系统以可预测的、有限度的方式变慢，往往比让系统以不可预测的、无限度的方式变慢更有用，“不可预测”和“无限”延时通常同时出现。（查看推文）
我非常同意最后一条推文，这是一个很好的观点。GraphQL API，尤其是公共 API，不可能像服务器驱动的用例那样具有可预测性，因为服务器驱动的服务调用是预知并单独优化过的，简单实现的 GraphQL API 肯定会导致非常低效的数据加载。还好 GraphQL 的可观察性工具、数据加载技术和类库现在都有了，让我的 GraphQL API 具有预测性而且速度很快。
如果您不需要 GraphQL 的特性，那么的确不如直接丢几个 RPC 端点那样简单，而且用起来免不了带来更多的认知负担。
这个主题可以作为提醒在构建 GraphQL API 时不要做什么，然而有些地方像稻草人一样，错误地描述了 GraphQL 构建的目的。文末给大家一些小贴士：
- 不要将 GraphQL API 设计成一个图形数据库，也不要根据数据库模式设计您的 API。
- 尽可能使用异步/批处理数据加载（如数据加载器），不要创建基于预查询或 gql-to-sql 工具的复杂 SQL 查询（常规经验）。
- 如果不能有效地支持通用特性，应避免使用它们，在需要且性能满足时再添加。
- 如果 GraphQL 设计用来解决的那些问题您遇不到，那么也没有必要用它。
