GraphQL 数据查询语言 or GraphQL A query language for your API

[lanlin]

诞生背景

Facebook 构建移动应用的时候，发现 RESTful 和他自家的 FQL 都不能够很好的解决 API 的一个关键性问题：

如何用同一套 API 满足所有的扩展需要？不管是 WEB 的，还是移动的，还是其他的？

于是，GraphQL 诞生了。 赞美那些脑洞大开的攻城狮们！让我们这些渣渣程序猿又 OUT 了一个档次。 GraphQL 概念的完善应该从 2012 开始。然后，到了 2015，社区正式成立。

核心概念

如图，有点像 JSON。 不过关键的地方就在于，你说你要什么，你画好格子，我就按照格子给你什么。

这就有点意思了！ 因为，你可以设想，直接通过一次请求，就把你这个页面需要的所有数据都拿下来！

**1. 请求减少了

2. 数据结构更清晰了
3. 重复查询减少了
4. 高度自定义 + 高度可重用**

真正做到了一套万能（万精油）类型的 API !!

概念简化

“我（Client）给你一张表，你（Server）填好了还给我!”

发展前景

目前几大主流语言都逐渐有人放出 GraphQL 的开源库，以后必将会越来越火。 不用说，这必将又是一个新的 API 标准！

[lanlin]

各家看点： GraphQL 为何没有火起来?

至今仍有一些问题困扰着我

1. 没有很好的数据库抽象层，如何优化性能，例如处理冗余查询等问题

2. RESTful 下不同 API 天然的就隔离了不同业务逻辑，所以能够比较简单的实现针对特定业务的鉴权和拦截。 但是 GraphQL 下面查询条件不受控，一次查询可能就涵盖了 N 多个 API 所涉及的业务范围。 这个时候，权限怎么设计呢？

3. 团队水平和协作问题，如果写前端的人压根没玩过数据库，也不了解后端。 那么能指望前端能够实现 A 到 B 的转变呢？

   A. 多个API，各干个事，查询逻辑透明，每个 API 的构成是一个 url + 几个固定参数。 B. 只有一个API，做完所有事情，能取什么自己看数据库和 GrapghQL Type，其他事情自己想办法...

4. 后端的同学写着写着又不自觉的代入到 RESTful 的线性思维里面，导致写出来的东西不通用。 太多的 type 和 resolver 了，已经搞不清谁是谁了。咦，好像这里写重复了

5. 综合以上，我们是不是要找全栈攻城狮？是不是要重新设计业务分层？是不是做到中途发现最好的办法是把项目重新来过？

呃。。额米豆腐，老衲还是继续观望下先。。。