Graphql 太难用了，难监控性能，难客户端缓存

[dwu8555]

一眼望去全是同一个 route path ，只能一个一个点看看传入参数判断到底调用的是哪个 graphql 的 func 。

在 nginx 和 cloudflare 这边也没法缓存。

[hefish]

可是。。。可是操作灵活啊，想要啥就是啥。。。直接脱裤都可以。。。

[NowTime]

query 里加一点标记呢？
比如 ?action=xxxx

[Trim21]

确实，这个只能在 graphql resolver 里面监控了

[wangxiaoer]

我不用 grapgql ，但是你说的地址区分这个问题用反向代理加上路径重写不就好了？

[nomagick]

GraphQL 是一个大量无所事事前端倒逼少数忙到死的服务端的外行领导内行的产物。

本质上就是把数据库权限给前端开了；
任何试图真正用手写 GraphQL 服务端代码而不直接开数据库权限的尝试最终都会玩火自焚。

如果说有哪个前端说喜欢 GraphQL ，我劝他更进一步，直接学习 SQL ，后端把 MYSQL 给他开了，直接一步到位从浏览器执行 SQL ，监控走 SQL 审计那一套，无缝衔接。

[buffzty]

@nomagick 我就像你那样说的 让前端写条件 后端自动拼 sql 的 不过我加限制了,只能查询某些字段. 写后台的时候这非常节省时间 因为有限制也不会有安全问题. 后台一大堆模型,每个模型一大堆筛选条件,排序规则. 如果正常写得累死,我这种方法只需要一个通用函数,再为每个模型设置安全规则即可

https://github.com/real-web-world/bdk/blob/main/fastcurd/model.go#L198

GraphQL 我也不用纯纯恶心人的.

[IvanLi127]

客户端缓存肯定是能做的，中间链路监控不方便是因为你用 HTTP 解析更高一层的 GraphQL 了。中间链路缓存不了还是因为你在当他是 HTTP 做。
所以问题本质还是 GraphQL 基建不如 HTTP 。