我列出了一些GraphQL隐藏的障碍，在选择构建新API的方法时应牢记这些障碍。很容易爱上专业营销人员推销的技术。然而，软件工程很难，因为没有一刀切的解决方案。GraphQL多年来一直备受关注。在您将这个漂亮的首字母缩略词添加到您的简历之前，我想根据生产经验分享我的观点和想法。有大名鼎鼎的AlexXu的新鲜好料，先来看看吧，这里不再赘述。虽然我完全支持视频中提到的担忧，但我想补充几点：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为客户团队提供的灵活性伴随着不可预测的缓慢数据库查询的可能性。当然，这可以通过手动或自动测试来缓解，但值得牢记。当然，在某些情况下，这可能是不可接受的。关于GraphQLschema拼接为了解决耦合问题，就有了schema拼接的想法。简而言之，您可以采用两个或多个GraphQL模式并将它们全部合并在一起以供客户端使用，同时单独生成它们。模式联合是要走的路。但问题是，即使是这个想法也远非完美的解决方案。这就是为什么公司正在围绕GraphQL构建复杂的工具，特别是Apollo最近（截至2022年夏季）推出的Federationv2.0和超图的想法。在我看来，这些都是协议核心问题的迹象。它给软件沙堡世界增加了不必要的认知负担和架构复杂性，使其更加脆弱。关闭很明显，GraphQL减少了它解决的用例数量，并不是万灵药。在您对它提供的好处感到惊讶之前，您必须评估上面列表中提到的视频和权衡。
