GraphQL and Relay 浅析
|
Facebook 在去年夏天公布了 GraphQL，就像往前端深潭砸下了一颗巨石，人们都被水声吸引到了湖边，观望是否会出现什么，有些人期待，有些人猜疑。过了半年多，社区已经慢慢的摸清这个石头的材质，本文希望在你入门 GraphQL 和 Relay 的过程中能帮你清除一些障碍。 GraphQLGraphQL 是在 Facebook 内部应用多年的一套数据查询语言和 runtime。 GraphQL 包括什么
GraphQL 优势官网已经列举了，我用更简练的语言描述下。 GraphQL 与 REST同类型协议目前最出名的是 REST，特点是资源可定位，使用 HTTP verbs。REST 具体应该怎么写有很多争议，但简单的例子是没有争议的： GET /users/1 REST 优点是简单明了，缺点也是太简单明了，导致语法可扩充性不强。 语法灵活 GraphQL 只需要一次请求就能够获得你所有想要的资源。这里举一个和 REST 对比的例子 让大家有直观的认识。 现在，我想获取id为1的用户的名字，年龄和他所有朋友的名字 GraphQL 实现的方案： {
user(id: 1) {
name
age
friends {
name
}
}
}
REST 实现的方案： GET /users/1 and GET /users/1/friends 或 GET /users/1?include=friends.name 发现区别了吗？用 REST 要不就发多次请求，要不就得用一个不方便扩展的语法。 没有冗余 日后扩充资源也没有冗余，你只会获得你想要的资源。还是用上面的例子，如果 user 多了个属性 gender 会怎么样？ 强类型 有 introspection 机制，代码即文档，方便快捷，而不需要去找这个 API 的说明文档在哪里，看个例子： 自定义 schema 没必要像 REST 这样固定且通用的语法。 其他专有方案（Ad Hoc Endpoints）和专有方案对比：
与图数据库的关系首先，介绍下什么是图数据库，可以参考neo4j的介绍，一图胜千言：
GraphQL 为什么有 Graph，是因为它的 query 是以图的形式来组织的： user
┖-OWNS-> playlist
┖-CONTAINS-> track
┖-LIKED_BY-> users
GraphQL 并不要求后台一定要是图数据库，关系数据库也可以，它只是一套查询数据的语言而已。 DataLoaderDataloader 是一个小工具，帮你把你的请求转成批量请求的形式，和 GraphQL 搭配的也挺好，看个例子: query FetchPlaylist {
playlist(id: "e66637db-13f9-4056-abef-f731f8b1a3c7") {
id
name
tracks {
id
title
viewerHasLiked
}
}
}
这个 query 是要获取某个用户的歌单。 import {
GraphQLString,GraphQLBoolean,GraphQLObjectType
} from 'graphql';
export default new GraphQLObjectType({
name: 'Track',description: 'A Track',fields: () => ({
id: {
type: GraphQLString,resolve: it => it.uuid
}
title: { type: GraphQLString },viewerHasLiked: {
type: GraphQLBoolean,resolve: (it,_,{ rootValue: { ctx: { auth } } }) => (
(auth.isAuthenticated) ? it.userHasLiked(auth.user) : null
)
}
})
});
resolve 函数调用的是后端 API，注意这里的 it 就是 track 的对象。 import DataLoader from 'dataloader';
import BaseModel from './BaseModel';
const likeLoader = new DataLoader((requests) => {
// requests is now a an array of [track,user] pairs.
// Batch-load the results for those requests,reorder them to match
// the order of requests and return.
})
export default class Track extends BaseModel {
userHasLiked(user) {
return likeLoader.load([this,user]);
}
}
在一个 event loop 里每次调用 dataloader，dataloader 会记下你的请求参数，在下次 event loop 的时候把这么多次的请求参数变成一个数组提供你操作，你就可以拿这个数组对数据库执行批量的操作了。而且，它还对结果按你的请求参数进行了缓存，是居家必备的杀人利器。 安全性或许有人有疑问，感觉 GraphQL 把我所拥有的资源全部都暴露了，别人不只一览全局，而且还能一次过全部拉下来，那还得了？ 可以看到你可以在里面插入权限限制的。至于获取资源太多拖垮服务器？ Jacob Gillespie 提到一些思路：
RelayRelay 是连接 GraphQL 和 React 的一座桥梁。不过，除了让 React 认识 GraphQL 服务器之外，它还做了什么呢？ 建议先把官网的资料都读一遍，Relay 相对来说比 GraphQL 复杂一些，而且文档并不详细（截至截稿时，Relay的版本是 v0.6.1），也缺失了关于 graphql-relay 库的详细介绍，扫一遍后，结合本文最后的学习资料的代码加深理解。 Relay 怎么用？使用 Relay 是要侵入前后端的：
Relay 包括什么？Relay 把关于数据获取的事情都接管过来，比如说请求异常，loading，请求排队，cache，获取分页数据。我这里重点讲一下以下几个方面： client-side cacheRelay 获取数据当然离不开 cache，可以看到 GraphQL 不再依赖 URL cache，而是按照 Graph 来 cache，最大的保证 cache 没有冗余，发最少的请求，我举一个例子： 比如下面这个请求： query { stories { id,text } }
如果利用 URL 请求（比如说浏览器的 cache），那么这个请求下次确实命中 cache 了，那么假如我还有一个请求是： query { story(id: "123") { id,text } }
看得出，下面这个请求获取的数据是上面请求的子集，这里有两个问题：
这两个想法催生出来了 GraphQL 的解决方案：按照 Graph 来 cache，也就是说子集不需要再发请求了，当然你也可以强制发请求来更新局部或者整个 cache。 具体做法是通过拍平数据结构（类似数据库的几个范式）来 cache 整个 Graph。 view 通过订阅他需要的每个 cache record 来更新，只要其中一个 record 更新了，也只有订阅了这个 record 的 view 才会得到更新。 最后，聊到修改，我们可以看到 mutation 有个反直觉的地方是请求的 query 里包括了需要获取的数据。为什么不直接返回你的修改影响的那些数据？ 因为服务端实现这个太复杂了，有的时候一个简单的修改会影响到非常多的后台数据，而很多数据 view 是不需要知道它变化了。 所以，Relay 团队最后选择的方案是，让客户端告诉服务器端你认为哪些数据你想重新获取。具体到实现，Relay 采用的方案是获取 cache 和 fat query 有交集的部分，这样既更新了 cache，而且不在 cache 里的也不会获取。 Relay 的声明式数据获取React 是按 Component 组织 view 的，最好的方式也是把 view 需要的数据写在 view。如果用常规的做法，view 负责自己的 Data-fetch，那么，由于 React 是一层一层的往里深入 Component 的，那么也就意味着每一层 Component 都自己发请求去了，是不可能做到用一个网络请求来获取所有数据的。 所以，Relay 通过抽象出一个 container 的概念，让每个模块提前声明自己需要的数据，Relay 会先遍历所有 container，组成 query tree，这样就达到了只使用一个网络请求的目的。 另外，通过声明式数据获取还可以更好的对组件约束，只能获取它声明的数据，并且 Relay 也可以做些验证。 graphql-relay-js在看一些 React 和 Relay 协作的例子时，经常发现这个库的存在，这个库到底是干什么的？ 通过查看源码后发现，里面其实是各种 helper 方法，负责生成一些 GraphQL 的类，为什么需要这样做？其实，这是因为 Relay 提供的一些功能（比如 ID handling，分页）需要 GraphQL 服务器提供特定的代码结构。如果你要开发一个 GraphQL 的前端，就算它基于其他框架，基于其他语言，实现一个像 graphql-relay-js 所实现的 Relay-compliant 的 server 是很有帮助的，比如graphql-go/relay。 babel-relay-pluginRelay 的 container 依赖的数据资源是通过声明的，但客户端是不知道后端的数据结构的。为了让客户端了解整个后台结构，就要引入这个 bable 插件，这个插件通过读取服务端的 schema，就可以让客户端正确理解它所需要的资源在服务端是长什么样的。 optimistic UI update我们看下例子： <Relay.RootContainer
Component={ProfilePicture}
route={profileRoute}
renderLoading={function() {
return <div>Loading...</div>;
}}
renderFailure={function(error,retry) {
return (
<div>
<p>{error.message}</p>
<p><button onClick={retry}>Retry?</button></p>
</div>
);
}}
/>
可以看到在 Relay 里可以很简单的处理请求整个请求过程中的 UI 变化。 总结相信阅读本文的读者都是对这两者有一定兴趣的人，但在我上手之后，我的心情是复杂的。GraphQL 和 Relay 带来了一些优势，最重要的是可以一次性获取资源，看上去是未来之路，但这优势其实用些不优雅的方法来解决也没什么问题，但为了这些优势需要编写大量与业务逻辑无关的代码，让我真心忧虑它的路能走多远，相信看过一个官方的 TODOList的例子 的入门者很容易就能感觉到。REST 如此简单，普及开来尚且用了几年，复杂好多倍的 GraphQL 的未来还任重而道远。 学习资料
相关的库
（编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |