您可能不需要 GraphQL！当您从一家 GraphQL 公司的联合创始人那里读到这句话时，您可能会感到惊讶。
为什么您可能不需要 GraphQL
2015 年（将近十年前！），Facebook 发布 GraphQL 后不久，GraphQL 就被炒得沸沸扬扬，因为它可以构建类型安全的 API，而且比其他任何 API 都具有更好的开发人员体验。各种各样的人都采用了它，包括
- 拥有小型团队的早期创业公司
- 打造 MVP 的独立黑客
- 构建无用户界面产品的公司
- 进行服务间通信的微服务团队
- 甚至是作为查询语言的数据库引擎团队
但 GraphQL 并不是为这些用例而设计的。
Facebook 发明 GraphQL 的初衷是将其作为众多面向最终用户的客户端与众多数据源之间的核心中介层。他们开发了一种新语言（因此也开发了工具链），使其能够跨不同语言编写的微服务工作。
这使得它成为解决 "我希望客户端数据访问是类型安全的 "这一问题的重型解决方案。不可避免的是，针对这些用例出现了更好的解决方案（如 tRPC），其采用率超过了 GraphQL。而且，随着 React 服务器组件的出现，这些用例中的许多又将得到进一步简化。
那么，谁需要 GraphQL 呢？
回答 "谁需要 GraphQL？"的困难在于 GraphQL 可以解决许多不同的问题。当你与两个使用 GraphQL 的人交谈时，你不可避免地会得到两种不同的答案，即他们为什么使用 GraphQL？
不仅如此，GraphQL 并不能明显地解决所有这些不同的问题；当你使用 GraphQL 时，许多问题就会......消失。这就很难让人意识到 GraphQL 解决了这些问题，因为你 "必须亲身经历过"，才能发现哪些问题悄然消失了。
我知道：作为经营 GraphQL 公司工作的一部分，我在过去三年中与数百家公司的数千名工程师讨论了他们的 API，尤其是使用 GraphQL 构建的 API。
让我总结一下他们告诉我 GraphQL 为他们解决了哪些问题，以及 GraphQL 是如何做到的。
GraphQL 解决的问题
1.移动应用程序在 API 更改后会定期中断
GraphQL 只返回客户端明确请求的字段，因此可以通过添加新类型或字段来增加新功能，而这对现有客户端来说绝不会造成中断。
此外，您还可以监控哪些客户正在使用哪些字段，因为他们必须准确指定他们需要的数据。
2.请求瀑布和/或过度抓取导致加载时间缓慢
使用 GraphQL，客户端只需发送一个请求，就能获得渲染整个页面/视图所需的所有数据，服务器会解析所有数据，并在一个响应中发送回来，而不会出现 BFF 带来的重复。(客户端甚至可以使用 @defer 和 @stream 指令要求服务器首先流式传输折叠数据）。
3.由于存在数百个重复的一次性端点，维护和端点发现非常困难
GraphQL 集中了每个实体/资源的数据访问。当底层微服务或数据库更改其数据管理方式时，只需将更改应用到 API 层中的单个中心位置，而无需更新许多端点或 BFF。
更进一步，GraphQL 使客户能够通过片段在组件级别上指定他们的数据需求。(例如，UserAvatar 组件可以抽象地指定它需要 UserType.avatarUrl）因此，即使在客户端，变更也必须只应用于与变更相关的特定组件！
4.安全和性能是一场 "打地鼠 "游戏
GraphQL 是客户端的中心数据访问层，因此您可以根据需要在尽可能精细的级别上执行安全和性能 SLA。与 REST API 的每个端点类似，您可以在 GraphQL 中对每个操作执行限制，但也可以更精细地对每个类型甚至每个字段进行限制。
如果您的公司遇到上述问题中的一个（或多个！），请考虑将 GraphQL 添加到您的堆栈中。
如果您现在还没有遇到这些问题，您可能会问："我什么时候会遇到这些问题？答案是很难预测，因为这取决于您的具体用例。有些公司在拥有 50 名工程师和数百万用户的情况下，并没有遇到这些问题。还有一些公司在构建 MVP 时遇到了多个问题。
根据我的经验提供一些指导：最迟当你有 100 多名工程师时，你很可能会遇到上述问题中的至少一个。
这就是为什么我的推文的大多数回复者都是对的：他们可能并不需要 GraphQL。
但有一点是肯定的：只要你遇到这些问题中的任何一个，GraphQL 都会为你解决。