前端开发使用GraphQL——服务端技术选型

在阅读这篇文章之前，首先要清楚并不是全部场景都适合使用GraphQL。在你决定使用GraphQL之前你最好仔细调研一下使用GraphQL能给你的项目带来什么好处，不然晋升答辩考核的时候，大概率你都不知道怎么描述自己的业绩。这里可以参考下文章《5个用/不用GraphQL的理由》

背景

我们的业务后台使用开发rpc服务，然后通过包一层http给前端调用。因为历史遗留问题，前期项目赶进度导致遗留了很多技术债。例如：

• 接口存在很多冗余字段
• 字段命名不规范
• 接口文档很多丢失、过时
• 部分接口功能耦合
• 实现一个功能的能力分散在多个接口里面
• ETC...

不管怎么样，我们后台提供的RPC服务都是需要包一层http后我们前端才能使用，因此，使用GraphQL来作为我们服务的接入层，可以比较好的解决这些问题，在GraphQL层调用后台RPC服务，然后以对外提供http接口。因为本人是前端开发，对nodejs比较熟悉，所以选择在nodejs运行环境下开发GraphQL服务，下面开始我的技术选型

开发语言选择

2021年了，新项目基本都是使用typescript。虽然使用typescript比起javascript来说有一定的学习成本，但是他引入了静态类型检测，给项目带来了更大的可靠性和更强的代码可读性。新项目必须上typescript。

Nodejs框架选择

• express：生态丰富，但是过于简单，自己需要实现很多其他内容
• koa: 同上，生态丰富，但是过于简单，自己需要实现很多其他内容
• eggjs: 阿里基于koa开发的框架，插件丰富，文档优秀，有GraphQL插件，但是对使用TS开发GraphQL支持不友好
• nestjs: 完全支持typescript，官方支持GraphQL
• etc...

express与koa都太过简单，不适合直接拿来使用，egg文档优秀，社区内容也丰富，但是对typescript和GraphQL的支持都比较有限，最终决定使用nestjs，nestjs是基于typescript开发的框架，官方也直接支持了GraphQL，中英文档完善，git star数量也够多。

GraphQL实现模块选择

选择模块之前，先明确下需求，既然决定了使用typescript，那就要选择一个typescript支持程度高，社区生态丰富，文档齐全的热门模块。目前大概有以下这些模块可以选择。

• GraphQL-JS：由 脸书官方提供的实现。几乎是一切其他模块的基础。
• Type-GraphQL： typescript开发的实现，主要是输出可执行 Schema。
• Apollo GraphQL: Apollo 提供的实现和 GraphQL 生态，内容丰富，不止一套引擎，还提供了纯客户端使用等多种工具。
• Nestjs/GraphQL: Nestjs框架基于typescript实现的GraphqL模块。

这些模块本质上都是通过解析类或者文本生成可以执行的Schema,然后交由GraphQL-JS或者apollo-server执行。区别在于组织代码的方式上，具体的区别这里不展开，有兴趣可以参考GraphQL 落地背后：利弊取舍

使用 typescript 开发 GraphQL 时，一般要基于 typescript 对数据定义模型，也要在 Schema 中定义数据模型。使用Type-GraphQL或者Nestjs/GraphQL可以帮助我们省略Schema模型定义，他们会基于Class编译出执行需要的schema。

因为选择了typescript作为开发语言，所以这里我选择Nestjs/GraphQL，因为他对typescript和GraphQL的支持最好，文档完善，社区生态好。

小结

最终在对比了各种方案后，我们选择了基于nestjs使用typescript开发GraphQL 服务。