我列出了一些 GraphQL hidden rocks，当您选择构建新 API 的方法时应该牢记这些。
很容易爱上专业营销人员销售的技术。然而，软件工程很难，因为没有一种解决方案可以适用于所有情况。
GraphQL 几年来一直是人们关注的焦点。在您将这个好看的缩写添加到您的简历之前，我想分享一下根据生产经验总结的观点和想法。有大名鼎鼎的Alex Xu的新鲜好料，大家先看看，这里不赘述，不赘述。
虽然我完全支持视频中提到的担忧，但我想补充几点：
GraphQL 不会取代 REST 或 SOAP
这只是构建 API 的另一种方式，但绝对不是“最好的方式，因为新的”。我什至会说它更像是用于更具体业务案例的 SOAP。下面我将通过展示它们之间的相似之处来提供更多关于这一点的细节。
创建 GraphQL 是为了解决一些特定问题
它涵盖了以下情况：
- 您正在开展业务，其中大多数用户都是通过“智能手机”运行的。此类用户经常在移动时切换网络/ISP，并且可能使用不可靠或不良的连接。基本上，GraphQL 允许您执行较少数量的从移动应用程序到 API 的请求。然而，细节决定成败。
- 您可以轻松地将所有数据(您需要在客户端/UI 上使用的数据)放入单个数据模型(或数据图)中。这可能是因为您从事大数据工作，或者有统一的方式来表示来自各种来源的信息。
GraphQL 允许您优化开发团队的吞吐量，方法是让您的前端团队考虑他们想从 API 中获得什么，而不是您的后端团队提出他们的数据模型或猜测什么是最佳 API 和数据模型。每次需要更改 UI 端时都等待 API 更改(后端工程师)，效率不是很高。因此，UI 开发人员很高兴，因为他们可以使用数据并找到各种使用或显示数据的方法。但是，他们的知识是否足以安全地执行此操作?这种好处是有代价的。
GraphQL 带来了权衡
不过，它要求您做好一些准备：
您必须生成 API 的架构，就像在 SOAP 的情况下一样。这并不是什么新鲜事，当您独自负责后端和前端(构建“Hello，World!”)时，这可能看起来很正常。当您的团队可以挤在一个房间(或共享 2 个比萨饼)并且可以非常快速地轻松地互相交谈时，这没关系。但是，如果您的团队很大和/或频繁更新 API 对象，您很快就会厌倦这个过程。每次后端工程师更新 API 并重新生成架构时，他们都必须与一些需要获取更新的对等方建立连接。他们必须花费更多精力来构建和维护额外的 CI 自动化步骤，以及使用聊天、信使等更好、更频繁地进行交流。显然，. 它无法像 REST 那样在实验中提供如此大的灵活性。
它将API 性能的控制权从后端开发团队手中转移到客户(UI/客户端开发团队)手中。使用其强类型 GraphQL 可以实现所谓的客户端指定查询。在更坏的情况下，它会导致N+1 问题。GraphQL 为客户团队提供的灵活性伴随着进行不可预测的缓慢数据库查询的可能性。当然，这可以通过手动或自动测试来缓解，但值得牢记。当然，在某些情况下这可能是不可接受的。
关于 GraphQL 模式拼接
为了解决耦合问题，有模式拼接的想法。简而言之，您可以采用两个或多个 GraphQL 模式，并将它们全部合并在一起以供客户端使用，同时单独生成它们。模式联合是要走的路。
但问题是，即使是这个想法也远非完美的解决方案。这就是为什么公司围绕 GraphQL 构建复杂工具的原因，特别是 Apollo 最近(截至 2022 年夏季)引入了Federation v2.0 和 supergraph 的想法。
在我看来，这都是协议核心出现问题的迹象。它给软件沙堡世界增加了不必要的认知负担和架构复杂性，变得更加脆弱。
结束
显然，GraphQL 缩小了它解决的用例数量，并不是灵丹妙药。在您对它提供的好处感到惊讶之前，您必须评估视频和上面列表中提到的权衡。
