这几天逛知乎发现 apijson 的作者还在暴力推荐自己的项目

哈哈哈哈作者是之前传音的同事，他当时的岗位就是写安卓客户端的，当时刚出来的时候在公司推广，我们一堆后端就在说这玩意咋用，谁愿意开放底层的权限给你，没想到今年刷到 16k+ start 了，这玩意正经人谁用啊。。

@qwerasdf123 原来就一个写安卓的，这属于是强行跨领域外行指导内行了吧，瞎搞什么后端 😂

what is the jb 玩意

流量为王的时代什么时候能过去？

@StarkWhite #63 我倒觉得跨行其实无所谓，有部分大佬都是跨行而且精通的，我只针对这个项目本身来说，后端提供一个 API ，你让调用方写一大堆逻辑，那调用方不用学习成本吗，我换位思考，我要是写前端你让我调个接口写这么一大堆东西，纯费劲，前端本来就是关注交互+页面呈现效果
再换个角度来说，如果是后端，那他为什么要用这个东西？ mybatis (plus)不香吗

@qwerasdf123 是， 打着“不用对接” 的旗号， 其实挖了个深坑

@tangkikodo #67 是的 懂的自然懂 任何一次小的技术选型 / 方案设计都有可能给后面的迭代埋下坑，何况这么多花样的东西

@qwerasdf123 @tangkikodo 看知乎上的评价，缺点一大堆。。。
https://www.zhihu.com/question/432617493

还是 fb 的 graphql 好用多了

@tangkikodo gql 转换数据可以在 resolver 中写，前端传对应字段就行了

@qwerasdf123 在项目中体验过 gql 之后，得出了这个工具，要用也是应该放在后端代理查询， 用最简洁的形式和前端做沟通。 这样如果请求有性能问题， 后端也有足够的方案来优化， 代替。

以一个个功能明确的 API 的方式， 类似 gql 查询， 但是前端不同提供描述， 如果有 ts sdk 传递类型信息会更好。

如果是 python 后端的话， 推荐一把 pydantic-resolve ，面向前后端一同迭代的场景，通过构建前端恰好可用的视图数据， 让前端专注在展现和交互功能上。

@StarkWhite gql 本身没问题， 问题出在 gql 查询到的字段要转换成前端直接可用的结构， 往往是会有落差的。
因为后端结构相对固定， 但是前端视图数据却是各种天马行空。

如果不是具体专供的 gql 接口的话， 前端做转换的工作量一般都是存在的。
如果是专供接口的话， 那前端重写一遍 query 就有点多余。

这是我使用的一些感受~

@qwerasdf123 我看 ta 之前也就在传音这种不知名小公司待过，难道腾讯的 bar 这么低，靠 apijson 这种水平的开源项目都能进去了吗？

而“前端自己要做数据转换”， 这件事在前后端分离的项目中， 就是容易积累“技术债” 和 “遗留代码” 的地方。

@StarkWhite 传音 不知名小公司？？？？？你是不是搞错了什么。。。

@tangkikodo 复杂度不可能凭空消失，最多只能转移，要么前端处理，要么后端处理，用啥技术都解决不了吧。。。就算是 被作者吹得神乎其神无所不能的 apijson ，我看也还是 “没有银弹”

@sampeng 刚在两个几千人技术群里问了，就没几个人听说过，都不知道是干啥的

话说 gql 可是 twitter, uber, paypal, ebay 等一堆大厂在用
https://graphql.org/users

@StarkWhite 复杂度不能消灭， 只能控制。

从关注点分离的角度， 以及自己的体会来看， 这块复杂度我希望放在后端来管控