这里记录着小洋童鞋在前端道路上的所思所想所感。
生命在于折腾，不在折腾中崩溃，就在折腾中涅槃。
首先给大家简单的介绍一下 graphql 特性，graphql 其实是一种和后端交换数据的协议，像通过 sql 语言可以操作数据库一样，graphql 通过 schema 的方式来控制数据，并约定提供以下能力：
可以说很多数据交换的情景都可以使用 graphql 的概念，我们就先基于 express 来快速打造一个 http 服务器 ( graphql 官方并没有说只限于 http) 用最简单的方式体验一下 graphql，我们的项目起始于 package.json：
$npm install 以后我们就可以愉快的玩耍了，首先搭好程序入口，本地服务以及处理 graphql 请求的 handler：
上述代码创建了入口 index.js 、本地服务 server.js 以及 schema 实例 schema.js ，至此我们的 graphql 服务的骨架就出来了，下面我们只要来把 schema.js 填充完整就可以体验 graphql 啦~
我们可以按照上述<code>描述数据</code>，<code>筛选数据</code>然后<code>获取数据</code>的顺序生成测试代码感受一下 graphql 的魅力吧~
首先我们先创建一个模拟数据源 todo list:
todo list 是一个元素为 todo object 的数组，由于我们要给客户端提供筛选及自省的能力，所以我们要通过 graphql 的 type 来描述所有组织结构，首先我们来描述元素 todo object
那么 todo list 显而易见就是 <code>new graphqllist(todotype)</code> 啦，即元素为 todotype 的数组。
有了数据源我们就可以愉快的通过 graphql schema 来取数据啦，我们的第一个 schema 就先为获取整个 todo list 吧，先在服务器上注册一个处理 graphql 请求的方法：
之前已经创建了一个端口为3000，路由为 /graphql 的 graphql api，至此终于可以 $node index.js 开始我们的 graphql 之旅啦~
比如我们可以通过下面的 query 来获取 todos 下的 title ，由于 todos 是数组所以结果对应也是数组：
注：通过控制台，postman等均可构造 post 请求验证结果，本文所有请求都通过 curl 来构造（包括添加 contenttype 请求头及 data）。
在介绍自省之前，我们可以先了解一下域，每个 graphql 根域都有 __schema 域，这个域有一个子域叫 querytype。我们可以通过查询这些域来了解 graphql 服务器支持那些查询，按照 object 的方式理解其实就是通过对象的属性可以了解其结构及内容
看到上面的结果大家应该都有感觉了，其实 graphql 请求的成功与否与接口的 schema 设计结构息息相关，所有的数据结构查询都是按协商好的规则进行的，还记得我们声明的 graphqlschema 是怎么写的吗？
发现结果是一一对应的了吧，哈哈~ 可以记住这个“万能查询”，同时 graphql 也提供了__type, __typekind, __field, __inputvalue等等的关键字来检测接口所支持查询的属性，比如我们现在已经知道了“/garphql”这个 api 会返回一个对象数组，那我想知道他包含的对象是什么结构咋变咧？
没错我们可以通过限定 __type 去查已经注册的 "todo" 对象来自省接口，还有很多关键字方法都可以达到上述的效果本文就不一一列举了。细心的同学发现上面 __type(name: todo) 的用法了吧，同样也可以用到我们的代码中来查询具体某一条的 todo 对象:
有查询数据当然也有修改数据，mutation 查询和普通查询请求（query）的重要区别在于 mutation 操作是按照顺序执行的，即多次修改数据后再查询，其返回一定是最后一次修改后的结果：
正如官方所说 graphql 是一个查询语言，而且目前还未完成，未来也可能会有更多更大的变动，但已经拓宽了我们的思路，让我们看到了更多的可能性。目前 graphql 利好主要是在于前端的开发效率，落地时需要服务端的全力配合，也存在着一定的安全风险（暴力破解接口能力等），最大的性能瓶颈可能来自于数据库查询，但究竟好不好用，关键是看你怎么用了，对吧？ 我们仍在前行，阳光总在风雨后。