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

[QWE321ASD]

去 github 看了一下,项目已经维护 6 年多了,使用者也多了起来,但是 issue 和 readme 还是那么抽象... 大家怎么看待这个项目?

[cdlnls]

感觉能理解呀，推广自己的项目有什么不对呢？谁不喜欢自己开发的程序能让更多人用上呢

[ZSeptember]

虽然不用，但是确实还是有用的。
以前自己也做过类似的框架，简化 CRUD 。
感觉 lz 不喜欢这个项目，可以先分享你的观点。

[chendy]

本来都忘了这茬了，楼主又给引了个流…

[junmoxiao]

暴力推荐。。。

[bojackhorseman]

不是说已经被某个大厂买了吗？

[QWE321ASD]

@ZSeptember 我没有不喜欢这个项目,是他的 issue 区和知乎回答硬引流的方式震撼到我了 https://www.zhihu.com/people/tommylemon 上次有这种震撼感还是我看某个不点 star 不给看文档的项目,还好 apijson 这个项目米线似乎比那个项目高点

[icyalala]

给人的第一印象就是比椰树椰汁还夸张的广告风格，夸张到离谱了。内容也许是好的，但感官很差。

[adoal]

魔障

[Track13]

emmm,打开仓库看了一眼，没看懂怎么用。

[QWE321ASD]

@chendy 哈哈,我发帖前也想过这个事,但是他应该属于成功到不需要黑流量了...

[QWE321ASD]

@cdlnls 前 10 个 issue 里有 8 个是推广...这力度是否有点...

[zhuangqhc]

这人是 UC 震惊部出来的吧

[tangkikodo]

都暴力推荐了， 那就顺带也推荐个后端驱动的 API 构建工具吧~~
肥肠小巧 https://allmonday.github.io/pydantic-resolve/

[dyllen]

打的牌子是腾讯开源的，很早就看见到处发帖推广了，很多年了。

[StarkWhite]

江山易改本性难移啊，又想起来以前 v 站上 Ta 舌战群儒的几百条评论，那气势到现在还能让人诚惶诚恐。。。
https://www.v2ex.com/t/568631

[pengpeng1]

readme 一大堆没啥鸡儿用的玩意，我都怀疑这个人去干传销肯定很成功！！

[v2yllhwa]

去看了眼 issue 的推广说 xxx linked APIJson 是看 github traffic 的 referer 有别人的域名，难绷。

[StarkWhite]

@pengpeng1 是程序员里最厉害的传销，还是传销中最厉害的程序员？/滑稽

[BeautifulSoap]

点进了项目的 Issues 页，存粹的视觉冲击和信息震惊了我半年

[lightattractbugs]

看完 issue 感觉作者魔怔了，建议远离

[dr1q65MfKFKHnJr6]

里面从国内大厂出来最多的是腾讯， 突然觉得 有点合理了， 是怎么回事。。。

[StarkWhite]

@bojackhorseman 据说连人带项目被腾讯收了
https://www.v2ex.com/t/843391

[weijancc]

看了 issue, 确实很惊人

[hefish]

这也是我不上逼乎的主要原因，上面太多推广了，明的暗的，防不胜防。

[frankies]

我觉得没什么不好，很多技术人不懂个人品牌营销，不愿去运营推广甚至鄙视推广，这是短视的。国外很多技术一般的开发者虽然技术一般，但天天发视频分享，去发推宣传，这对个人价值增值和职业发展也是很重要的。

[zjp]

好奇有腾讯的人现实里见过他是什么样的吗

[tangkikodo]

@frankies 流量为王的时代， 正向口碑和反向口碑， 反正能引流， 吵架也能引流
作者在营销上， 算是豁出去了。

现在前后端分离上很多方案都点歪了科技树， 前端总想多做点业务层的事情， 后端总想给点万能接口...

但实际上， 前端，或者说 UI ， 应该只是业务数据的一种具体实现， 是核心业务的外层 presenter 层， 讲道理就是应该稍作业务逻辑处理相关的事情的。

[StarkWhite]

@v2yllhwa 这个域名 refer 是怎么来的？我看到有不少打了 500 强 标签的国内大厂企业相关 issue ，难道这些企业都用了 apijson ？

[huiyifyj]

确实有点抽象，这 readme 页面看得就难顶，没想到 issues 页更无语。

[tangkikodo]

apijson 或者 graphql 作为查询层的功能， 放在 client 很容易出现不合适的情况。

个人觉得放到后端或者 bff 层， 保持独立固定的接口， 才能做好总体业务的维护。

[StarkWhite]

@tangkikodo 终于有人提到 facebook 的 gql 啦，这不比什么 apijson 强多了？
https://www.v2ex.com/t/589138

[StarkWhite]

@Track13 也就是个做增删改查的 orm 库而已，还大吹特吹，mybatis ，hibernate ，prisma ，sequlize 等早就一大堆同类项目了

[lstz]

比较让人反感的就是洗脑式输出，而且很多是比较复制粘贴的感觉

但没办法，这套就是很好用

[StarkWhite]

@lstz 今年过年不收礼呀，收礼还收脑白金?

[lstz]

@StarkWhite 他得到了精髓了属于是 hhh

[StarkWhite]

@zjp 网上有 ta 的视频，人长得还凑和吧，不丑。。。
https://space.bilibili.com/437134249

[Sivan]

https://github.com/Tencent/APIJSON/issues/678
https://github.com/Tencent/APIJSON/issues/675
https://github.com/Tencent/APIJSON/issues/671
https://github.com/Tencent/APIJSON/issues/677

我 TM 直呼离谱…

[v2yllhwa]

@StarkWhite 首先这个 referer 可以随便伪造，其次小米某位员工在 lark 文档里面可能贴了一下这个库，有人点开看过，结果就是小米 linked APIJson ，有点太乐了

[tangkikodo]

@StarkWhite gql 社区资源是真的丰富

不过 gql 拿来给 client 提供 api 是会有点问题的， 除非是 api 先行， 开发完了也不用调整的这种项目。

否则迭代也会疼

[StarkWhite]

@v2yllhwa 这怎么伪造？伪造出来的 github 识别不了吗？

[StarkWhite]

@tangkikodo graphql 胜在迭代几乎不用改代码，还是很值得推荐的

[StarkWhite]

@Sivan 我点了一个标签，发现了更多类似 issue ，真不知道作者是怎么搞到这些信息的 。。。
[Baidu 百度] [500 强] GitHub 官方主页链接了 APIJSON
[McDonald's 麦当劳] [500 强] 餐饮巨头内网链接了 apijson-framework
[CHINA TELECOM 中国电信] [500 强] 天翼云申请了 APIJSON 相关发明专利
[FE 飞企互联] 上市公司飞企互联的凌云中台集成了 APIJSON 并提供了在线文档
[Job] WP-Buddy 在印度招聘岗位要求了解 APIJSON

https://github.com/Tencent/APIJSON/issues?q=is%3Aissue+is%3Aopen+label%3A%22Popularize+%E5%AE%A3%E4%BC%A0%2F%E6%8E%A8%E5%B9%BF%2F%E5%B8%83%E9%81%93%22

[tangkikodo]

@StarkWhite 看迭代的变化程度， 如果是增减字段还是 ok 的， 如果接口要做大变化的话， 我感觉维护 query 也是额外成本。

给 client 一种这么灵活的工具， 有时搞不好会玩出花最后不好维护。 比如本来可以通过一个新接口+过滤来获取的数据，client 为了图方便避免沟通， 走了一个绕路的查询， 而路径长的查询又可能引起性能问题。

[diagnostics]

你笑别人搞传销，别人笑你不懂“信创”

[QWE321ASD]

@StarkWhite 哈哈哈,原来作者被拿下了,我还寻思他怎么没放过 v2ex,原来是 V2EX 没放过他

[StarkWhite]

@cedoo22 有个从腾讯出来的人说，以前在隔壁办公室，经常看到他带几个人去打球，见人都笑呵呵的，还托人带下女同事

[StarkWhite]

还拿了个公司的技术奖，请了整个中心几十个人吃饭

[StarkWhite]

@zjp

[StarkWhite]

@tangkikodo 社区早就有一堆代码生成器了，这个影响不大，而且如果都是 js/ts ，前后端都可以共用的

[shixuedela]

看到这个人，突然想起了鱼皮。两个人当时不会在 TX 有交流把？

[tangkikodo]

@StarkWhite 确实，追写生成器帮助下，这个还是好解决的。
我感觉疼的还是 client 整的查询比较魔幻的时候的性能问题。 约等于丢失了慢查询的调优空间。

[StarkWhite]

@shixuedela 腾讯高级布道师鱼皮？好像还帮忙推广过 apijson

[StarkWhite]

@tangkikodo n+1 问题，可以用 dataloader 解决，还有 join-monster 这类 graphql 相关库也可以试试

[putyy]

666

[tangkikodo]

@StarkWhite 说到 n+1 和 dataloader 感觉现有的 在 context 里面集中初始化的写法，维护起来稍嫌麻烦， 不能放开手脚随便定义

[StarkWhite]

@tangkikodo 这个支持 sql join ，比 dataloader 还要强大
https://github.com/join-monster/join-monster

[StarkWhite]

@icyalala 椰树椰汁可真会请模特，看起来得有 E 罩杯了吧 😂

[tangkikodo]

@StarkWhite 两个都挺重要，sql join 负责 db 的查询，dataloader 负责 db 或者 其他远程调用。

这个 join-monster 看起来和 https://postgraphile.org/ 之类的概念很像， 从 gql 查询调用 db 查询

可是。。这不太适合直接给 client 用的， 太灵活了， 自己的项目用用倒是可以简化一些步骤。

graphql 对前端有个小麻烦，就是遇到数据层级聚合的场景， 前端要么依赖 gql-lodash, 要么自己手动拆了算。

感觉问题的本质还是，gql 或者 apijson 或者 orm 这些都是负责一层层找到数据， 不负责数据后续转换。

比如获取完数据之后做点后处理， 计算全部每个 blog comment 数量， 或者 site 所有 comment 数量

这种 gql 内部做的话， 相当于整个 node 要全部预计算完了。

query {
MyBlogSite {
name
blogs {
id
title
comments {
id
content
}
comment_count # comments count for blog
}
comment_count # total comments
}
}

当然，这些是属于某种深水区的使用困扰 :<

[tangkikodo]

@StarkWhite

fix

```graphql
query {
MyBlogSite {
name
blogs {
id
title
comments {
id
content
}
comment_count # comments count for blog
}
comment_count # total comments
}
}
```

[anoyi]

看了这么啰嗦的 README ，就懒得用

[qwerasdf123]

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

[42is42is42]

https://cn.linkedin.com/in/tommylemon

[StarkWhite]

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

[churchmice]

what is the jb 玩意

[wukaige]

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

[qwerasdf123]

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

[tangkikodo]

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

[qwerasdf123]

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

[StarkWhite]

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

[StarkWhite]

还是 fb 的 graphql 好用多了

[StarkWhite]

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

[tangkikodo]

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

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

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

[tangkikodo]

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

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

这是我使用的一些感受~

[StarkWhite]

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

[tangkikodo]

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

[sampeng]

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

[StarkWhite]

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

[StarkWhite]

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

[StarkWhite]

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

[tangkikodo]

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

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

[Rorysky]

我就找到 性别写成 sex 这个槽点

这项目确实隔靴搔痒

[AndyZhuAZ]

没看懂这个项目在做什么😂

[StarkWhite]

@tangkikodo 那就是后端通过 resolver 内部实现业务逻辑了

[StarkWhite]

@anoyi 都不用看 readme ，光是 国产 这个点就可以毙了

[Pony69]

有点意思

[WindProtect]

KPI 考核了吧。。。

[qwerasdf123]

@StarkWhite #78 传音做非洲、印度市场的，市值千亿左右，不过国内确实少听说，在深圳的应该大部分都知道

[qwerasdf123]

@StarkWhite #69
这个 issue ，给人一种没有没有功劳也有苦劳的感觉，作者一页页截 Stargazers 怪累的
https://github.com/Tencent/APIJSON/issues/197

[moonvstod]

@StarkWhite #78 全球前五的手机商，主要做非洲市场

[StarkWhite]

@qwerasdf123 @sampeng @moonvstod 不好意思，我是见识少了，查了下确实是比较大的手机厂

[tangkikodo]

@qwerasdf123 这份执着也真的只能佩服

[StarkWhite]

@qwerasdf123 我也是纳闷，谁点赞了收藏了这种数据也能放在首页介绍里？
https://github.com/Tencent/APIJSON#%E7%BB%9F%E8%AE%A1%E5%88%86%E6%9E%90

[StarkWhite]

@WindProtect 这还真有可能，以前看到过有些大厂开源点 star 发红包送礼的。。。

[StarkWhite]

@dyllen 这项目以前不是腾讯的，之前在 v 站暴力推广了好几年，哪哪都有 ta
https://www.v2ex.com/t/728299

[StarkWhite]

@diagnostics 听说近几年有很多打着 “信创” 的名头坑蒙拐骗拿 zf 经费的