前言

目前网络上很多 GraphQL 入门文章, 但缺少一些全栈的工程化落地指导和性能优化的文章.

本文会先简单带大家简单过一下 GraphQL 简介和规范、前后端如何配合使用, 避免新手缺少一些必要的上下文, 之后会专注于介绍 GraphQL 前端工程化和性能的优化. 由于作者们全是前端开发人员, 所以我们会使用前端最熟悉的 react + nodejs 体系来阐述.

正文

因何而起: GraphQL 简介和规范

GraphQL 是怎样开始的？

向移动的转变

GraphQL 的起源可追溯到这个行业向移动的转变。当时，Facebook 的移动战略（即，在移动设备上采用 HTML5）由于网络的使用量过高而未能实现。结果，Facebook 决定使用原生技术从头构建 iOS 应用程序。

在移动端实现 Facebook 新闻推送的是一个主要问题。这不是像获检索一个故事、作者、故事的内容、评论列表和喜欢该文章的人这么简单。每个故事都相互关联、嵌套和递归的。现有的 API 没有被设计成允许开发人员在移动设备上展示一个丰富、类似新闻推送的体验。它们没有层次性，允许开发人员选择他们所需要的，或有显示异构推送故事列表的能力。

传统 REST API 的局限性

一次 REST 查询全量返回数据, 存在前端过度获取的情况

页面需要多接口拼接, REST 需要针对每个接口发一次请求

嵌套查询实现复杂

无运行时类型约束

在 2012 年，Facebook 决定，他们需要构建一个新的新闻推送 API，以构建 Facebook 的移动应用程序。这就是 GraphQL 开始成形的时间，并且，在 8 月中旬，Facebook 发布了采用新 GraphQL 技术的 iOS5.0 应用程序。它允许开发人员通过利用其数据获取（data-fetching）功能来减少网络的使用。在接下来的一年半时间里，除了新闻推送外，GraphQL API 扩展到大多数的 FacebookiOS 应用程序。在 2015 年，GraphQL 规范首次与 JavaScript 中的引用实现一起发布。

GraphQL 查询长什么样?

一个 GraphQL 操作可以是一个查询（query（读操作））、修改（mutation（写操作））以及订阅（subscription（持续读操作））, 其规范如下, 我们举例说明:

例子 1

前端请求格式:

{





  user {


    name


}

服务端返回格式:

{





  user: {

    name: "张三"
}

例子 2

前端请求格式:

{





  user {


    name


    age

   }

}

服务端返回格式:

{





  user: {

    name: "张三",
    age: 18
   }

}

例子 3

前端请求格式:

{





  user {


    name


    age

    friends {
      name
      age
    }
  }
}

服务端返回格式:

{





  user: {
    name: "张三",
    age: 18,
    friends: [
      {
        name: "李四",
        age: 18
      },
      {
        name: "王五",
        age: 18
      }
    ]
  }
}

GraphQL 是怎么解决 REST API 遇到的问题的?

前端按需获取字段: GraphQL 将视角转移到前端，由前端决定它需要的数据, 而不是服务器。这是最初发明 GraphQL 的主要原因.
前端聚合多查询为一次 HTTP 请求.
更好的嵌套查询支持
严格定义的数据类型可减少前端与服务器之间的通信错误(后面会介绍到)。

GraphQL 的主要组件

实际上，GraphQL API 使用了 3 个主要的组件：

前端查询 query 语句: 是前端发出的请求
服务端 GraphQL Server Schema: Schema ****描述了前端一旦连接到 GraphQL 服务器就可以使用的功能(可获取的数据结构和字段类型等信息)。
服务端 GraphQL Server 解析器 resolver: 除非我们告诉 GraphQL 服务器该做什么，不然它不知道如何处理它得到的前端查询。这个工作是用解析器 resolver 来完成的。简单地说，resolver 告诉 GraphQL server 如何（及从何处）获取与特定字段对应的数据。你可以在 resolver 里查询数据库或者转发 http 请求等方式来获取数据源.

接下来我们看下这 3 个组件如何实现一个 api 查询.

如何使用: React + Apollo Client + Apollo Server 的配合使用

Apollo 是一个实现了 GraphQL 协议的开源框架, 支持多种主流编程语言

Apollo Server 服务端: 链接

const { ApolloServer, gql } = require("apollo-server");
const { userDB, favorateDB, placeDB } = require("./mockDB");



// Construct a schema, using GraphQL schema language const typeDefs = gql`
  type Query {
    user(id: ID!): User
  }
  type User {
    id: ID
    name: String
    age: Int
    friends: [User]
    favorate: [Project]
  }
  type Project {
    projectName: String
    places: [Place]
  }
  type Place {
  
    location: String
    price: Float
  }

`;



// Provide resolver functions for your schema fields const resolvers = {
  Query: {
    user: (root, args) => {
      console.log("user resolver", root, args);
      return userDB.find(({ id }) => id === args.id);
    }
  },
  User: {
    friends: (root, args) => {
      console.log("friends resolver", root, args);
      const friendIDs = root.friendIDs || [];
      return userDB.filter(({ id }) => friendIDs.includes(id));
    },
    favorate: (root, args) => {
      console.log("favorate resolver", root, args);
      const _userId = root.id;
      return favorateDB.find(({ userId }) => userId === _userId).favorates;
    }
  },
  Project: {
    places: (root, args) => {
      console.log("Project resolver", root, args);
      const projectName = root.projectName;
      return placeDB.find((place) => place.projectName === projectName).places;
    }
  }
};

const server = new ApolloServer({
  typeDefs,
  resolvers
});

server.listen().then(({ url }) => {
  console.log(`? Server ready at ${url}`);
});

React + Apollo Client 客户端 : 链接

// index.tsx
import { React } from "react";
import * as ReactDOM from "react-dom/client";
import { ApolloClient, InMemoryCache, ApolloProvider } from "@apollo/client";
import App from "./App";




 // 此处 uri 需要是上面 apollo server 启动地址 const client = new ApolloClient({
  uri: "https://s6x0sp.sse.codesandbox.io/",
  cache: new InMemoryCache()
});



const root = ReactDOM.createRoot(document.getElementById("root"));


root.render(
  <ApolloProvider client={client}>
    <App />
  </ApolloProvider>
);

// App.tsx
import { useQuery, gql } from "@apollo/client";



const getUser = gql`
  query getUser($id: ID!) {
    user(id: $id) {
      name
      age
      friends {
        name
        age
      }
      favorate {
        projectName
        places {
          location
          price
        }

      }
    }
  }
`;


function User() {
  const { loading, error, data } = useQuery(getUser, {
    variables: {
      id: "1"
    }
  });
  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error :{error.message}</p>;
  return <pre>{JSON.stringify(data, null, 2)}</pre>;
}


export default function App() {
  return (
    <div>
      <h2>My first Apollo app</h2>
      <User />
    </div>
  );
}

如何写的更爽, 提示协作体验和效率： GraphQL 前端工程化

运行时类型校验，提升开发体验，减少前端页面崩溃

GraphQL 本身有运行时强校验功能，同时搭配前端 TS 技术栈，整体代码仓库在类型安全得到很大的提升。在前端开发中，如果接口入参和返回值的类型得到保证，则内部业务逻辑的各种组件和工具函数，一般就自然而然的具备了比较好的类型安全能力。从而在最大程度上保证了代码的类型安全，可有效降低前端页面实际运行中崩溃的概率。

下面是一个示例，在接口联调过程中，后端接口应该返回一个枚举，但实际返回了空字符串，能一眼根据报错就知道是后端 API 处理出现问题。

减少手写冗余代码

借助一个轻巧的 bamToGraphql （需要先登录谷歌账号）浏览器扩展和 codegen 工具，尽量避免手写冗余代码，通过自动化和半自动化工具，我们可以将前端的一个查询语句自动生成一个开箱即用的 useQuery hook 函数，同时具备准确的类型提示和安全能力。下面是一些截图示例：

bamToGraphql 根据 bam 类型自动生成 GraphQL 对应类型：

自动生成的 useListNodeQuery，不需要手写和传入任何类型，但其实完全类型安全，初次书写，和后续改动都很方便。

如何做性能的优化

浏览器减负

Apollo Client 缓存机制的合理利用

在 Web 侧技术栈中，我们选择了比较流行和成熟的 Apollo Client 开源工具，没有自造轮子。Apollo Client 自带非常完备的缓存机制，具体策略在此不详细展开，可参见官方文档。如果业务在持续迭代和优化过程中，需要使用缓存时，我们可以合理利用已有能力，以很低的成本实现相关需求。比如下面这个例子，就属于比较高级的用法，充分体现了 Apollo Client 基于 GraphQL 所提供细粒度缓存能力：

// 片段可以让我们更灵活的读取或更新缓存
fragment NamePart on Person {
  firstName
  lastName
}





query GetPerson {
  people(id: String!) {
    ...NamePart
    avatar
  }
}

// 利用 fragment 从缓存中读取数据
let fg = client.readFragment({
  id: 'Person:cacheId',
  fragment: NamePart,
});




const data = usePersonQuery(...)

// 可在实时数据返回前，使用
// 缓存数据兜底，优化使用体验
let dp = data.NamePart || fg

浏览器侧接口的编排和聚合

GraphQL 的灵活性之一就是浏览器侧可以自主指定查询字段，在此基础上，借助内置指令和一些 GraphQL server 侧的默认实现，在浏览器中也可以实现一些简单的编排和聚合操作。比如下面这两个例子：

mutation AddExistedNodes(
  $DefaultNodePoolBody: CreateDefaultNodePoolRequest!
  $ExistedNodesBody: CreateNodesRequest!
  $HasDefaultNodePool: Boolean!
) {
  # mutation 里面 root action 是串行执行
  CreateDefaultNodePool(body: $DefaultNodePoolBody) 
  @skip(if: $HasDefaultNodePool) {
    Id
  }

  CreateNodes(body: $ExistedNodesBody) {
    Ids
  }
}




query DefaultNodePoolAndClusterInfoForCreateNode($ClusterId: String!) {
  # query 里面的 root action 是并发请求
  DefaultNodePools: ListNodePools(body: { Filter: { ClusterIds: [$ClusterId], Name: "vke-default-nodepool" } }) {
    Total
    Items {
      ...NodePoolItemForCreateNode
    }
  }

  Cluster: GetCluster(body: { Filter: { Ids: [$ClusterId] } }) {
    ClusterConfig {
      Vpc {
        Id
        Name
      }
      SecurityGroups {
        Id
        Name
      }
    }
  }
}

请求语句 hash，提高请求效率

在通常的 GraphQL 请求中，会在每一次请求中都携带整个 Document 语句，由于 Document 语句是固定的，我们可以将其进行 hash 处理，从而在实际发出请求时，只需要发出一个 hash 值即可，从而减少带宽消耗，提高请求效率。下面是浏览器中使用 hash 之后的入参，可以看到查询入参中，整个 GraphQL document 被替换为一个 hash 字符串：

BFF 层优化

减少手写冗余代码

schema 类型复用

GraphQL 本身不支持泛型、继承导致 schema 中有大量的重复结构，github issue 也有讨论，不这么做的原因大概是如果加上泛型和继承会导致自省特别麻烦

Thanks for proposing this! During the GraphQL redesign last year, we actually considered adding this!

There are two issues that seemed to result in more complication than would be worth the value we would get from this feature, but I’m curious what you think or if you have ideas:

What does the introspection result look like? When I read the ConnectionEdge type and look at its fields, what will the type of node be? The best answer we could come up with was to change Field.type from Type to Type | GenericParameter which is a bit of a bummer as it makes working with the introspection API more complicated. We could also expand Type to include the possibility of defining a generic param itself. Either way, it also has some rippling effects on the difficulty of implementing GraphQL, which would need to track type parameter context throughout most of it’s operations.

What should __typename respond with? What should { bars { __typename } } return? This one is pretty tricky. { "bars": { "__typename": "Connection" } }? That describes the type, but you’re missing info about the type parameter, that that ok? { "bars": { "__typename": "Connection<Bar>" } } Is also problematic as now to use the __typename field you need to be able to parse it. That also adds some overhead if you were hoping to use it as a lookup key in a list of all the types you know about.

Not to say these problems doom this proposal, but they’re pretty challenging.

Another thing we considered is how common type generics would actually be in most GraphQL schema. We struggled to come up with more than just Connections. It seemed like over-generalization to add all this additional complexity into GraphQL just to make writing Connections slightly nicer. I think if there were many other compelling examples that it could motivate revisiting.

目前我们是通过 graphql-s2s 预处理的方式做到继承、泛型，graphql-s2s 还提供了元数据装饰可以很方便的扩展 GraphQL

继承和多继承

Before graphql-s2s

type Teacher {
  id: ID!
  creationDate: String
  firstname: String!
  middlename: String
  lastname: String!
  age: Int!
  gender: String 
  streetAddress: String
  city: String
  state: String
  title: String!
}


type Student {
  id: ID!
  creationDate: String
  firstname: String!
  middlename: String
  lastname: String!
  age: Int!
  gender: String 
  streetAddress: String
  city: String
  state: String
  nickname: String!
}

After graphql-s2s

type Node {
  id: ID!
  creationDate: String
}











type Address {
  streetAddress: String
  city: String
  state: String
}





type Person inherits Node, Address {
  firstname: String!
  middlename: String
  lastname: String!
  age: Int!
  gender: String 
}


type Teacher inherits Person {
  title: String!
}


type Student inherits Person {
  nickname: String!
}

泛型

Before graphql-s2s

type Question {
  name: String!
  text: String!
}











type PagedQuestion {
  Items: [Question!]!
  TotalCount: Float!
  PageNumber: Float!
  PageSize: Float!
}





# Using the generic type
type Student {
  name: String
  questions: PagedQuestion
}

type PageStudent {
  Items: [Student!]!
  TotalCount: Float!
  PageNumber: Float!
  PageSize: Float!
}



# Using the generic type
type Teacher {
  name: String
  students: PageStudent
}

After graphql-s2s

 # Defining a generic type type Paged<T> {
  Items: [T!]!
  TotalCount: Float!
  PageNumber: Float!
  PageSize: Float!
}



type Question {
  name: String!
  text: String!
}





# Using the generic type type Student {
  name: String
  questions: Paged<Question>
}

# Using the generic type type Teacher {
  name: String
  students: Paged<Student>
}

在泛型上使用自定义名称

graphql-s2s 提供 alias 装饰器自定义名称

type Post {
  code: String
}

type Brand {
  id: ID!
  name: String
  posts: Page<Post>
}



@alias((T) => T + 's')
type Page<T> {
  data: [T]
}






# output:
# =======
type Post {
  code: String
}




type Brand {
  id: ID!
  name: String
  posts: Posts
}


type Posts {
  data: [Post]
}

减少 resolver 书写代码: 指令和中间件

当项目规模化地写起来之后，会发现很多 resolver 都是很相似的，一个一个全都写出来很麻烦还不好维护。那怎样使 resolver 代码保持 DRY(Don’t Repeat Yourself) 的原则呢？可以使用自定义指令或 graphql 中间件。

指令 (Directive)

GraphQL 有两个内置指令@include和@skip，它们做的事情也非常简单，就是在返回结果中条件性地去包含或者不包含某个字段。所以乍看上去指令好像只是 graphql 中很不起眼的一个小 feature，但其实，指令的想象空间是很大的，对一个大型 graphql 项目的意义和价值也是不应被忽视的。

我们知道，graphql 中每个字段的 resolution，归根结底都是靠一个 resolver 函数的调用，而指令 (Directive) 的目的，就在于能够在项目启动阶段自动批量生成(或修改)字段的 resolver 函数。所以通过自定义 directive 的方式，可以把许多通用的字段解析或转换的逻辑给封装掉，然后简单直接地运用到需要的字段处即可。

中间件 (graphql-middleware)

大白话讲，graphql-middleware 就是给 resolver 打辅助的预处理/后处理逻辑，是围绕着 resolver 的洋葱模型（下图）。适用于通用的 resolver 辅助逻辑，如：

数据转换：对请求或响应数据进行统一数据格式转换
权限校验：对 GraphQL 提供的服务进行统一权限校验
指标采集：采集 GraphQL 服务的一些指标或性能数据

它与自定义指令的不同之处在于，指令是 opt-in 的，你需要把它写到某个字段上才行；而 graphql-middleware 则是对所有字段的 resolution 都生效的，而且它也不能替代 resolver，只是预处理和后处理。

middleware 函数当然是支持异步的，因为如果在调 resolver 前后都有逻辑要跑，那当然得 await resolve(...).

import { applyMiddleware } from "graphql-middleware";

const resolver = {
    Query: {
    hello: (root, args, context, info) => {
      console.log(`3. resolver`)
    },
  },
}

// 只有预处理没有后处理
const middleware1 = (resolve, root, args, context, info) => {
    console.log('1. first middleware before resolver')
    return resolve(root, args, context, info);
}


// 既有预处理也有后处理
const middleware2 = async (resolve, root, args, context, info) => {
    console.log('2. second middleware before resolver')
    const res = await resolve(root, args, context, info)
    console.log('4. second middleware before resolver')
    return res;
}




const schema = makeExecutableSchema({typeDefs,resolvers,...})
const schemaWithMiddleware = applyMiddleware(schema,middleware1,middleware2)

middleware 函数接的参数在 resolver 的四个入参外还加了 resolver 本身。

PaaS 前端团队使用的自定义指令

fetch

BFF 层作为前端和后端的中继，resolver 最常见的逻辑就是向后端发请求。围绕这个场景我们设计了 fetch 指令.

fetch 指令是用于具体字段上的自定义指令，它支持传入 method，prefix，timeout 等多个参数，用以控制请求发送的多个方面，不过最常用的两个关键入参是：

svc：要访问哪个服务的接口，如 “vke”, “iam”.
path：访问的 url 及 query string 部分。

只要是对于 schema 中直接对接后端接口来获取值的字段（没有某些特殊逻辑处理的），都可以直接使用自定义的 fetch 指令，大大减少了开发过程中对接后端接口的成本。例：

type Query {
  deployments(body: WorkloadsBodyInput!): Deployments! @fetch(
    svc: "vke",
    path: "/?Action=ListDeployments&Version=2021-03-03",
  )
  deployment(body: WorkloadBodyInput!): Deployment! @fetch(
    svc: "vke",
    path: "/?Action=GetDeployment&Version=2021-03-03",
  )
}

另外，fetch 还支持接一个variables参数，虽然一般而言请求体会来自 web 端而不是写在 bff 里，但一种情况是例外，那就是本字段 fetch 时的请求体里需要本字段的父节点的返回值，所以我们支持了$result占位符，当这个占位符出现在 fetch 的 variables 参数中时，将会被自动解析为父节点返回值。例：

type UsersItem {
  Username: String!
  DisplayName: String!
  AccountId: String!
  Description: String!
  UserInfo: UserInfo @fetch(
    variables: {
      AccountId: "$result.AccountId"
      UserName: "$result.Username"
    },
    svc: "iam"
    method: "GET"
    path: "/?Action=GetUser&Version=2018-01-01"
  )
}

load

load 指令也是用于处理请求的，它适合 n+1 的场景。比如这个例子中：

// BFF 侧 schema SDL
type Query {
    listOfThingA: [ThingA!]! @fetch(svc: "whatever", path: "/?Action=ListThingA")
}






type ThingA {
    name: String!
    thingB: ThingB! @fetch(variables: { thingBId: "$result.thingBId" })
}


type ThingB @define(svc: "whatever", path: "/?Action=GetThingB"){
    name: String!
}



// web 侧 query AST
query {
    listOfThingA {
        name
        thingB {
            name
        }

    }

}

假设ListThingA会返回 100 个ThingA对象，这 100 个都会再去 resolve 它的thingB字段，所以会发出 100 个GetThingB的请求。这就是一个 n+1 的情况，n 在本例中是 100，1 是指 n 中的每一个又会触发 1 次额外请求。

为了把这 n 个额外请求合成一个（前提是批量查询的后端接口存在），我们引入了 DataLoader，并定义了 load 指令。针对每个需要解决 n+1 问题的场景，把相应的 batch 函数定义好，挂载到 bff 的上下文中，在 schema 中的具体字段上，就可以通过提供loader和key两个参数给 load 指令 (key 将作为 batch 函数的入参)，来使该字段使用相应的 batch 函数来进行合并请求。在 key 参数中也支持$result和$arg占位符的运行时解析。例：

type Node {   Id: String!   Name: String!   ClusterId: String!   NodePool: ListNodePoolsItem @load(
    loader: "nodePoolListLoader"
    key: "$result.NodePoolId"
  )   K8sNodeInfo: K8sNodeInfo @load(
    loader: "k8sNodeListLoader"
    key: { Id: "$result.Id", ClusterId: "$result.ClusterId" }
  )
}

运行时优化

减少查询复杂性: 嵌套层级限制和解决 N+1 嵌套请求

针对 N + 1 嵌套请求，我们将开源 dataloader 封装成 load 指令，借助中间件融入 GraphQL 技术栈。简单场景可直接使用指令，复杂场景可以在对应字段的 resolver 中调用 dataloader 的 API。在不破坏 GraphQL 按需执行的原则下，保证接口请求依然批量查询，同时保证接口性能和开发体验。

Apollo Server 监控和安全

由于 GraphQL 和 RESTful API 不同，GraphQL 可以通过查询语句一次性查询所有接口数据，这会导致服务器资源耗尽，我们需要限制 GraphQL 查询量限制，一般有两种方式，一种限制 GraphQL 查询深度，颗粒度比较粗，直接服务器端计算查询语句层级，大于指定层级就拒绝请求；一种是针对每个查询节点计算性能消耗估值，根据估值限制高估值的查询，这种就需要结合监控去估算每个查询节点的性能消耗

查询深度限制

假设我们有这样的 GraphQL 定义

type Song {
  title
  album: Album
}











type Album {
  songs: [Song]
}



type Query {
  album(id: Int!): Album
  song(id: Int!): Song
}

这样会导致我们服务器有可能执行循环查询

query evil {
  album(id: 42) {
    songs {
      album {
        songs {
          album {
            songs {
              album {
                songs {
                  album {
                    songs {
                      album {
                        songs {
                          album {
                            # and so on...
                          }
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

如果查询深度为 10，000，我们的服务器将如何处理它？这可能会成为一项非常昂贵的操作，在某些时候将耗尽服务器资源。这是一个可能的 DOS 漏洞。我们需要一种方法来验证传入查询的复杂性。

目前我们使用的是开源的 graphql-depth-limit

使用

import depthLimit from 'graphql-depth-limit'
import express from 'express'
import graphqlHTTP from 'express-graphql'
import schema from './schema'
 
const app = express()
 
app.use('/graphql', graphqlHTTP((req, res) => ({
  schema,
  validationRules: [ depthLimit(2) ]
})))

上面我们设置了 depthLimit(2), 那么下面超过 2 层深度的查询: deep3 在发起查询时则会被拒绝

# depth = 0
query deep0 {
  thing1
}











# depth = 1
query deep1 {
  viewer {
    name
  }

}



 
 
# depth = 2
query deep2 {
  viewer {
    albums {
      title
    }

  }
}


 
# depth = 3
query deep3 {
  viewer {
    albums {
      songs{
        {
          title
        }
      }
    }
  }
}

查询成本限制

大部分情况我们可以通过查询深度限制去，但是有些情况查询深度不深但是某些节点查询特别耗费资源，如果一个查询里面有特别多的这种节点也会导致服务器资源耗尽，这时候就需要结合查询成本限制。查询成本限制我们需要通过监控知道每个节点的查询性能以便估算成本

Apollo Server 性能监控

我们项目使用的 Apollo Server 框架，通过 Apollo Server 插件做性能埋点

export default function promGraphQLPlugin(config: PromGraphQLPluginConfig) {
  let typeInfo: TypeInfo | null = null;



  const {
    resolversHistogram,
  } = makeGraphQLMetric(config);



  const graphQLPlugin: ApolloServerPlugin<BaseContext> = {
    async serverWillStart() {
      return {
        schemaDidLoadOrUpdate(schemaContext: GraphQLSchemaContext) {
          typeInfo = new TypeInfo(schemaContext.apiSchema);
        },
      };
    },
    // eslint-disable-next-line max-lines-per-function
    async requestDidStart(requestDidStartContext: GraphQLRequestContext<BaseContext>) {
      requestDidStartContext.context[promPluginExecutionStartTimeSymbol] = process.hrtime.bigint();


      return {
        async executionDidStart(
          requestContext: GraphQLRequestContextExecutionDidStart<BaseContext>,
        ) {
          if (config.skipIntrospection && isIntrospectionOperationString(requestContext.source)) {
            return;
          }

          const internalContext = createInternalContext(
            requestContext.document,
            requestContext.request,
          );

          requestContext.context[promPluginContext] = internalContext;


          return {
            willResolveField(fieldResolverParams: GraphQLFieldResolverParams<any, BaseContext>) {
              const shouldTrace = shouldTraceFieldResolver(
                fieldResolverParams.info,
                config.resolversWhitelist,
              );

              if (!shouldTrace) {
                return undefined;
              }

              const resolveStartTime = process.hrtime.bigint();

              return (err: Error | null) => {
                const resolveTotalTime =
                  (process.hrtime.bigint() - resolveStartTime) / BigInt(1000000000);

                resolversHistogram?.histogram.observe(
                  resolversHistogram.fillLabelsFn(
                    { ...internalContext, info: fieldResolverParams.info },
                    requestContext.context,
                  ),
                  Number(resolveTotalTime),
                );
              };
            },
          };
        },
      };
    },
  };

  return graphQLPlugin;
}

主要根据 graphql_execute_resolver 这个指标做性能监控，通过这个指标数据可以统计每个 field 执行时间，根据查询时间做成本估值

graphql_execute_resolver_count{graphql_field_name="id",graphql_field_path="books.*.authors.*.id",graphql_field_type="String",graphql_operation_name="test",graphql_operation_type="query"} 4 1670328219594
graphql_execute_resolver_sum{graphql_field_name="id",graphql_field_path="books.*.authors.*.id",graphql_field_type="String",graphql_operation_name="test",graphql_operation_type="query"} 0.03 1670328219594
graphql_execute_resolver_bucket{graphql_field_name="id",graphql_field_path="books.*.authors.*.id",graphql_field_type="String",graphql_operation_name="test",graphql_operation_type="query",le="0.1"} 4 1670328219594
graphql_execute_resolver_bucket{graphql_field_name="id",graphql_field_path="books.*.authors.*.id",graphql_field_type="String",graphql_operation_name="test",graphql_operation_type="query",le="0.4"} 4 1670328219594
graphql_execute_resolver_bucket{graphql_field_name="id",graphql_field_path="books.*.authors.*.id",graphql_field_type="String",graphql_operation_name="test",graphql_operation_type="query",le="0.7"} 4 1670328219594
graphql_execute_resolver_bucket{graphql_field_name="id",graphql_field_path="books.*.authors.*.id",graphql_field_type="String",graphql_operation_name="test",graphql_operation_type="query",le="1"} 4 1670328219594
graphql_execute_resolver_bucket{graphql_field_name="id",graphql_field_path="books.*.authors.*.id",graphql_field_type="String",graphql_operation_name="test",graphql_operation_type="query",le="2"} 4 1670328219594
graphql_execute_resolver_bucket{graphql_field_name="id",graphql_field_path="books.*.authors.*.id",graphql_field_type="String",graphql_operation_name="test",graphql_operation_type="query",le="3"} 4 1670328219594
graphql_execute_resolver_bucket{graphql_field_name="id",graphql_field_path="books.*.authors.*.id",graphql_field_type="String",graphql_operation_name="test",graphql_operation_type="query",le="5"} 4 1670328219594
graphql_execute_resolver_bucket{graphql_field_name="id",graphql_field_path="books.*.authors.*.id",graphql_field_type="String",graphql_operation_name="test",graphql_operation_type="query",le="7"} 4 1670328219594
graphql_execute_resolver_bucket{graphql_field_name="id",graphql_field_path="books.*.authors.*.id",graphql_field_type="String",graphql_operation_name="test",graphql_operation_type="query",le="10"} 4 1670328219594
graphql_execute_resolver_bucket{graphql_field_name="id",graphql_field_path="books.*.authors.*.id",graphql_field_type="String",graphql_operation_name="test",graphql_operation_type="query",le="+Inf"} 4 1670328219594

然后根据上述的成本估值, 设置总体的查询成本限制

目前我们使用的是 graphql-cost-analysis 开源库

使用

app.use(
  '/graphql',
  graphqlExpress(req => {
    return {
      schema,
      rootValue: null,
      validationRules: [
        costAnalysis({
          variables: req.body.variables,
          maximumCost: 1000,
        }),
      ],
    }
  })
)

示例

# you can define a cost directive on a type
type TypeCost @cost(complexity: 3) {
  string: String
  int: Int
}





type Query {
  # will have the default cost value
  defaultCost: Int


  # will have a cost of 2 because this field does not depend on its parent fields
  customCost: Int @cost(useMultipliers: false, complexity: 2)


  # complexity should be between 1 and 10
  badComplexityArgument: Int @cost(complexity: 12)


  # the cost will depend on the `limit` parameter passed to the field
  # then the multiplier will be added to the `parent multipliers` array
  customCostWithResolver(limit: Int): Int
    @cost(multipliers: ["limit"], complexity: 4)

  # for recursive cost
  first(limit: Int): First
    @cost(multipliers: ["limit"], useMultipliers: true, complexity: 2)



  # you can override the cost setting defined directly on a type
  overrideTypeCost: TypeCost @cost(complexity: 2)
  getCostByType: TypeCost

  # You can specify several field parameters in the `multipliers` array
  # then the values of the corresponding parameters will be added together.
  # here, the cost will be `parent multipliers` * (`first` + `last`) * `complexity
  severalMultipliers(first: Int, last: Int): Int
    @cost(multipliers: ["first", "last"])
}

type First {
  # will have the default cost value
  myString: String

  # the cost will depend on the `limit` value passed to the field and the value of `complexity`
  # and the parent multipliers args: here the `limit` value of the `Query.first` field
  second(limit: Int): String @cost(multipliers: ["limit"], complexity: 2)

  # the cost will be the value of the complexity arg even if you pass a `multipliers` array
  # because `useMultipliers` is false
  costWithoutMultipliers(limit: Int): Int
    @cost(useMultipliers: false, multipliers: ["limit"])
}

总结:

本文先是介绍了 GraphQL 由来和规范, 再结合 react + nodejs 阐述了工程化落地事项, 可以让大家更方便安全的使用 GraphQL.

但是 GraphQL 并不是圣杯, 不是所有业务和团队都适用, 否则 GraphQL 不会经历了 10 年还不温不火, 以下场景我们建议谨慎考虑使用 GraphQL , 仅供参考

你的团队只有 REST API 开发经验, 那么 GraphQL 还是有很高的学习成本的, 在踩坑的时候需要更多的时间成本去解决
你的业务对 “接口聚合或者按需获取” 没那么强需求, 或者频次很低场景很少, REST API 就能满足绝大部分业务
你的服务需要做 OPEN API, 由于 GraphQL 目前仍不是主流, 那么就要考虑你的 OPEN API 消费者的对接成本和习惯

文章版权归作者所有，未经允许请勿转载，侵权请联系 admin@trc20.tw 删除。

THE END

# 前端 # GraphQL

GraphQL 前端工程化和性能优化

前言

正文

因何而起: GraphQL 简介和规范

GraphQL 是怎样开始的？

传统 REST API 的局限性

GraphQL 查询长什么样?

GraphQL 是怎么解决 REST API 遇到的问题的?

GraphQL 的主要组件

如何使用: React + Apollo Client + Apollo Server 的配合使用

如何写的更爽, 提示协作体验和效率： GraphQL 前端工程化

运行时类型校验，提升开发体验，减少前端页面崩溃

减少手写冗余代码

如何做性能的优化

浏览器减负

Apollo Client 缓存机制的合理利用

浏览器侧接口的编排和聚合

请求语句 hash，提高请求效率

BFF 层优化

减少手写冗余代码

schema 类型复用

继承和多继承

泛型

在泛型上使用自定义名称

减少 resolver 书写代码: 指令和中间件

指令 (Directive)

中间件 (graphql-middleware)

PaaS 前端团队使用的自定义指令

fetch

load

运行时优化

减少查询复杂性: 嵌套层级限制和解决 N+1 嵌套请求

Apollo Server 监控和安全

查询深度限制

查询成本限制

Apollo Server 性能监控

然后根据上述的成本估值, 设置总体的查询成本限制

总结:

GraphQL 前端工程化和性能优化

前言

正文

因何而起: GraphQL 简介和规范

GraphQL 是怎样开始的？

传统 REST API 的局限性

GraphQL 查询长什么样?

GraphQL 是怎么解决 REST API 遇到的问题的?

GraphQL 的主要组件

如何使用: React + Apollo Client + Apollo Server 的配合使用

如何写的更爽, 提示 协作 体验和效率 ： GraphQL 前端工程化

运行时类型校验，提升开发体验，减少前端页面崩溃

减少手写冗余代码

如何做性能的优化

浏览器减负

Apollo Client 缓存机制的合理利用

浏览器侧接口的编排和聚合

请求语句 hash，提高请求效率

BFF 层优化

减少手写冗余代码

schema 类型复用

继承和多继承

泛型

在泛型上使用自定义名称

减少 resolver 书写代码: 指令和中间件

指令 (Directive)

中间件 (graphql-middleware)

PaaS 前端团队使用的自定义指令

fetch

load

运行时优化

减少查询复杂性: 嵌套层级限制和解决 N+1 嵌套请求

Apollo Server 监控和安全

查询深度限制

查询成本限制

Apollo Server 性能监控

然后根据上述的成本估值, 设置总体的查询成本限制

总结:

如何写的更爽, 提示协作体验和效率： GraphQL 前端工程化