apollo graphql mysql_GraphQL实战（后端篇：apollo-server-koa + koa）

image

前言

什么是GraphQL?

简而言之就是用于API的查询语言。你可以理解为只需要一次请求加上点查询参数，就可以定制任何后端有的信息。

在继续讲GraphQL之前我们先来看看我们常用的RESTFul接口(REST和RESTFul的关系就像Beatuy和Beautiful的关系)的优缺点(没缺点我们换它干啥)

RESTFUL接口的优缺点

RESTFul接口在历史上最大的贡献在于实现了前后端分离以及后端的无状态设计(后端无状态设计就是后端的资源不需要建立session，完全依赖客户端的请求)。

优点：

不仅有http状态码可供错误机制处理还可以方便的自定义错误码

缺点 :

接口冗长。(随着业务的不断丰富，单个RESTFul接口可能变得越来越冗长)

文档难于维护。(RESTFul文档的维护缺失是个很耗人力的事)

无法自定义相应结果。(有时候我只需要一个用户名，接口RESTFul给我返回了一大堆不需要的字段)

效率低下。(如果用RESTFul接口的话，经常会遇到需要几个RESTFul接口才能完成的展示页面的情况)

针对RESTFul的缺点，GraphQL就应运而生了。来看下它的优缺点：

优点

自定义查询API，体验好。(后端性能是否提高暂且不论，但是前后端代码减少了不少，一个接口搞定所有需要的信息)

文档自动生成。(再也不需要人工维护文档了，可以往下看，有例子)

可以自定义查询结果。(接口调用者决定需要哪些字段，后端会根据前端的查询参数返回定制的字段)

缺点

无http状态码。(无论查询条件是否正确，http状态码返回的都是200,而且自定义的状态码不好处理)

无缓存(据说Apollo GraphQL这个项目已经集成了，具体插件是apollo-cache-inmemory);

以上大致讲了下GraphQL的一个优缺点，自然也能大致了解其应用场景，在GraphQL还没有完全解决它的缺点之前，我们可以将其和RESTFul接口搭配使用。接下来我们基于koa 2.5.1 和 apollo-server-koa 2.4.8 进行实战演练

由于我这个项目是之前基于RESTFul接口的，这里我将GraphQL集成到上面(也就是在后端返回和前端之间加入GraphQL这层拦截层)。

先看下项目结构