这是一个创建于 1299 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近看了一些 graphql 相关的教程，感觉很不错，觉得对比于以往的 restful 开发模式，至少有以下优点： 1 降低接口开发的代码量 配合可实现 graphql 自动化的编程框架，比如 hasura 可自动生成 graphql 接口服务，其他编程语言和框架也有类似的 2 增强了接口的灵活性，也可以适应前端的需求变更 比如前端要求加个字段或者返回关联对象的时候，不用增加接口或者重写接口了，前端组织 ql 语句就能实现了 不知道这个技术，各位用的多吗？
 |
1
Mithril 2021-05-06 17:29:57 +08:00
至少你说的这俩都算不上什么优点。。。
1. 稍微复杂点的需求都不可能自动生成接口。除非你打算直接把数据库暴露出去。但这么干为啥不直接 Node JS 里上 ORM 一把梭？反正都是前端可以解决的需求。如果有后端计算或者复杂的多服务交互需求，GraphQL 都得自己写。 2. 本质上和 1 是一个问题，数据结构足够简单而且数据库足够小的话就可以随便自动生成。数据量大了你就得自己写。比如你返回个列表，每个对象会返回一个关联查询的其他对象。自动生成的话它就是先查出来第一个列表，然后每个列表对象做一次查询。这种你得自己写 data loader 。 |
 |
2
yaphets666 2021-05-06 17:46:03 +08:00
公司有个项目在用 graphql，总而言之麻烦多多，说不上一塌糊涂，但也差不多了。
一个东西不流行，一定是这个东西本身有问题。 |
|
3
yaphets666 2021-05-06 17:50:24 +08:00  1
还有就是这个东西极大增加前端工作量，x5 x10 这种程度的增加，如果你推动 graphql 落地，你肯定和前端混不下去了。
|
 |
4
chengdonghui OP @Mithril 可以了解一下 hasura[https://hasura.io/],应该可以减少 70%的手动编码量吧。
|
|
5
chengdonghui OP @yaphets666 用不用 graphql，前端不都要写调用 api 部分的代码吗？
|
 |
6
GzhiYi 2021-05-06 18:12:00 +08:00
尽管我觉得工作量有所增加，但数据字段可控的感觉还是不错的。
|
|
7
yaphets666 2021-05-06 18:41:25 +08:00
@chengdonghui 模糊查询啊 各种拼接 sql 都要前端来 你觉得没问题你就试试
|
|
8
Mithril 2021-05-07 09:03:47 +08:00
@chengdonghui 你再仔细看看我说的，70%是不可能的。除非你需要在后端处理的业务逻辑几乎没有，这就相当于前端直连数据库。
但你业务都简化到这种程度了，为啥不直接把后端全砍掉前端直接 node.js 里上 ORM ？ |
 |
9
eric96 2021-05-10 17:52:22 +08:00
不懂就问，这个和我自定义一套查询协议有什么区别呢？我们公司也是有自己的查询协议，每个服务的基础协议都是一直的，然后我们做了一个数据查询服务的中间件，聚合了其它所有的能提供数据的微服务，然后根据业务需要归纳需要支持的查询场景，由这个中间件支持列表，嵌套查询，关联查询，聚合查询等，同时这个中间件也是支持 dataLoader，可以自己接入数据源
|
 |
10
1044523901 2021-07-10 22:10:52 +08:00
来看下，怎么说服领导，放弃 graphql，简直坑害前端同事。
|
 |
11
tangkikodo 259 天前
@Mithril 找到看法相同的了~ 握手
作为一个查询语言，gql 是个后端请求数据聚合的好帮手 （但也有问题， 比如做层级聚合） 但把这查询语言暴露给 client 就离大谱了 （除非做 github, jira 这种固定需求的 client ） 这约等于后端把业务处理的控制权分散了出去，client 拼个夸张的 query 之后， 过来说功能交付了， 但是性能不行， 你帮我优化优化。 这可就刺激了。 gql 也好，orm 也好， 都只做了层层向下关联数据的事情， 并不负责从查询到的数据， 转换为前端所真正需要的视图这一块。 如果使用 python 的话， 可以尝试一下 pydantic-resolve. https://allmonday.github.io/pydantic-resolve/dataloader/ 解决的就是这种，即负责关联数据的获取， 同时还能处理数据转换，然后再使用最朴素的传统接口返回。 |
Select Language