GraphQL 有哪些缺点、不足?

2019-09-24 22:13:30 +08:00
 find456789

我目前用的 restful, 打算切换到 GraphQL


我目前感觉 GraphQL 有 2 个缺点:

1.会暴露数据库结构(字段名),但我不清楚在如今这个年代,是否还有保护字段名、数据库结构的需要

2.嵌套查询,比较费性能


请问各位用 GraphQL 的朋友,说说它的缺点吧,谢谢

9109 次点击
所在节点    问与答
40 条回复
kyuuseiryuu
2019-09-24 22:21:08 +08:00
老规矩,等一个朋友。
find456789
2019-09-24 22:25:44 +08:00
GraphQL 好像也不能用 get 方式来查询,可惜了,

我有一些接口,查询的结果希望可以缓存在 cdn 上,展示给某些用户(未登录用户),

如果 GraphQL 只能发 post,那就无法在 cdn 上缓存了
hronro
2019-09-24 22:40:06 +08:00
1. GraphQL 并不一定会暴露数据库的字段和结构
2. 这个主要看 GraphQL 服务端的实现中,能否自动处理 Schema 和数据库表之间的关系。即使在较为简单的实现中,也可以用 dataloader 之类的工具来缓解嵌套查询中对相同资源重复查询的压力
3. GraphQL 接口的缓存,基本上是通过 GraphQL 客户端 (如 Apollo, Relay 之类)来进行,不会走浏览器本身的缓存机制
AltairT
2019-09-24 23:06:12 +08:00
@kyuuseiryuu #1 你说的这个朋友已经快三个月没发帖了...
zjsxwc
2019-09-24 23:07:46 +08:00
那个男人还会来吗?
wanacry
2019-09-24 23:10:28 +08:00
辣个男人
gbin
2019-09-24 23:46:44 +08:00
@kyuuseiryuu #1 那个男人到底是谁?
agagega
2019-09-25 00:48:29 +08:00
@gbin apijson
mxtob
2019-09-25 01:05:02 +08:00
之前项目用过 graphql,对于 api 结构来说对前端友好,但是后端其实就是把文档也写在代码里,除了这个文档其他的代码量比 rpc 风格多了点,就是比较麻烦习惯了就好。

对于 query 类型(get),数据库查询字段多少还是在 model 那里定死了,我们是这么做,所以前端那边只是返回取多取少了数据而已,这个点其实想问下其他用过人是怎样的

对于 mutation 类型(post),之前踩过坑,前端过滤和后端过滤识别过滤有点难,因为我们正则菜,抽象语法树写不出,有些人能利用 graphql 这种语法进行攻击,总之这个是实际情况,如果过滤这块没做好建议 post 类型走传统风格别 graphql

以上是本人片面看法 有更好见解望指出
littleangel
2019-09-25 07:32:07 +08:00
日常等人。
baiyi
2019-09-25 08:32:08 +08:00
那个男人是不是号被 ban 了,好久没看到了
abcbuzhiming
2019-09-25 09:29:07 +08:00
*.在这个时代暴露数据库结构并不是特别大的问题
*.GraphQL 的最大问题在于它本质上只是一个协议,它解决了后端面临的复杂度问题吗?我觉得一点都没有,所以这个东西前端同学很喜欢(因为他们不需要面对后端复杂度问题),而遭到了后端同学的强烈抵制(因为他们无法容忍前端同学这样想咋地就咋地的要数据)。
所以这个东西一定会慢慢的回到和 REST 差不多的位置上,因为它充其量就是个协议,可能比 REST 更强一点,等各位前端的同学入侵到后端的领域,然后被后端的复杂度问题恶心之后。就会明白这玩意局限在哪里
Mithril
2019-09-25 09:48:48 +08:00
1. 不一定,你的 GraphQL Schema 并不一定需要跟数据库类型对应,虽然对应了比较好理解,但不是强制的。
2. 取决于你如何设计 Schema 和是否使用 DataLoader。你可以设计成聚合类型,而不是单纯的 Domain 类型。或者你自己写 DataLoader。
不过这两个问题,RESTful 一样有,除非你并不是按照纯粹的 RESTful 设计接口的。
GraphQL 可以很好的解决前后端的沟通问题,省去你写接口文档的时间,同时也可以做一些简单的类型验证。你甚至可以一套 Schema 同时生成前后端所使用的类型。前端也可以写一些简单的聚合查询而不需要和后台沟通。

GraphQL 只是一层协议,和缓存无关。你可以在前端把查询的 JSON 直接 Base64 拼到 GET 请求的 Query String 里,然后后台取到这个 JSON 再去走 GraphQL 的 Parser。虽然默认情况下 GraphQL 都是走 POST 请求,但不代表你非得这样做。

GraphQL 的权限验证比较麻烦,如果你要区分用户权限可以访问的数据,实现起来不如 RESTful 方便。毕竟根据用户权限阻断访问请求在各种 middleware 里面都可以实现。但你用 GraphQL 就要在用户 context 里面自己验证。

我的项目不需要根据用户区分访问内容,所以只用了 GraphQL 做了查询。修改的接口很简单而且稳定,所以直接用了 RESTful。对于查询,因为类型之间有嵌套关系。比如 ClassA 包含 ClassB 对象,就可以在 DataLoader 里面省去查 B 的那部分。但对于单个类型,所有 field 是全部查询的。
AlloVince
2019-09-25 10:04:28 +08:00
去年写过一个 ppt, 有一节总结了一下 GraphQL VS RESTFul 的优缺点比较

https://allovince.github.io/gimare/?8ba1c92890c74cc7f4e68f09c79ec0d1#/6
MaxTan
2019-09-25 10:08:26 +08:00
哈哈,辣个蓝人都成了 v2 的一个梗了
baihaihui01
2019-09-25 10:09:36 +08:00
树形结构数据。让人头大
adjusted
2019-09-25 10:13:12 +08:00
如果是前端 query 有很多解决方案,但是 GraphQL 的精髓我觉得可能是 Type
zpf124
2019-09-25 10:20:47 +08:00
谁来给解惑一下 辣个蓝人 是谁啊?
天天 APIJSON 到处灌水的那个?
passerbytiny
2019-09-25 10:27:35 +08:00
借问一下,GraphQL 跟后端有啥关系,前端直接查询数据库,后端不是没了吗?
AshoneA
2019-09-25 10:30:45 +08:00
前端的痛点让后端解决了,没多少团队的后端喜欢这么做

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

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

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

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

© 2021 V2EX