GraphQL是一种用于API的查询语言，同时基于你的现有数据来执行这些查询的服务端运行时。它为API中的数据提供了一套易于理解的完整描述，并让客户端能准确地获得它们所需的查询内容，且不会附带任何冗余信息。

最初，GraphQL只是Facebook为其移动APP开发的内部解决方案，后来向社区开源。

优点

1. 实用的数据交换

使用GraphQL时，开发者可以根据客户端需要的字段对查询进行灵活定义，这样“量体裁衣式”的自定义非常实用，而且执行起来十分简单。如果前端需要一个人的“名字”和“年龄”，GraphQL就能只对这两个字段进行查询。而这个人的“姓”和“地址”就不会在该查询的响应中被发送。

2. 使用数据加载器来减少网络调用

尽管GraphQL库本身并不包含数据加载器（Dataloader），但是数据加载器的确是一个非常实用的程序库，可以用来解耦你的APP中互不相关的部分，还不会牺牲批处理数据加载的性能。虽然数据加载器提供了一个加载单个值的API，但所有并发请求将被组合起来并提交给你的批处理加载函数。这就能让你的APP在整个应用程序中安全地执行分布式数据获取。

举个例子：在上述例子的基础上，这次我们从另一个叫做“交易服务”的服务中获取一个“人”的“银行信息”，这时后端可以从“交易服务”中获取相关的“银行信息”，然后将这个结果与这个“人”的“名字”和“年龄”捆绑在一起，再将这些信息资源作为响应发送回去。

3. 在公开数据和数据库模型之间进行解耦

GraphQL的一大优点是能以解耦的方式将数据库建模数据对用户进行选择性地公开。这样，在对持久层（persistence layer）进行设计时，我们可以在聚焦于该层需求的同时，兼顾考虑怎样才是向外部世界公开数据的最佳方式。该功能还能与数据加载器联合起来使用，因为你可以在将数据发送给用户前将这些数据组合在一起，这样一来为公开数据设计模型就会变得非常容易。

4. 摆脱API版本控制的烦恼

API版本控制是一个经常遇到的问题。一般而言，通过在相同的API前面添加一个v2标签来添加一个新版本来解决这个问题是相当简单的解决方案。但使用GraphQL时情况就大不相同了，尽管你还是可以使用上述解决方案来处理这个问题，但这并不符合GraphQL的自由精神。GraphQL的文档明确指出，你应该升级你的API，这意味着在不破坏原API的情况下向现有端点添加更多字段。前端仍然可以使用相同的API进行查询，并且在需要的时候请求新字段。就是这么简单。

这个特性在与前端开发团队协作时非常有用。由于设计更改，前端团队可以请求添加所需要的新字段，而后端团队可以轻松地实现该字段的添加，且不会扰乱现有的API。

5. 前后端团队独立开发

使用GraphQL，前端和后端团队可以彼此独立地工作。由于GraphQL包含严格类型定义的schema，前后端团队可以互不干扰地并行工作。首先，前端团队甚至在无需查看代码的情况下，就可以很容易地从后端生成schema。而这个生成的schema可以直接用于查询的创建。其次，前端团队还可以一直使用API的mock版本进行开发工作。他们还可以用mock版本来测试代码。这为开发人员提供了相当令人愉悦的体验，且完全不会对他们的开发工作造成任何妨碍。

缺点

1. 并不是所有的API都可以升级

有时，由于来自业务或设计的变化日积月累，迫使API的实现需要完全更改。在这种情况下，你将不得不依赖旧的方法来进行API版本控制。

2. 难维护的代码

我遇到过好几次，在使用数据加载器来获取数据时，代码有时会分散到多个地方，这对代码的维护造成了一些困难。

3. 响应时间长

由于查询可以不断升级并变得非常庞大，这有时会影响查询的响应时间。要避免这种情况，请确保让响应资源保持简洁。这方面的指南，请查看Github GraphQL API。

4. 缓存困难

通常对一个API响应进行缓存的主要目的是能更快地从未来的请求中获得响应。与GraphQL不同，REST的API所利用的是将缓存内置于HTTP技术规范中。正如前面提到的，一个GraphQL查询可以请求资源的任何字段，这就使得在GraphQL里使用缓存天生就很困难。

结论

我个人强烈推荐使用GraphQL作为REST API的替代品。GraphQL所提供的极大灵活性让它的缺点瑕不掩瑜。当然这里提到的优点和缺点可能并不总是适用于所有应用场景，但是值得在决定是否使用GraphQL时纳入考虑，希望我所提供的这些意见是否可以对你的项目有所帮助。

英文原文：

6 Months Of Using GraphQL

创作场景

用了 6 个月的 GraphQL，真香！