共计 1808 个字符，预计需要花费 5 分钟才能阅读完成。
欢送浏览 ????
本文会通过理论场景介绍一下 GraphQL，目标是让你疾速理解 GraphQL 是什么，以及根本工作思路，不蕴含理论用法，所以浏览很轻松。
一、GraphQL 是什么？
GraphQL 是后端数据查询语言，能够简略了解为 GraphQL 对标的是 REST 接口。
GraphQL 由 Facebook 开源，目前曾经在 Facebook 中撑持千亿级的 API 接口调用，在 Facebook 之外正在被迅速利用。
咱们不要被 GraphQL 这个名字误导了，第一次看见它时，我还认为这是一个图数据库的查询语言呢。
GraphQL 大体上确实是 “ 图查问 ” 的意思，但这个 “ 图 ” 是 数据图谱 的意思，不是图数据库。
二、GraphQL 思路
以上图为例，这是支流的 Feed 流模式，如何实现呢？
定下来界面中须要显示哪些数据元素之后，后端开始为其定制一个 REST 接口，查问出相干数据：
- Post 帖子
- 作者
- Like 喜爱
- Comment 评论
- Share 分享
后端程序员进行数据关联查问，取出其中须要的数据项，而后封装为一个易于前端操作的数据结构，例如 JSON 对象。
这样 Feed 流的接口就 OK 了，同样的，对于其余界面再进行相应的接口开发。
例如在帖子详情页面，波及的数据还是 Feed 流中的这些，但具体的数据项不同了，例如：
- 帖子须要全文
- Like 须要点赞用户的图像列表、ID
- Comment 评论须要详情列表
因为数据项的不同，就须要针对这个界面需要从新开发吧。
如果你嫌麻烦，提供了一个大而全的接口，后端开发是简略了，但新问题来了，例如：
- 前端开发须要从后果数据中认真挑出本人所须要的数据项。
- 接口返回数据中蕴含大量的前端无用数据，会占用更多的带宽，影响性能，例如 Facebook 那种千亿级的 API 调用量，这种带宽的节约是不能容忍的。
有什么更好的方法呢？（如果你有更好的教训，欢送发给我，我会分享给大家）
Facebook 为了解决这个问题，设计出了 GraphQL。
GraphQL 解决思路
对于上述场景，实质上是后端在应酬前端的每个需要，是以前端需要为核心。
前端说我要这些数据，后端就去筹备这些数据，来一个需要就解决一个需要。
Facebook 的想法是：
数据就是那样的，每个数据对象蕴含哪些项，依据各个数据对象的关系就能够造成数据的图谱了。
后端负责结构这个数据图谱，前端依据数据图谱来查问本人所须要的数据。
这样前端与后端都是以数据图谱为核心了，后端就不必服侍前端各种不同类型的需要了，前端也能够自在的精准查问数据了。
感觉比拟形象是吧，看上面的示例代码：
# ----------- 定义数据类型 -----------
type Post {
id: String!
title: String!
description: String
comments: [Comment]
likes:[Like]
}
type Comment{id:String}
type Like{id:String}
# ----------- 定义查问接口 -----------
type Query {recentPosts(count: Int, offset: Int): [Post]!
}
type Mutation {writePost(title: String!, category: String) : Post!
}（下面代码可横向滑动）
其中分为 2 个局部：
- 下面局部定义了数据类型，例如 Post，指明蕴含哪些数据项，其中的
comments、likes关联了其余的数据类型，这样就描绘出了数据对象之间的关系。 - 上面局部定义了查问接口，供前端调用。
而后咱们看前端怎么用。
上图中，右边是前端的调用形式，左边是返回的数据后果。
前端调用了 recentPosts 接口，并指明了只须要返回 id，所以，返回后果中只有 id 数据项。
上图中，前端调用了 recentPosts 接口，这次指明了须要：
- Post 的 id 项
- likes 的 id 项
- comments 的 id 项
在左边的返回后果中能够看到，应前端的需要返回了相应数据。
三、小结
在以数据图谱为核心之后，后端省心了，前端自在了。所以 GraphQL 的外围就是构建好这个数据图谱。
以上就是 GraphQL 根本内容了，如果对它有趣味，能够留言通知我，之后我会整顿一个 GraphQL 的应用教程。
写在最初
欢送大家关注我的公众号【惊涛骇浪如码】，海量 Java 相干文章，学习材料都会在外面更新，整顿的材料也会放在外面。
感觉写的还不错的就点个赞，加个关注呗！点关注，不迷路，继续更新！！！