关于 GQL 的新动态,各位怎么看,对前端后端有什么影响

2018-11-08 09:48:21 +08:00
 gzf6

https://www.cnbeta.com/articles/tech/785733.htm

4954 次点击
所在节点    程序员
48 条回复
cyril4free
2018-11-08 09:50:10 +08:00
隔壁组的同事已经用上了,据说很爽。。免去了前后端对接口参数的困扰。。
fzleee
2018-11-08 09:59:23 +08:00
所以,GQL 是个什么东西...
gzf6
2018-11-08 10:00:45 +08:00
heww
2018-11-08 10:06:27 +08:00
用起来很爽,不用费什么脑子。但它的 js client 不好用。
IsaacYoung
2018-11-08 10:39:20 +08:00
去 redux 化
reus
2018-11-08 10:57:06 +08:00
如果需要高性能,后端就要手写,就没法自动生成代码
如果自动生成代码,那性能…… 就好像查询不需要开销似的
关系数据库本质不是图数据库,后端需要实现这两种模型之间的转换,没有简单高效的办法
反正我是不想做这种东西,除非有图数据库可以替代关系数据库
trait
2018-11-08 11:08:58 +08:00
应该不错,GitHub 的 gql 版本 api 已经有了,正在过渡,Twitter 貌似也在用
TommyLemon
2018-11-08 11:15:48 +08:00
说明很多公司都前后端分离后碰到了各种恼人的开发与沟通问题

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 部分解决了这些问题,让它们看到了希望
TommyLemon
2018-11-08 11:18:31 +08:00
@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
find456789
2018-11-08 11:21:12 +08:00
我是小白

感觉权限是个问题呀, 比如 没有登陆会员只能查看 3 个字段,vip 能查看 5 个字段, 管理员能查看所有字段, 这在 gql 上是不是很难实现呀?
TommyLemon
2018-11-08 11:24:58 +08:00
@find456789 逻辑不难,但判断要写很多,这里有教程
juejin.im/post/5b13cda1f265da6e4a6bcfee
Hilong
2018-11-08 11:30:39 +08:00
@TommyLemon 昨天还看到公众号推送去搜索了 下,支持
asd123456cxz
2018-11-08 11:45:15 +08:00
@TommyLemon #11 看到老哥推广好多次了。。支持下
TommyLemon
2018-11-08 11:54:52 +08:00
@Hilong @asd123456cxz 感谢。
其实我有时也在一些技术群推广 GraphQL,在公司也为 GraphQL 开过分享会。
不怕对比,就怕大家不知道、不认可 前端定制接口 的做法。
一部分用户是因为先了解到 GraphQL,然后看不懂、不会用、用起来麻烦,
后面看到 APIJSON 就转了过来。
RubyJack
2018-11-08 11:55:17 +08:00
性能一塌糊涂
clino
2018-11-08 12:04:16 +08:00
@TommyLemon 能用在 python 后端上吗?
TommyLemon
2018-11-08 12:09:44 +08:00
@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
feverzsj
2018-11-08 12:11:51 +08:00
前端老是喜欢搞些低能的东西
TommyLemon
2018-11-08 12:12:20 +08:00
@clino
目前只有 Java,C#, PHP, Node.js 的后端实现 以及 Android,iOS,JavaScript 的 Demo。
但 APIJSON 的协议是与语言无关的,可以用 Python 等其它语言实现,可以参考这个引导
github.com/TommyLemon/APIJSON/issues/38
buhi
2018-11-08 12:16:52 +08:00
大兄弟, 你怎么保证你这个自己一个人在做的东西就能比 fb 一个大厂在 backup 的东西要好用呢

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/505627

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX