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

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