目标：框架打造，别具匠心。服务于业务的数据聚合平台。
引言： 蜂巢内容平台面临的挑战：互联网的发展，多端的数据展现和业务数据聚合，如何最佳的根据的查询条件给出不同的数据聚合和数据格式？ 所见即所得，是前端人员或者是接入内容平台的业务方最希望看到的结果。一切让调用者自己定义格式和请求条件。
GraphQL涉及哪些场景
一个GraphQL查询是一个字符串，它被发送给一个与数据模式无关的服务器，然后服务器返回JSON数据。GraphQL是强类型的，并避免了版本控制，同时提供了随着数据演进可以轻易改进查询语句的能力。
现有的业务场景一般是这样的，业务方提出需求，然后寻找开发资源，由后端提供数据，让前端实现各种不同的业务视图。这样的做法存在很多的重复劳动，如果能够将其中通用的内容抽取出来提供给各个业务方反复使用，必然能够节省宝贵的开发时间和开发人力。
前端的解决方案是将视图组件化，各个业务线既可以是组件的使用者，也可以是组件的生产者。那么问题来了，前端通过组件实现了跨业务的复用，后端接口如何相应地提高开发效率呢？
我们假设某个业务需要以下数据内容 a：
{
user(id: 3500401) {
id,
name,
isViewerFriend
}
}
对，这不是 JSON，但是我们仍然可以看懂它表示的是查询 id 为 3500401 用户的 id，name 和 isViewerFriend 信息。用户信息对于各个业务都是通用的，假设另外一个业务需要这样的用户信息 b：
{
user(id: 3500401) {
name,
profilePicture(size: 50) {
uri,
width,
height
}
}
}
对比一下，我们发现只是少了两个字段，多了一个字段而已。如果要实现我们的目标，即复用同一个接口来支持这两种业务的话，会有以下几种做法：
用同一个接口，这个接口提供了所有数据。这样做的好处是实现起来简单，但缺点是对业务做判断的逻辑会增多，而且对于业务来说，响应内容中有些数据根本用不到；
使用参数来区分不同的业务方并返回相应的数据。好处仍然是实现简单，虽然不会有用不到的数据返回，但是仍然需要增加业务逻辑判断，会造成以后维护的困难。
此外，这样还会造成不同业务之间的强依赖，每次发布都需要各个业务线一起测试和回归。不重用接口则没法提高开发效率，重用接口则会有这些问题，那么到底有没有“好一点”的解决方案呢？
这是我们在处理复杂的前后端分离中经常要面临的一个思考。
1. GraphQL，一种新的思路
我们知道，用户信息对应的数据模型是固定的，每次请求其实是对这些数据做了过滤和筛选。对应到数据库操作，就是数据的查询操作。如果客户端也能够像“查询”一样发送请求，那不就可以从后端接口这个大的“大数据库”去过滤筛选业务需要的数据了吗？
GraphQL 就是基于这样的思想来设计的。上面提到的（a）和（b）类型的数据结构就是 GraphQL 的查询内容。使用上面的查询，GraphQL 服务器会分别返回如下响应内容。
a 查询对应的响应：
{
"user" : {
"id": 3500401,
"name": "peter",
"isViewerFriend": true
}
}
b 查询对应的响应：
{
"user" : {
"name": "peter",
"profilePicture": {
"uri": "http: //someurl.cdn/pic.jpg",
"width": 50,
"height": 50
}
}
}
只需要改变查询内容，前端就能定制服务器返回的响应内容，这就是 GraphQL 的客户端指定查询（Client Specified Queries）。假如我们能够将基础数据平台做成一个 GraphQL 服务器，不就能为这个平台上的所有业务提供统一可复用的数据接口了吗？ 如果定位为：数据服务标准化管理，数据网关也是不错的架构。
借助于Antlr语法解析：
参考： http://www.antlr.org/
2, 查询条件自由组合 QSQL
1) 如何让各种条件组合+逻辑判断一起使用，很自然想到的是SQL函数。
2) GraphQL同样支持条件传递和变量替换，让查询串和请求格式串分离。
3) 最终围绕多维度数据聚合进行思考
3，如何解决1+N问题？
我们先看看graphQL的执行流程 。
回到语法树的遍历: 深度遍历或者广度遍历（解决LIST数据批量获取的特性）
深度遍历
广度遍历
我们采取广度遍历算法，构建相同的节点采取批量直接构建List List这样的形式请求领域服务，完成批量问题调用。
参考：
规范：https://github.com/chentsulin/awesome-graphql
InfoQ: http://www.infoq.com/cn/news/2015/10/graphql-your-schema?_t=t
总结：
后续还有很多优化和配套工具需要继续完善，其中包括内容平台的领域模型标准化建设，一键建站服务，垃圾防控，性能优化和限流降级和接口监控等。
