GraphQL学习之实践篇
前言
两篇文章学完了GraphQL(基础篇, 原理篇)，接下去便是实践的过程，这个实践我们使用了如下技术栈去实现一套任务管理系统，源码就不公开了，毕竟还在职~。效果如下：
image
使用的技术栈有：
- React16全特性
- Antd构建UI界面
- create-react-app搭建客户端基础
- react-apollo完成客户端请求的封装和响应体的处理
- bizcharts(g2)实现图表
- apollo-boost(graphql)完成客户端数据请求
- rxjs完成某部分响应式设计
- 全程使用ramda.js做函数式编程
- Nest框架做服务器
- 数据库选择moogoose
- passport搭配jsonwebtoken做用户认证管理
- graphql-server(@nest/graphql)实现服务端graphql请求的处理
项目结构
如下图：
image
分为两大部分：client和server，其中client的目录结构如下：
image
各个目录的解释在图中已经体现。
server端的目录结构如下：
image
各个目录的含义的解释在图中已经体现。
因为我们主要是讲graphql的应用，所以其余的细节忽略不说。至于Nest框架的使用，请参考文档Nest.js
GraphQL的实践
实践GraphQL我们不会直接用graphql-js，而是使用功能更加丰富、社区支持更多apollo-graphql。其文档编写的也是很详尽，基本上所有的问题都可以在文档上找到答案。推荐新手可以先按照Get started来入手
客户端的实践
初始化
因为我们使用了apollo-boost，所以在前端入口文件上，要拿这个包进行一些初始化，得到apolloClient的实例(无关的代码已经去掉)：
import React from 'react';
import ReactDOM from 'react-dom';
import { ApolloProvider } from 'react-apollo';
import ApolloClient from 'apollo-boost'
... ...
const GW_BASE_URL = process.env.NODE_ENV === 'production' ? '/graphql' : 'http://127.0.0.1:8888/graphql'
const client = new ApolloClient({
uri: GW_BASE_URL,
// 需要设置这个，这样每次请求的时候认证信息才会带上
fetchOptions: {
credentials: 'include',
},
// 缓存读取配置
clientState: {
typeDefs,
resolvers,
},
// 设置这个是为了配合jwt
request: async (operation) => {
// get the authentication token from local storage if it exists
const token = localStorage.getItem('token');
operation.setContext({
headers: {
authorization: token ? `Bearer ${token}` : '',
Origin: location.href,
},
});
},
// 设置全局错误处理信息，这样就不用每个请求都进行error处理
onError: (errObj) => {
if (errObj.graphQLErrors) {
const errorMsg = errObj.graphQLErrors[0].message;
if (errorMsg === '身份信息已过期，请重新登录') {
... ...
message.info(errorMsg, 3, () => location.hash = '#/user/login');
} else if (errorMsg && (errorMsg as any).statusCode === 403) {
message.error('权限不足，请不要重试');
} else {
message.error(errorMsg);
}
}
},
});
ReactDOM.render(
<ApolloProvider client={client}>
<LocaleProvider>
<App />
</LocaleProvider>
</ApolloProvider>,
document.getElementById('root'),
);
页面级别的使用
每个页面都会新建三个文件：
graphql.ts
index.scss
index.tsx
其中graphql.ts定义了客户端的请求，比如：
import gql from 'graphql-tag';
// 用来查询所有的用户
export const QUERY_USERS = gql`
query {
userList {
id
roles
team
mobile
staffCode
email
username
}
}
`;
而后在index.tsx文件中就可以使用这个查询语句，如下：
image
整个流程是很清晰的，因为使用了typescript，所以在客户端可以引用到服务端定义的返回类型，从而提高了代码编写的速度。
实践出来的问题和想法
-
react-apollo目前发现了个bug，如果我返回的数据的层级太深，比如达到了4层以上，数据更新到缓存的时候便会出错。 - 关于graphql的本地状态的管理略微复杂，如果有个请求的结果从一开始就一直被所有的页面使用，一般一些公共的信息，比如用户名等，这种情况下想要直接拿到的话是不大可能的，需要绕一大圈去实现，有点蛋疼~
- 分页的功能分为游标式和skip式，很明显游标式并不适用于web端，虽然游标式对数据是非常友好的。在移动端用游标式更加适合。
- 本地状态管理是graphql的一个很厉害的功能，直接不需要任何数据管理框架，就可以实现数据的各种操作，这是一大亮点！
- apollo-graphql也提供了开发者工具，可以在浏览器实时预览当前缓存的所有数据Developer tools
服务端实践
因为服务端使用了Nest.js，所以没有直接用apollo提供的服务器，而是用了Nest框架封装出来适用于Nest框架的graphql包graphql。该包还是提供了很多功能的。
服务端GraphQL的初始化
在app.modules.ts中，我们要去初始化graphql模块(无关代码已忽略)：
@Module({
imports: [
GraphQLModule.forRoot({
// 指定服务端schema存放的位置
typePaths: ['graphql/schema.graphql'],
// 配置了该选项，可以自动根据代码生成schema
autoSchemaFile: path.join(__dirname, 'graphql/schema.graphql'),
buildSchemaOptions: {
},
// 可以自动生成types文件
// definitions: {
// path: path.join(__dirname, 'types/graphql.ts'),
// },
debug: true,
playground: true,
context: ({ req }) => ({ req }), // 一定要这里设置req到上下文中，否则在guard中是拿不到这个req参数的
}),
],
controllers: [],
providers: []
})
服务端业务层级的实现
每个业务目录都会存在这么些文件：
image
我们在dto目录下定义三种类型文件：xx.args.ts/xx.input.ts/xx.model.ts，分别定义下面三种情况
- args对应请求不是Input类型的
- input对应请求是Input类型的
- model对应请求的响应体
而后在xx.resolver.ts中实现resolve函数，借助于修饰器，比如：
import { Query, Resolver, Args, Mutation } from '@nestjs/graphql'
@Resolver('User')
export class UserResolver {
@Query(returns => [UserItem])
... ...
async userList(): Promise<UserItem[]>{
return this.userService.getUserList();
}
}
UserItem在这里(user.model.ts)定义：
import { ObjectType, Field, ID, registerEnumType, Int } from 'type-graphql'
... ...
@ObjectType()
export class UserItem {
@Field(type => ID, {nullable: true})
_id?: number;
@Field({nullable: true})
username?: string;
@Field({nullable: true})
email?: string;
... ...
}
如此便完成了整个服务端数据流的过程。看着是不是很easy啊？
服务端实践的思考
- 数据库的model和graphQL定义的model大致相同，二者如何更好地契合在一起？目前社区并没有给出对应的解决方案。
- 因为graphql只有一个endpoint，所以打印请求就不能像之前restful那样，需要一个与之对应的打印方案
- 如何结合swagger实现文档级别的呈现？亦或是不需要swagger，而是依靠schema去呈现文档给客户端，值的深入研究，并给出解决方案
- graphql号称解决版本的兼容性问题是轻而易举的，目前在本项目中并没有体现到。
最后
至此，三篇关于GraphQL的文章到此结束了，花了很多时间断断续续地学习，希望可以给大家呈现一份不一样地文章，供大家思考。后续我所在的公司网关团队会持续实践GraphQL，争取贡献出更多的解决方案。
