这是一个创建于 1920 天前的主题，其中的信息可能已经有所发展或是发生改变。
我目前用的 restful， 打算切换到 GraphQL
我目前感觉 GraphQL 有 2 个缺点：
1.会暴露数据库结构（字段名），但我不清楚在如今这个年代，是否还有保护字段名、数据库结构的需要
2.嵌套查询，比较费性能
请问各位用 GraphQL 的朋友，说说它的缺点吧，谢谢
 |
1
kyuuseiryuu 2019-09-24 22:21:08 +08:00  10
老规矩，等一个朋友。
|
 |
2
find456789 OP GraphQL 好像也不能用 get 方式来查询，可惜了，
我有一些接口，查询的结果希望可以缓存在 cdn 上，展示给某些用户（未登录用户）， 如果 GraphQL 只能发 post，那就无法在 cdn 上缓存了 |
 |
3
hronro 2019-09-24 22:40:06 +08:00 via iPhone 1
1. GraphQL 并不一定会暴露数据库的字段和结构
2. 这个主要看 GraphQL 服务端的实现中，能否自动处理 Schema 和数据库表之间的关系。即使在较为简单的实现中，也可以用 dataloader 之类的工具来缓解嵌套查询中对相同资源重复查询的压力 3. GraphQL 接口的缓存，基本上是通过 GraphQL 客户端 （如 Apollo, Relay 之类）来进行，不会走浏览器本身的缓存机制 |
 |
4
AltairT 2019-09-24 23:06:12 +08:00
@kyuuseiryuu #1 你说的这个朋友已经快三个月没发帖了...
|
 |
5
zjsxwc 2019-09-24 23:07:46 +08:00 via Android
那个男人还会来吗？
|
 |
6
wanacry 2019-09-24 23:10:28 +08:00 via iPhone
辣个男人
|
 |
7
gbin 2019-09-24 23:46:44 +08:00 via Android
@kyuuseiryuu #1 那个男人到底是谁?
|
 |
9
mxtob 2019-09-25 01:05:02 +08:00 via iPhone 1
之前项目用过 graphql，对于 api 结构来说对前端友好，但是后端其实就是把文档也写在代码里，除了这个文档其他的代码量比 rpc 风格多了点，就是比较麻烦习惯了就好。
对于 query 类型(get)，数据库查询字段多少还是在 model 那里定死了，我们是这么做，所以前端那边只是返回取多取少了数据而已，这个点其实想问下其他用过人是怎样的 对于 mutation 类型(post)，之前踩过坑，前端过滤和后端过滤识别过滤有点难，因为我们正则菜，抽象语法树写不出，有些人能利用 graphql 这种语法进行攻击，总之这个是实际情况，如果过滤这块没做好建议 post 类型走传统风格别 graphql 以上是本人片面看法 有更好见解望指出 |
 |
10
littleangel 2019-09-25 07:32:07 +08:00 via iPhone
日常等人。
|
 |
11
baiyi 2019-09-25 08:32:08 +08:00
那个男人是不是号被 ban 了，好久没看到了
|
 |
12
abcbuzhiming 2019-09-25 09:29:07 +08:00 2
*.在这个时代暴露数据库结构并不是特别大的问题
*.GraphQL 的最大问题在于它本质上只是一个协议，它解决了后端面临的复杂度问题吗？我觉得一点都没有，所以这个东西前端同学很喜欢（因为他们不需要面对后端复杂度问题），而遭到了后端同学的强烈抵制（因为他们无法容忍前端同学这样想咋地就咋地的要数据）。 所以这个东西一定会慢慢的回到和 REST 差不多的位置上，因为它充其量就是个协议，可能比 REST 更强一点，等各位前端的同学入侵到后端的领域，然后被后端的复杂度问题恶心之后。就会明白这玩意局限在哪里 |
 |
13
Mithril 2019-09-25 09:48:48 +08:00 1
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 是全部查询的。 |
 |
14
AlloVince 2019-09-25 10:04:28 +08:00 1
去年写过一个 ppt， 有一节总结了一下 GraphQL VS RESTFul 的优缺点比较
https://allovince.github.io/gimare/?8ba1c92890c74cc7f4e68f09c79ec0d1#/6 |
 |
15
MaxTan 2019-09-25 10:08:26 +08:00
哈哈，辣个蓝人都成了 v2 的一个梗了
|
 |
16
baihaihui01 2019-09-25 10:09:36 +08:00
树形结构数据。让人头大
|
 |
17
adjusted 2019-09-25 10:13:12 +08:00
如果是前端 query 有很多解决方案，但是 GraphQL 的精髓我觉得可能是 Type
|
 |
18
zpf124 2019-09-25 10:20:47 +08:00
谁来给解惑一下 辣个蓝人 是谁啊?
天天 APIJSON 到处灌水的那个? |
 |
19
passerbytiny 2019-09-25 10:27:35 +08:00
借问一下，GraphQL 跟后端有啥关系，前端直接查询数据库，后端不是没了吗？
|
 |
20
AshoneA 2019-09-25 10:30:45 +08:00
前端的痛点让后端解决了，没多少团队的后端喜欢这么做
|
 |
21
nigelvon 2019-09-25 10:36:26 +08:00
缺点是理解其思想的门槛比较高，老项目需要重构。水平一般的团队建议暂时不要考虑，仅仅是会用的话，用 RESTful 的思想来写 GraphQL 带来的全是缺点没有什么优点。
|
 |
22
Caballarii 2019-09-25 10:37:11 +08:00 1
怎么天天有人把 GraphQL 和数据库合起来说？？？这俩东西隔着后端十万八千里行代码，八竿子打不着好吗
|
 |
23
StarkWhite 2019-09-25 16:18:13 +08:00
@gbin 就是那个在 V 站天天发广告，各种完爆，拳打 GraphQL 脚踢 Hibernate 的那个大佬 /狗头
|
|
24
StarkWhite 2019-09-25 16:23:06 +08:00
@zpf124 没错，是他是他就是他
|
|
25
StarkWhite 2019-09-25 16:23:49 +08:00
@passerbytiny 如果只有 CRUD，那你还真得担心自己要下岗了
|
 |
26
jy02201949 2019-09-25 16:27:55 +08:00
@kyuuseiryuu #1 好久没看到他的推广贴了，好想念
|
 |
27
wangxiaoaer 2019-09-25 16:29:52 +08:00
@AltairT #4 听你这么说我才反应过来是啥意思，我已经把他 B 了，所以不知道那个可怕的男人近况如何了？
|
|
28
StarkWhite 2019-09-25 16:41:18 +08:00
@jy02201949 你们居然关心起他来了，这是得了斯德哥尔摩综合征？ /滑稽
|
 |
29
TangMonk 2019-09-25 16:46:54 +08:00
不觉得 GraphQL 好用，对于后段来说反而麻烦
|
|
30
StarkWhite 2019-09-25 16:51:43 +08:00
@TangMonk 就写几个 schema，type 等，resolver 里实现简单的 CRUD 就行了，graphql 会自动过滤、组装数据
|
|
31
TangMonk 2019-09-25 16:53:04 +08:00
@TommyLemon
这个男人？ |
|
32
StarkWhite 2019-09-25 16:58:54 +08:00
@TangMonk 就是他，apijson 作者，天天发广告烦死了
|
|
33
TangMonk 2019-09-25 17:05:12 +08:00 via iPhone
@StarkWhite 😄
|
 |
34
newtype0092 2019-09-25 17:11:53 +08:00
@StarkWhite 他是我见过最敬业的推广，真的是安利万众发自真心。
|
 |
35
ohoh 2019-09-25 17:40:55 +08:00
都在说那个男人，那个男人难道做的不对？
|
|
36
StarkWhite 2019-09-25 17:45:27 +08:00
@newtype0092 “你如果无聊的话, 你可以每天关注一下 v2 的 java 版块的话题.
然后你就能发现一只复读机, 涵盖了大部分话题, 只要话题和 ORM, http Server,Restful 这几个任意一个有一丁点关联, 他都会自说自话到他的 APIJSON. 你要是单纯听他吹,感觉他一个项目比 Spring 全部项目都万能. 除了不能生孩子没有他的的框架做不了的.” |
|
37
StarkWhite 2019-09-25 17:48:34 +08:00
@newtype0092 那是，只要有人质疑，就亲自下场和大家互 a，一定要把对方说到不再反驳为止 /狗头
|
|
38
StarkWhite 2019-09-25 17:52:10 +08:00
@StarkWhite 看下这种血腥场面，不得不服 https://www.v2ex.com/t/568631?p=1#r_7399882
|
|
39
ohoh 2019-09-26 09:03:26 +08:00
众口烁金 积毁销骨
|
 |
40
zzzzzzk 2020-07-09 15:27:20 +08:00
多伤
|
Select Language