主要观点：GraphQL 技术起初受关注，作者曾是其支持者，但随着时间推移，在安全、性能、维护性等方面的考虑下，作者认为如今不应向大多数人推荐 GraphQL，而应考虑其他替代方案。
关键信息：

• 攻击面：暴露查询语言给不受信任的客户端增加了应用的攻击面，需确保每个字段都经过适当授权，GraphQL 处理授权比 REST 更复杂；还存在查询大小无限制导致的性能问题和查询解析可能导致的内存问题。
• 性能：在性能方面，GraphQL 与 HTTP 缓存不兼容并非问题，主要问题是数据获取的 N + 1 问题，在 GraphQL 中因是查询语言，客户端修改查询可能导致该问题，在 REST 中可将嵌套查询提升到控制器处理；授权的 N + 1 问题更难处理，在 GraphQL 中比 REST 更常见。
• 耦合性：在成熟的 GraphQL 代码库中，业务逻辑被迫进入传输层，测试应用时必须在集成层进行大量测试，调试更困难。
• 复杂性：为解决安全和性能问题而采取的各种缓解措施增加了代码库的复杂性，REST 解决方案对后端开发者来说更简单。
• 替代方案：如果控制所有客户端、客户端数量较少、客户端使用静态类型语言且服务器和客户端使用多种语言，最好暴露符合 OpenAPI 3.0 + 的 JSON REST API。有“实现优先”和“规范优先”两种实现方式，“实现优先”如 Python 的 FastAPI 和 TypeScript 的 tsoa，“规范优先”如 TypeSpec 可生成 OpenAPI YAML 规范及各种类型的代码。
  重要细节：
• 以 Ruby 代码结合 graphql-ruby 库为例说明问题；
• 提到常见的缓解攻击的方法，如与授权框架集成等；
• 举例说明各种性能问题和代码耦合的情况；
• 介绍不同语言在处理类似问题时的工具和方法，如 Ruby 的 rswag 等。