GraphQL 有哪些缺点、不足？

老规矩，等一个朋友。

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

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

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

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

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

那个男人还会来吗？

辣个男人

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

@gbin apijson

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

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

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

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

日常等人。

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

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

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 是全部查询的。

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

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

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

树形结构数据。让人头大

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@TommyLemon
这个男人？

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

@StarkWhite

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

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

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

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

@StarkWhite 看下这种血腥场面，不得不服 t/568631?p=1#r_7399882

众口烁金 积毁销骨

多伤