@TommyLemon
从 graphql-js 摘取片段代码
github.com/graphql/graphql-js/blob/master/src/__tests__/starWarsSchema.js

```js
const humanType = new GraphQLObjectType({
name: 'Human',
description: 'A humanoid creature in the Star Wars universe.',
fields: () => ({
id: {
type: GraphQLNonNull(GraphQLString),
description: 'The id of the human.',
},
name: {
type: GraphQLString,
description: 'The name of the human.',
},
friends: {
type: GraphQLList(characterInterface),
description:
'The friends of the human, or an empty list if they have none.',
resolve: human => getFriends(human),
},
appearsIn: {
type: GraphQLList(episodeEnum),
description: 'Which movies they appear in.',
},
homePlanet: {
type: GraphQLString,
description: 'The home planet of the human, or null if unknown.',
},
secretBackstory: {
type: GraphQLString,
description: 'Where are they from and how they came to be who they are.',
resolve() {
throw new Error('secretBackstory is secret.');
},
},
}),
interfaces: [characterInterface],
});


const queryType = new GraphQLObjectType({
name: 'Query',
fields: () => ({
hero: {
type: characterInterface,
args: {
episode: {
description:
'If omitted, returns the hero of the whole saga. ' +
'If provided, returns the hero of that particular episode.',
type: episodeEnum,
},
},
resolve: (root, { episode }) => getHero(episode),
},
human: {
type: humanType,
args: {
id: {
description: 'id of the human',
type: GraphQLNonNull(GraphQLString),
},
},
resolve: (root, { id }) => getHuman(id),
},
droid: {
type: droidType,
args: {
id: {
description: 'id of the droid',
type: GraphQLNonNull(GraphQLString),
},
},
resolve: (root, { id }) => getDroid(id),
},
}),
});
```

从 dataloader 摘取片段代码
github.com/facebook/dataloader/blob/master/examples/SQL.md

```js
var DataLoader = require('dataloader');
var sqlite3 = require('sqlite3');

var db = new sqlite3.Database('./to/your/db.sql');

// Dispatch a WHERE-IN query, ensuring response has rows in correct order.
var userLoader = new DataLoader(ids => {
var params = ids.map(id => '?' ).join();
var query = `SELECT * FROM users WHERE id IN (${params})`;
return queryLoader.load([query, ids]).then(
rows => ids.map(
id => rows.find(row => row.id === id) || new Error(`Row not found: ${id}`)
)
);
});

// Parallelize all queries, but do not cache.
var queryLoader = new DataLoader(queries => new Promise(resolve => {
var waitingOn = queries.length;
var results = [];
db.parallelize(() => {
queries.forEach((query, index) => {
db.all.apply(db, query.concat((error, result) => {
results[index] = error || result;
if (--waitingOn === 0) {
resolve(results);
}
}));
});
});
}), { cache: false });

// Usage

var promise1 = userLoader.load('1234');
var promise2 = userLoader.load('5678');

Promise.all([ promise1, promise2 ]).then(([ user1, user2]) => {
console.log(user1, user2);
});
```

要写大量逻辑重复又不好抽象的代码，就是问题啊

@buhi 问题是所有需要优化的 Type 都要各自写一个 DataLoader， @eloah 这个兄弟应该深有体会

@eloah 哈哈，可以看下 APIJSON，提供自动化的权限控制，自动化 join，#9 楼 #21 楼有详细对比

@vipppppp 唉，之前有个开发者在 issue 里留言说在做 Python 版：
“刚刚把单元测试写好。json 的表现层完全自定义，都是为了对应 sql ”
到现在有 2 个月了也没更新
github。com/TommyLemon/APIJSON/issues/38

@reus 还请您把方案拿出来和“我这破东西”对比下，让大家也长长见识，顺便给与支持

@kran 3 行代码即可实现 各种角色 对一张表的 增删改查 默认权限配置，支持通过注解来自定义。
my.oschina.net/tommylemon/blog/889074

@TommyLemon 是 APIJSONAuto 比它们好用很多，它们只在支持代码自动补全有优势，
而 APIJSONAuto 的 自动注释请求、自动生成代码、自动化回归测试（前后对比测试+机器学习测试）是它们都没有的。
http://apijson。org/

@buhi
不是保证，是基于事实的对比。
APIJSON 与 GraphQL 全方位对比解析(一)-基础功能
juejin。im/post/5ae80edd51882567277433cf

APIJSON 与 GraphQL 全方位对比解析(二)-权限控制
juejin。im/post/5b17518c6fb9a01e75463096

APIJSON 与 GraphQL 全方位对比解析(三)-表关联查询
juejin。im/entry/5b4ff88f6fb9a04f914a8df5

如果你单纯用影响力来对比，那 OKHTTP，Mybatis，RxJava，Vue.js 等
早期由个人开发者做起来的项目都不能和 FLAG 等大公司同类项目比了，更不可能超过了。

GraphQL 硬生生地把加强版 API Proxy 做成了一门编程语言(#import,$variable...)，
基础的问题(定制结构、分组排序、JOIN 等)没都解决好，还越做越复杂，概念满天飞。
那套新的协议还真只有 Facebook 那种水平的大牛才能准确高效地解析出来，
不过毕竟是新协议，怎么都不会比发展了快 20 年的 JSON 更成熟方便。

APIJSON 基于 JSON 扩展而来，不但提供了几乎所有 SQL 常用功能+远程函数等其它功能，
还可以很好地利用 JSON 的生态，可以用一大堆成熟的封装与解析库，一大堆视频博客等教程，
一大堆方便好用的调试工具(Chrome 控制台、Postman 等对 JSON 内置支持)...

而且现在 APIJSON 主项目(Java)也有 4 个开发者在维护，支持 MySQL, PostgreSQL, Oracle。

还有其它 3 个作者分别实现了 APIJSON 的 C#, PHP, Node.js 版。

加上 APIJSONAuto 自动化接口管理工具（ GraphiQL,Graphcool 的 PlayGround,Apollo Client Devtools,GraphQLIDE 好用很多，你可以都对比下）已经有一个初具雏形的 APIJSON 生态了。

@clino
目前只有 Java，C#, PHP, Node.js 的后端实现 以及 Android，iOS，JavaScript 的 Demo。
但 APIJSON 的协议是与语言无关的，可以用 Python 等其它语言实现，可以参考这个引导
github.com/TommyLemon/APIJSON/issues/38

@RubyJack GraphQL 是用来自动整合其它接口或服务的，性能取决于 整合方式 以及 原来的接口或服务的性能。
如果就是简单地把几个接口拼在一起返回数据，很容易引发 N+1 次查询 /调用，性能就差了，
所以 Facebook 又搞了个 [DataLoader]( https://github.com/facebook/dataloader)，
从主查询（主表）里取出 副查询（副表）需要的所有 id，
将原来 N 次 WHERE id=$id 副查询 变为一次 WHERE id IN( $idList ) 来优化性能，
但使用 DataLoader 要写 userLoader 等一些实例
```js
var DataLoader = require('dataloader')

var userLoader = new DataLoader(keys => myBatchGetUsers(keys));
```

并且实现初始化
```js
function createLoaders(authToken) {
return {
users: new DataLoader(ids => genUsers(authToken, ids)),
}
}
```

和调用方法
```
// Request begins...
var userLoader = new DataLoader(...)

// And a value happens to be loaded (and cached).
userLoader.load(4).then(...)

// A mutation occurs, invalidating what might be in cache.
sqlRun('UPDATE users WHERE id=4 SET username="zuck"').then(
() => userLoader.clear(4)
)

// Later the value load is loaded again so the mutated data appears.
userLoader.load(4).then(...)

// Request completes.
```

在原来写一堆 Schema，Type，Resolver 的基础上又增加了不少工作量。

APIJSON 直接提供自动化的 join，不需要后端写任何代码，前端传一个 join 键值对就行：
```js
{
"[]": { //查询数组
"join": "</User/id@", // Comment LEFT JOIN User ON User.id = Comment.userId
"Comment": {},
"User": {
"id@": "/Comment/userId",
"@column": "id,name" // SELECT id,name
}
}
}
```
可以用 APIJSONAuto-自动化接口管理平台 在线测试
http://apijson.org

@Hilong @asd123456cxz 感谢。
其实我有时也在一些技术群推广 GraphQL，在公司也为 GraphQL 开过分享会。
不怕对比，就怕大家不知道、不认可 前端定制接口 的做法。
一部分用户是因为先了解到 GraphQL，然后看不懂、不会用、用起来麻烦，
后面看到 APIJSON 就转了过来。

jenkins，公司 Android，Java 都在用来做自动化构建

@find456789 逻辑不难，但判断要写很多，这里有教程
juejin.im/post/5b13cda1f265da6e4a6bcfee

@heww @reus @TommyLemon
APIJSON 比 GraphQL 强大易用很多，解决了以上所有问题，
并且不用写 Schema，Type，resolver 等一堆东西，
它会自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入。
还有自动化的各种 JOIN(INNER, LEFT, RIGHT 等)解决 N+1 问题。
还支持多字段排序 order by，多字段分组 group by，聚合函数 having
等几乎所有 MySQL 的常规功能。
juejin.im/post/5ae80edd51882567277433cf

创作不易，GitHub 右上角点 Star 支持下吧，谢谢 ^_^
github.com/TommyLemon/APIJSON

说明很多公司都前后端分离后碰到了各种恼人的开发与沟通问题

1.浪费性能、流量和带宽
返回不需要的字段、对象等

2.各种奇葩的缩写、混乱的命名
各种缩写、拼音、驼峰和非驼峰混用等，
只有看文档才知道是什么、才知道用哪个，而且文档还很可能有错误。
例如
评论数量可能是 commentCount, comment_count, cmt_count, pl_num...
分页页码可能是 page, pageNum, page_number, page_num, pnum...

3.数据类型不稳定或随意改变
对象为空时应该返回 null 或 {} ，但实际会返回空数组 []，
甚至是 "", "[]" 等 ，导致前端解析崩溃；
后端擅自改变类型导致线上 App 崩溃...

4.几百甚至上千个混乱的状态码
各项目几乎完全不通用，不看相关的内部文档根本不知道对应的错误是什么，而且文档还很可能有错误。
例如
注册: 成功 600, 手机号不合法 601, 验证码错误 603, 手机号已注册 607, 缺少必要字段 609...
评论: 成功 1070, 不允许评论 1071, 参数错误 1073, 动态被删除 1075...

5.文档过时，与接口不同步
后端把接口改了没有及时通知，前端 /客户端莫名其妙调了半天才发现

6.应用界面和接口强耦合难分离
比如某个版本的 QQ 空间动态的 JSON 结构必须对应某个版本的某个接口，
有时候 JSON 结构甚至是由后端拍脑袋决定的，不好用也得用

7.版本迭代导致大量重复功能的接口
为了兼容旧版应用不好直接改原来的接口，一般只能新增

8.前端 /客户端与后端扯皮
前端 /客户端想要一次性返回或者更方便解析的结构，但后端想要少写代码

9.数据库操作不安全
delete 忘加 where 直接删光全部数据，只要发生一次

10.开发流程繁琐周期长
后端写接口>后端写文档>前端 /客户端查文档>(前端 /客户端关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端 /客户端调用接口>(前端 /客户端关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端 /客户端解析返回结果>(前端 /客户端关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问)

...

Facebook 出的 GraphQL 部分解决了这些问题，让它们看到了希望

遍历+递归，不管什么以及多少键值对，怎么嵌套 都可以解决.
这个网站大量使用了 遍历+递归 来解析 JSON，然后生成 JSON 后的注释、封装与解析 JSON 的 Java 代码
http://apijson.org/

遍历

@MuscleOf2016 @mikuazusa
已解决，现在可以用机器学习测试了：
1.点击右区域 第 3 个图标按钮（本地保存，点击查看共享），会进入测试用例界面
2.点击 切换机器学习的按钮（机器学习：已关闭），会开启机器学习
3.点击左区域 最右侧的图标按钮（回归测试）
http://apijson.org/