为什么我不再在新项目中使用 GraphQL

在继续之前，我想先声明一下，作为一名前端工程师，我非常热爱 GraphQL。它赋予我创造的力量。

我还认为 GraphQL 对于大型工程组织来说是一个不错的选择。将 GraphQL 服务器作为不同微服务之上的 API 层，可以让前端工程师直接构建，而无需处理复杂性。

不过，对于新项目，我将不再使用 GraphQL。我对新项目的定义是：没有明确市场契合度的项目，以及团队规模较小（工程师少于 3 人）的项目。

表现

作为一名后端工程师，我讨厌 GraphQL。GraphQL 在客户端提供了很大的灵活性，但这意味着我们无法在服务端进行如此积极的优化。

确保我们的 GraphQL 服务器性能卓越需要严谨和细心。除非团队已经精通 GraphQL 性能，否则这项投资是否合理值得怀疑。例如，团队需要知道如何利用数据加载器来避免 n + 1 次查询。

安全

使用传统的 REST API，我们可以为暴露的每条路由添加安全性。而使用 GraphQL API，我们必须意识到，可能会触发无限多的查询组合。

必须谨慎组织类型和对类型的访问。我们必须确保不会意外添加暴露敏感字段的子查询。

工程师入职

GraphQL 对很多工程师来说还很陌生。传统的 REST API 对很多工程师来说都很熟悉。但在真正高效工作之前，GraphQL 是必须额外学习的一项技能。

当我们想要学习 GraphQL，或者真的很喜欢使用它时，我们很容易就会选择它。在使用 GraphQL 之前，我们应该问问自己：“在项目早期，这种权衡是否值得？”

结论

有人认为，如果项目发展壮大后我们最终的目标是 GraphQL，那么就应该从 GraphQL 开始。如果项目发展壮大有保证，那么我同意。

然而，如果我们不确定我们的项目能否在6个月内，在30多名工程师的共同努力下取得巨大成功……我相信走更传统的路线会让团队更灵活，更容易引进人才。时间至关重要，GraphQL 可以在组织成熟后再添加。