GraphQL学习之实践篇

前言

两篇文章学完了GraphQL(基础篇, 原理篇)，接下去即是实践的过程，这个实践咱们使用了以下技术栈去实现一套任务管理系统，源码就不公开了, 等稳定后再发布。效果以下：

使用的技术栈有：

1. React16全特性
2. Antd构建UI界面
3. create-react-app搭建客户端基础
4. react-apollo完成客户端请求的封装和响应体的处理
5. bizcharts(g2)实现图表
6. apollo-boost(graphql)完成客户端数据请求
7. rxjs完成某部分响应式设计
8. 全程使用ramda.js作函数式编程
9. Nest框架作服务器
10. 数据库选择moogoose
11. passport搭配jsonwebtoken作用户认证管理
12. graphql-server(@nest/graphql)实现服务端graphql请求的处理

项目结构

以下图：

分为两大部分：client和server，其中client的目录结构以下：

各个目录的解释在图中已经体现。

server端的目录结构以下：

各个目录的含义的解释在图中已经体现。

由于咱们主要是讲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文件中就可使用这个查询语句，以下：

整个流程是很清晰的，由于使用了typescript，因此在客户端能够引用到服务端定义的返回类型，从而提升了代码编写的速度。

实践出来的问题和想法

1. react-apollo目前发现了个bug，若是我返回的数据的层级太深，好比达到了4层以上，数据更新到缓存的时候便会出错。
2. 关于graphql的本地状态的管理略微复杂，若是有个请求的结果从一开始就一直被全部的页面使用，通常一些公共的信息，好比用户名等，这种状况下想要直接拿到的话是不大可能的，须要绕一大圈去实现，有点蛋疼~
3. 分页的功能分为游标式和skip式，很明显游标式并不适用于web端，虽然游标式对数据是很是友好的。在移动端用游标式更加适合。
4. 本地状态管理是graphql的一个很厉害的功能，直接不须要任何数据管理框架，就能够实现数据的各类操做，这是一大亮点！
5. 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: []
})
复制代码

服务端业务层级的实现

每一个业务目录都会存在这么些文件：

咱们在dto目录下定义三种类型文件：xx.args.ts/xx.input.ts/xx.model.ts，分别定义下面三种状况

1. args对应请求不是Input类型的
2. input对应请求是Input类型的
3. 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啊？

服务端实践的思考

1. 数据库的model和graphQL定义的model大体相同，两者如何更好地契合在一块儿？目前社区并无给出对应的解决方案。
2. 由于graphql只有一个endpoint，因此打印请求就不能像以前restful那样，须要一个与之对应的打印方案
3. 如何结合swagger实现文档级别的呈现？亦或是不须要swagger，而是依靠schema去呈现文档给客户端，值的深刻研究，并给出解决方案
4. graphql号称解决版本的兼容性问题是垂手可得的，目前在本项目中并无体现到。

最后

至此，三篇关于GraphQL的文章到此结束了，花了不少时间断断续续地学习，但愿能够给你们呈现一份不同地文章，供你们思考。后续我所在的公司网关团队会持续实践GraphQL，争取贡献出更多的解决方案。