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

graphql 和 apijson 怎么选?

  •  
  •   legiorange · 2021-03-16 19:13:52 +08:00 via Android · 1868 次点击
    这是一个创建于 1351 天前的主题,其中的信息可能已经有所发展或是发生改变。

    就单纯好奇这两个技术的优劣,场景。

    跪求大佬们指指点点。

    4 条回复    2022-06-06 14:08:05 +08:00
    janus77
        1
    janus77  
       2021-03-16 21:47:59 +08:00   ❤️ 1
    你都不知道使用场景的话为啥还要用这些,直接用其他主流的就可以
    icy37785
        2
    icy37785  
       2021-03-17 04:37:24 +08:00 via iPhone
    等你有场景了就自然知道应该用什么技术了。没场景的情况下看介绍也理解不了其中优劣。
    letitbesqzr
        3
    letitbesqzr  
       2021-03-17 08:47:07 +08:00   ❤️ 1
    没场景的情况下去使用这些技术,只会增大工作量,毫无用途
    xmsz
        4
    xmsz  
       2022-06-06 14:08:05 +08:00   ❤️ 1
    就我目前来说

    我是想找个前端直接查询 sql 的方案

    我的场景是,我在在做 DEMO 项目,然后遇到数据的存储。本来是用 indexedb 的,但是这玩意和 localstorage 一样的限制,所以不能满足更多需求
    那么就需要一个持久化储存
    然后持久化存储有了,但是前端并不能直接访问数据库,需要某个中间服务去处理,而且这个中间服务必须简单,不能花太多精力

    然后这时候的方案就是


    1. 直接传 sql , 这个肯定不行,又慢又不安全
    2. orm 写接口,加快了查询速度,但还是要写接口,不符合需求
    3. graphql ,还是要写 schema...
    4. apijson 只有 java ,我 TM...
    5. nextjs ,另一种思路可以但是副作用更大


    然后说一下 graphql ,他的场景主要是解决前端层的需求,更具体的是 BFF 层的需求,比如接口裁剪、组合。不是解决后端层的需求。后端其实并没有任何收益,说代码少写实际上并没有,因为你用普通的 orm 也能搞。
    当然,有很多工具可以实现自定义生成 schema ,但还是不够快,而且费了太多功夫的。像这种情况下,我们肯定是不推荐硬写。就能实现但不是它该做的


    那么剩下就是 apijson ,首先我一看到那个 github 项目页真的。真的是很糟糕
    我感觉就是个 80 后程序员硬写出来的东西,而且毫无审美
    更加意外的是居然还有那么多产品在用? 当然这也说明国内真的很多公司水得一比

    因为如果你真的有技术人员,或者真的有选型的能力,那绝对不可能选择 apijson ,怎么敢用在生产环境上????
    这就和前端的 uniapp 一样

    虽然火,但是他真的又菜又没有创新。受众人群就是非程序员或者水平菜得不行的程序员
    当然还有一批 80 后的程序员,就真的和社会脱节了,这个东西才是他们能认知的东西


    然后目前来说,像我这个场景下,graphql 还是无奈的优选

    最简单的方法就是 graphql + 自动生成 schema 然后放在云函数就可以跑了
    再麻烦一点就是 graphql + orm + 云函数,然后如果表结构更新,记得更新云函数就行
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3243 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 13:02 · PVG 21:02 · LAX 05:02 · JFK 08:02
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.