V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
chengdonghui
V2EX  ›  GraphQL

做前后端分离接口开发时,用 graphql 的多吗?

  •  
  •   chengdonghui · 2021-05-06 16:21:37 +08:00 · 2288 次点击
    这是一个创建于 1057 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近看了一些 graphql 相关的教程,感觉很不错,觉得对比于以往的 restful 开发模式,至少有以下优点: 1 降低接口开发的代码量 配合可实现 graphql 自动化的编程框架,比如 hasura 可自动生成 graphql 接口服务,其他编程语言和框架也有类似的 2 增强了接口的灵活性,也可以适应前端的需求变更 比如前端要求加个字段或者返回关联对象的时候,不用增加接口或者重写接口了,前端组织 ql 语句就能实现了 不知道这个技术,各位用的多吗?

    11 条回复    2024-03-11 13:03:07 +08:00
    Mithril
        1
    Mithril  
       2021-05-06 17:29:57 +08:00
    至少你说的这俩都算不上什么优点。。。
    1. 稍微复杂点的需求都不可能自动生成接口。除非你打算直接把数据库暴露出去。但这么干为啥不直接 Node JS 里上 ORM 一把梭?反正都是前端可以解决的需求。如果有后端计算或者复杂的多服务交互需求,GraphQL 都得自己写。
    2. 本质上和 1 是一个问题,数据结构足够简单而且数据库足够小的话就可以随便自动生成。数据量大了你就得自己写。比如你返回个列表,每个对象会返回一个关联查询的其他对象。自动生成的话它就是先查出来第一个列表,然后每个列表对象做一次查询。这种你得自己写 data loader 。
    yaphets666
        2
    yaphets666  
       2021-05-06 17:46:03 +08:00
    公司有个项目在用 graphql,总而言之麻烦多多,说不上一塌糊涂,但也差不多了。
    一个东西不流行,一定是这个东西本身有问题。
    yaphets666
        3
    yaphets666  
       2021-05-06 17:50:24 +08:00   ❤️ 1
    还有就是这个东西极大增加前端工作量,x5 x10 这种程度的增加,如果你推动 graphql 落地,你肯定和前端混不下去了。
    chengdonghui
        4
    chengdonghui  
    OP
       2021-05-06 18:03:30 +08:00
    @Mithril 可以了解一下 hasura[https://hasura.io/],应该可以减少 70%的手动编码量吧。
    chengdonghui
        5
    chengdonghui  
    OP
       2021-05-06 18:04:33 +08:00
    @yaphets666 用不用 graphql,前端不都要写调用 api 部分的代码吗?
    GzhiYi
        6
    GzhiYi  
       2021-05-06 18:12:00 +08:00
    尽管我觉得工作量有所增加,但数据字段可控的感觉还是不错的。
    yaphets666
        7
    yaphets666  
       2021-05-06 18:41:25 +08:00
    @chengdonghui 模糊查询啊 各种拼接 sql 都要前端来 你觉得没问题你就试试
    Mithril
        8
    Mithril  
       2021-05-07 09:03:47 +08:00
    @chengdonghui 你再仔细看看我说的,70%是不可能的。除非你需要在后端处理的业务逻辑几乎没有,这就相当于前端直连数据库。
    但你业务都简化到这种程度了,为啥不直接把后端全砍掉前端直接 node.js 里上 ORM ?
    eric96
        9
    eric96  
       2021-05-10 17:52:22 +08:00
    不懂就问,这个和我自定义一套查询协议有什么区别呢?我们公司也是有自己的查询协议,每个服务的基础协议都是一直的,然后我们做了一个数据查询服务的中间件,聚合了其它所有的能提供数据的微服务,然后根据业务需要归纳需要支持的查询场景,由这个中间件支持列表,嵌套查询,关联查询,聚合查询等,同时这个中间件也是支持 dataLoader,可以自己接入数据源
    1044523901
        10
    1044523901  
       2021-07-10 22:10:52 +08:00
    来看下,怎么说服领导,放弃 graphql,简直坑害前端同事。
    tangkikodo
        11
    tangkikodo  
       17 天前
    @Mithril 找到看法相同的了~ 握手

    作为一个查询语言,gql 是个后端请求数据聚合的好帮手 (但也有问题, 比如做层级聚合)

    但把这查询语言暴露给 client 就离大谱了 (除非做 github, jira 这种固定需求的 client )

    这约等于后端把业务处理的控制权分散了出去,client 拼个夸张的 query 之后, 过来说功能交付了, 但是性能不行, 你帮我优化优化。 这可就刺激了。

    gql 也好,orm 也好, 都只做了层层向下关联数据的事情, 并不负责从查询到的数据, 转换为前端所真正需要的视图这一块。

    如果使用 python 的话, 可以尝试一下 pydantic-resolve. https://allmonday.github.io/pydantic-resolve/dataloader/

    解决的就是这种,即负责关联数据的获取, 同时还能处理数据转换,然后再使用最朴素的传统接口返回。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1058 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 22:41 · PVG 06:41 · LAX 15:41 · JFK 18:41
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.