Node.js 服务端实践之 GraphQL 初探
本文来自淘宝前端团队的云翮，讲述了GraphQL的使用场景和如何自己搭建一个GraphQL服务器。
DT 时代，各种业务依赖强大的基础数据平台快速生长，如何高效地为各种业务提供数据支持，是所有人关心的问题。
现有的业务场景一般是这样的，业务方提出需求，然后寻找开发资源，由后端提供数据，让前端实现各种不同的业务视图。这样的做法存在很多的重复劳动，如果能够将其中通用的内容抽取出来提供给各个业务方反复使用，必然能够节省宝贵的开发时间和开发人力。
前端的解决方案是将视图组件化，各个业务线既可以是组件的使用者，也可以是组件的生产者。那么问题来了，前端通过组件实现了跨业务的复用，后端接口如何相应地提高开发效率呢？
我们假设某个业务需要以下数据内容 a：
{
user(id: 3500401) {
id,
name,
isViewerFriend
}
}对，这不是 JSON，但是我们仍然可以看懂它表示的是查询 id 为 3500401 用户的 id，name 和 isViewerFriend 信息。用户信息对于各个业务都是通用的，假设另外一个业务需要这样的用户信息 b：
{ user(id: 3500401) { name, profilePicture(size: 50) { uri, width, height } }} |
|---|
对比一下，我们发现只是少了两个字段，多了一个字段而已。如果要实现我们的目标，即复用同一个接口来支持这两种业务的话，会有以下几种做法：
- 用同一个接口，这个接口提供了所有数据。这样做的好处是实现起来简单，但缺点是对业务做判断的逻辑会增多，而且对于业务来说，响应内容中有些数据根本用不到；
- 使用参数来区分不同的业务方并返回相应的数据。好处仍然是实现简单，虽然不会有用不到的数据返回，但是仍然需要增加业务逻辑判断，会造成以后维护的困难。
此外，这样还会造成不同业务之间的强依赖，每次发布都需要各个业务线一起测试和回归。不重用接口则没法提高开发效率，重用接口则会有这些问题，那么到底有没有“好一点”的解决方案呢？
这是我们在处理复杂的前后端分离中经常要面临的一个思考。
本文主要分为以下五部分，这里节选了第一部分问题和第五部分结论。
- 问题来了
- GraphQL 一种新的思路
- 使用 Node.js 实现 GraphQL 服务器
- 检查服务器
- 总结
至此我们已经实现了一个 GraphQL 基础服务器。在实际业务中数据模型肯定会更加复杂，而 GraphQL 也提供了强大的类型系统（Type System）让我们能够轻松地描述各种数据模型，它提供的抽象层能够为依赖同一套数据模型的不同业务方提供灵活的数据支持。关于 GraphQL 在淘宝更多的生产实践，请持续关注我们博客未来的系列文章。