有用过 GraphQL 的吗？可以进来说说相比 restful 的优劣吗?

[ReinerShir]

在使用 restful 中，经常发现无法严格按照 restful 规范来设计，结果就是慢慢的变成的一个仅仅是看起来像是 restful 的设计

因此网上找资料发现了 GraphQL，它可以大量节省请求次数，返回字段由前端决定，也不用写文档了，初步了解之下感觉很不错。

但转念一想可能没这么简单，有没有用过的大佬来说说它有什么坑？

相比 restful 的优劣有哪些？

[baiyi]

graphQL 是给 API 设计的查询语言，应该属于特殊场景（资源有着较多复杂查询）适用。

[jingcoco]

我自学了一段时间,前段时间看帖子说热度降了下来,说是前端同学用的爽,但是后端的同学不愿意做. 不过我个人感觉还是想继续学习.然后后端选一个 express 框架的.

[jingcoco]

个人没有太懂那个帖子的那个言论,为啥后端这么抵触....

[co1mugx]

调用端是爽了，但是服务端除了写接口还得写描述，不然怎么公布可以获取哪些字段。所以并不能说前端要什么可以自己决定，他要你也得有啊

[EPr2hh6LADQWqRVH]

Restful 已经是过度宣传实际意义不大的东西了，GraphQL 根本就是这种 xjb 宣传贴大字报行为的无敌威力加强版。

只有一种情况 GraphQL 有用：
当你想把 SQL 数据库查询工作量前置到浏览器的时候。

任何其他情况都不适用， 任何。


如果你的应用是用的 MongoDB 或者任何不是 SQL 的，等着难受吧，恶心死你。
如果你的应用是高度动态的，等着难受吧，恶心死你。
如果你的应用是有分页概念而不是直接查数据库的，等着难受吧，恶心死你。

如果你的应用是你自己设计的有自己的想法会思考，而不是按照丫挺的教程 c-c c-v，等着难受吧，恶心死你

[co1mugx]

之前用 nestjs 的时候但是提供了一个方案，可以通过代码生成 gql 文件，其他框架应该也有类似操作

[atonku]

你出任你出，我用算我输。

[adjusted]

我们用 graphql schema 生成对应的 go struct，写起来很舒服。GraphQL 初看是一种自定义查询的协议，其实我认为更重要的是类型，代表着 API 开发向 schema driven 和类型的转变，其实挺符合 javascript 向 typescript 转变的倾向。

[FantaMole]

没有实际业务接口真的会严格按 restful 的标准来执行的，满足不了业务要求。它是一份标准，你可以用来参考，但不是什么都要按这上面来做。而且说句实话，你会发现同一个公司的同事英语水平真是参差不齐，就说 restful 的 api 路径命名，不用动词就要憋死一批人，该不该用复数，又要憋死一批人

[wdhwg001]

不看好，因为请求合并了就意味着无法区分主次，服务器端也需要一口气准备所有数据，这样传输的并行还是查询的并行都更难实现。
更不用说，很多时候服务器端是需要对特定的 crud 做优化的，需求放这么开的话这种优化也更困难了。

[zjsxwc]

个人觉得 GraphQL 与几十年前的 CS 架构的软件没什么不同，

CS 时代后端直接写数据库存储过程，客户端直接用 SQL，权限控制在 DB 里配置，

历史总是惊人的相似。

[KuroNekoFan]

如果你有很原子的 restful 后端，graphql 的意义在于减少数据传输的冗余

[mahone3297]

最近看到一篇文章，对比了 graphQL 和 restful 区别，可以参考下
https://mp.weixin.qq.com/s?__biz=MzA3MDIyNTgzNA==&mid=2649974959&idx=1&sn=e91c177840276c4cd93c0482ad1d4c81&chksm=86c7d26ab1b05b7c6bfce96b3adaba7254512de86dd53fa36152734bedcacd112ea2f34b3394&token=43242864&lang=zh_CN#rd

[forgottencoast]

@FantaMole “该不该用复数” 笑了，真的，只能靠全公司统一规范来解决了。

[bsg1992]

GraphQL 和 restful 场景特别特别的小。

[masterclock]

个人使用 GraphQL 的主要原因是强类型。
React + TypeScript 下用 introspection 出来的 schema 和 gql tag 里的查询语句预编译生成 react 的 hook，保证编译能过。
服务端用 apollo 的 gateway 做 federation， 组合多个 GraphQL 的后端，几个后端的协调一下命名等，相互间访问和隔离问题都不大。
GraphQL 用来提供 “one api”，跟 SQL 什么的都没什么关系，GraphQL 也不是 SQL 的有效抽象。
用什么数据库也无所谓，反正都在 resolver 里解决。
高度动态确实不太好，直接变成 AnyQL，类型意义全没了。
分页用 Relay 定义，支持 cursor 或 offset，实现起来比较麻烦，但客户端上好用点。

[ReinerShir]

@forgottencoast 想问下查询参数很多的情况下你们是怎么解决的？ restful 规定查询使用 get，参数拼 url 后面，但是参数一多，那个参数栏惨不忍睹，取值、维护都很麻烦，所以我们是直接查询用 POST 、参数放 BODY 里

[coolair]

权限不好控制

[676529483]

如果你的接口需要门框模式（也就是经常需要把几个接口整合起来，减少调用次数），GraphQL 很赞。当然这是前端，后端不会减少代码量

[bruceshi]

1. GraphQL，代码生成是必不可少的，不论是 code first 还是 schema first，要不然会很麻烦，选择一个好的工具（框架）很重要，有兴趣的同学可以看下[NestJs]( https://docs.nestjs.com/graphql)的一些实现
2. GraphQL 是 API 查询语言不等于 GraphQL 直接查询数据库
3. GraphQL 只是一种新的组织 API 查询方式和结构的工具，本质上还是 HTTP
4. 说 MongoDB 的，我觉得不论是 Restful 还是 GraphQL 我都会死，GraphQL 和你用什么 DB 没有本质上的关系
5. GraphQL 也可以很简单的分页，如果觉得分页有问题的，我相信是看到网上很多使用 [Relay]( https://relay.dev/docs/en/graphql-server-specification.html#connections) 提到的分页方式，代码在自己手里，想写简单就写简单点。
6. 权限控制的话，可以精确到 field level，不知道大家提到的权限问题具体是什么，我暂时没遇到很复杂的权限控制，没有什么发言权。
7. 复杂度，可以通过定义 complexity 控制。
8. 缓存问题，payload 大的问题，GraphQL 可以通过[persisted queries]( https://www.apollographql.com/docs/apollo-server/performance/apq/)将 POST 变成 GET
9. 多学习，多思考，而不是无脑黑一个夸一个。再黑的东西也有闪光点。