这是一个创建于 1865 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近看了一些 graphql 相关的教程，感觉很不错，觉得对比于以往的 restful 开发模式，至少有以下优点： 1 降低接口开发的代码量 配合可实现 graphql 自动化的编程框架，比如 hasura 可自动生成 graphql 接口服务，其他编程语言和框架也有类似的 2 增强了接口的灵活性，也可以适应前端的需求变更 比如前端要求加个字段或者返回关联对象的时候，不用增加接口或者重写接口了，前端组织 ql 语句就能实现了 不知道这个技术，各位用的多吗？
 |
1 Mithril 2021 年 5 月 6 日至少你说的这俩都算不上什么优点。。。 |
 |
2 yaphets666 2021 年 5 月 6 日公司有个项目在用 graphql，总而言之麻烦多多，说不上一塌糊涂，但也差不多了。 |
|
3 yaphets666 2021 年 5 月 6 日 1
还有就是这个东西极大增加前端工作量，x5 x10 这种程度的增加，如果你推动 graphql 落地，你肯定和前端混不下去了。 |
 |
6 GzhiYi 2021 年 5 月 6 日尽管我觉得工作量有所增加，但数据字段可控的感觉还是不错的。 |
|
8 Mithril 2021 年 5 月 7 日@chengdonghui 你再仔细看看我说的，70%是不可能的。除非你需要在后端处理的业务逻辑几乎没有，这就相当于前端直连数据库。 |
 |
9 eric96 2021 年 5 月 10 日不懂就问，这个和我自定义一套查询协议有什么区别呢？我们公司也是有自己的查询协议，每个服务的基础协议都是一直的，然后我们做了一个数据查询服务的中间件，聚合了其它所有的能提供数据的微服务，然后根据业务需要归纳需要支持的查询场景，由这个中间件支持列表，嵌套查询，关联查询，聚合查询等，同时这个中间件也是支持 dataLoader，可以自己接入数据源 |
 |
10 1044523901 2021 年 7 月 10 日来看下，怎么说服领导，放弃 graphql，简直坑害前端同事。 |
 |
11 tangkikodo 2024 年 3 月 11 日@Mithril 找到看法相同的了~ 握手 作为一个查询语言，gql 是个后端请求数据聚合的好帮手 （但也有问题， 比如做层级聚合） 但把这查询语言暴露给 client 就离大谱了 （除非做 github, jira 这种固定需求的 client ） 这约等于后端把业务处理的控制权分散了出去，client 拼个夸张的 query 之后， 过来说功能交付了， 但是性能不行， 你帮我优化优化。 这可就刺激了。 gql 也好，orm 也好， 都只做了层层向下关联数据的事情， 并不负责从查询到的数据， 转换为前端所真正需要的视图这一块。 如果使用 python 的话， 可以尝试一下 pydantic-resolve. https://allmonday.github.io/pydantic-resolve/dataloader/ 解决的就是这种，即负责关联数据的获取， 同时还能处理数据转换，然后再使用最朴素的传统接口返回。 |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。