GraphQL 有哪些缺点、不足？

[find456789]

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

---

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

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

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

---

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

[kyuuseiryuu]

老规矩，等一个朋友。

[find456789]

GraphQL 好像也不能用 get 方式来查询，可惜了，

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

如果 GraphQL 只能发 post，那就无法在 cdn 上缓存了

[hronro]

1. GraphQL 并不一定会暴露数据库的字段和结构
2. 这个主要看 GraphQL 服务端的实现中，能否自动处理 Schema 和数据库表之间的关系。即使在较为简单的实现中，也可以用 dataloader 之类的工具来缓解嵌套查询中对相同资源重复查询的压力
3. GraphQL 接口的缓存，基本上是通过 GraphQL 客户端 （如 Apollo, Relay 之类）来进行，不会走浏览器本身的缓存机制

[AltairT]

@kyuuseiryuu #1 你说的这个朋友已经快三个月没发帖了...

[zjsxwc]

那个男人还会来吗？

[wanacry]

辣个男人

[gbin]

@kyuuseiryuu #1 那个男人到底是谁?

[agagega]

@gbin apijson

[mxtob]

之前项目用过 graphql，对于 api 结构来说对前端友好，但是后端其实就是把文档也写在代码里，除了这个文档其他的代码量比 rpc 风格多了点，就是比较麻烦习惯了就好。

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

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

以上是本人片面看法 有更好见解望指出

[littleangel]

日常等人。

[baiyi]

那个男人是不是号被 ban 了，好久没看到了

[abcbuzhiming]

*.在这个时代暴露数据库结构并不是特别大的问题
*.GraphQL 的最大问题在于它本质上只是一个协议，它解决了后端面临的复杂度问题吗？我觉得一点都没有，所以这个东西前端同学很喜欢（因为他们不需要面对后端复杂度问题），而遭到了后端同学的强烈抵制（因为他们无法容忍前端同学这样想咋地就咋地的要数据）。
所以这个东西一定会慢慢的回到和 REST 差不多的位置上，因为它充其量就是个协议，可能比 REST 更强一点，等各位前端的同学入侵到后端的领域，然后被后端的复杂度问题恶心之后。就会明白这玩意局限在哪里

[Mithril]

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]

去年写过一个 ppt， 有一节总结了一下 GraphQL VS RESTFul 的优缺点比较

https://allovince.github.io/gimare/?8ba1c92890c74cc7f4e68f09c79ec0d1#/6

[MaxTan]

哈哈，辣个蓝人都成了 v2 的一个梗了

[baihaihui01]

树形结构数据。让人头大

[adjusted]

如果是前端 query 有很多解决方案，但是 GraphQL 的精髓我觉得可能是 Type

[zpf124]

谁来给解惑一下 辣个蓝人 是谁啊?
天天 APIJSON 到处灌水的那个?

[passerbytiny]

借问一下，GraphQL 跟后端有啥关系，前端直接查询数据库，后端不是没了吗？

[AshoneA]

前端的痛点让后端解决了，没多少团队的后端喜欢这么做

[nigelvon]

缺点是理解其思想的门槛比较高，老项目需要重构。水平一般的团队建议暂时不要考虑，仅仅是会用的话，用 RESTful 的思想来写 GraphQL 带来的全是缺点没有什么优点。

[Caballarii]

怎么天天有人把 GraphQL 和数据库合起来说？？？这俩东西隔着后端十万八千里行代码，八竿子打不着好吗

[StarkWhite]

@gbin 就是那个在 V 站天天发广告，各种完爆，拳打 GraphQL 脚踢 Hibernate 的那个大佬 /狗头

[StarkWhite]

@zpf124 没错，是他是他就是他

[StarkWhite]

@passerbytiny 如果只有 CRUD，那你还真得担心自己要下岗了

[jy02201949]

@kyuuseiryuu #1 好久没看到他的推广贴了，好想念

[wangxiaoaer]

@AltairT #4 听你这么说我才反应过来是啥意思，我已经把他 B 了，所以不知道那个可怕的男人近况如何了？

[StarkWhite]

@jy02201949 你们居然关心起他来了，这是得了斯德哥尔摩综合征？ /滑稽

[TangMonk]

不觉得 GraphQL 好用，对于后段来说反而麻烦

[StarkWhite]

@TangMonk 就写几个 schema，type 等，resolver 里实现简单的 CRUD 就行了，graphql 会自动过滤、组装数据

[TangMonk]

@TommyLemon
这个男人？

[StarkWhite]

@TangMonk 就是他，apijson 作者，天天发广告烦死了

[TangMonk]

@StarkWhite 😄

[newtype0092]

@StarkWhite 他是我见过最敬业的推广，真的是安利万众发自真心。

[ohoh]

都在说那个男人，那个男人难道做的不对？

[StarkWhite]

@newtype0092 “你如果无聊的话, 你可以每天关注一下 v2 的 java 版块的话题.
然后你就能发现一只复读机, 涵盖了大部分话题, 只要话题和 ORM, http Server,Restful 这几个任意一个有一丁点关联, 他都会自说自话到他的 APIJSON.

你要是单纯听他吹,感觉他一个项目比 Spring 全部项目都万能. 除了不能生孩子没有他的的框架做不了的.”

[StarkWhite]

@newtype0092 那是，只要有人质疑，就亲自下场和大家互 a，一定要把对方说到不再反驳为止 /狗头

[StarkWhite]

@StarkWhite 看下这种血腥场面，不得不服 https://www.v2ex.com/t/568631?p=1#r_7399882

[ohoh]

众口烁金 积毁销骨

[zzzzzzk]

多伤