这是一个创建于 265 天前的主题，其中的信息可能已经有所发展或是发生改变。
去 github 看了一下,项目已经维护 6 年多了,使用者也多了起来,但是 issue 和 readme 还是那么抽象... 大家怎么看待这个项目?
95 条回复 • 2024-03-12 12:18:27 +08:00
 |
1
cdlnls 265 天前
感觉能理解呀，推广自己的项目有什么不对呢？谁不喜欢自己开发的程序能让更多人用上呢
|
 |
2
ZSeptember 265 天前
虽然不用，但是确实还是有用的。
以前自己也做过类似的框架，简化 CRUD 。 感觉 lz 不喜欢这个项目，可以先分享你的观点。 |
 |
3
chendy 265 天前  1
本来都忘了这茬了，楼主又给引了个流…
|
 |
4
junmoxiao 265 天前
暴力推荐。。。
|
 |
5
bojackhorseman 265 天前
不是说已经被某个大厂买了吗？
|
 |
6
QWE321ASD OP @ZSeptember 我没有不喜欢这个项目,是他的 issue 区和知乎回答硬引流的方式震撼到我了 https://www.zhihu.com/people/tommylemon 上次有这种震撼感还是我看某个不点 star 不给看文档的项目,还好 apijson 这个项目米线似乎比那个项目高点
|
 |
7
icyalala 265 天前
给人的第一印象就是比椰树椰汁还夸张的广告风格，夸张到离谱了。内容也许是好的，但感官很差。
|
 |
8
adoal 265 天前
魔障
|
 |
9
Track13 265 天前 1
emmm,打开仓库看了一眼，没看懂怎么用。
|
 |
12
zhuangqhc 265 天前
这人是 UC 震惊部出来的吧
|
 |
13
tangkikodo 265 天前
都暴力推荐了， 那就顺带也推荐个后端驱动的 API 构建工具吧~~
肥肠小巧 https://allmonday.github.io/pydantic-resolve/ |
 |
14
dyllen 265 天前
打的牌子是腾讯开源的，很早就看见到处发帖推广了，很多年了。
|
 |
15
StarkWhite 265 天前
江山易改本性难移啊，又想起来以前 v 站上 Ta 舌战群儒的几百条评论，那气势到现在还能让人诚惶诚恐。。。
https://www.v2ex.com/t/568631 |
 |
16
pengpeng1 265 天前
readme 一大堆没啥鸡儿用的玩意，我都怀疑这个人去干传销肯定很成功！！
|
 |
17
v2yllhwa 265 天前 via Android
去看了眼 issue 的推广说 xxx linked APIJson 是看 github traffic 的 referer 有别人的域名，难绷。
|
|
18
StarkWhite 265 天前
@pengpeng1 是程序员里最厉害的传销，还是传销中最厉害的程序员？/滑稽
|
 |
19
BeautifulSoap 265 天前
点进了项目的 Issues 页，存粹的视觉冲击和信息震惊了我半年
|
 |
20
lightattractbugs 265 天前 1
看完 issue 感觉作者魔怔了，建议远离
|
 |
21
cedoo22 265 天前
里面从国内大厂出来最多的是腾讯， 突然觉得 有点合理了， 是怎么回事。。。
 |
|
22
StarkWhite 265 天前
|
 |
23
weijancc 265 天前
看了 issue, 确实很惊人
|
 |
24
hefish 265 天前
这也是我不上逼乎的主要原因，上面太多推广了，明的暗的，防不胜防。
|
 |
25
frankies 265 天前 2
我觉得没什么不好，很多技术人不懂个人品牌营销，不愿去运营推广甚至鄙视推广，这是短视的。国外很多技术一般的开发者虽然技术一般，但天天发视频分享，去发推宣传，这对个人价值增值和职业发展也是很重要的。
|
 |
26
zjp 265 天前 via Android
好奇有腾讯的人现实里见过他是什么样的吗
|
|
27
tangkikodo 265 天前
@frankies 流量为王的时代， 正向口碑和反向口碑， 反正能引流， 吵架也能引流
作者在营销上， 算是豁出去了。 现在前后端分离上很多方案都点歪了科技树， 前端总想多做点业务层的事情， 后端总想给点万能接口... 但实际上， 前端，或者说 UI ， 应该只是业务数据的一种具体实现， 是核心业务的外层 presenter 层， 讲道理就是应该稍作业务逻辑处理相关的事情的。 |
|
28
StarkWhite 265 天前
@v2yllhwa 这个域名 refer 是怎么来的？我看到有不少打了 500 强 标签的国内大厂企业相关 issue ，难道这些企业都用了 apijson ？
|
 |
29
huiyifyj 265 天前
确实有点抽象，这 readme 页面看得就难顶，没想到 issues 页更无语。
|
|
30
tangkikodo 265 天前
apijson 或者 graphql 作为查询层的功能， 放在 client 很容易出现不合适的情况。
个人觉得放到后端或者 bff 层， 保持独立固定的接口， 才能做好总体业务的维护。 |
|
31
StarkWhite 265 天前 1
|
|
32
StarkWhite 265 天前
@Track13 也就是个做增删改查的 orm 库而已，还大吹特吹，mybatis ，hibernate ，prisma ，sequlize 等早就一大堆同类项目了
|
 |
33
lstz 265 天前 via Android
比较让人反感的就是洗脑式输出，而且很多是比较复制粘贴的感觉
但没办法，这套就是很好用 |
|
34
StarkWhite 265 天前
@lstz 今年过年不收礼呀，收礼还收脑白金?
|
|
35
lstz 265 天前 via Android
@StarkWhite 他得到了精髓了属于是 hhh
|
|
36
StarkWhite 265 天前
|
 |
37
Sivan 264 天前 2
|
|
38
v2yllhwa 264 天前 via Android
@StarkWhite 首先这个 referer 可以随便伪造，其次小米某位员工在 lark 文档里面可能贴了一下这个库，有人点开看过，结果就是小米 linked APIJson ，有点太乐了
|
|
39
tangkikodo 264 天前
|
|
40
StarkWhite 264 天前
@v2yllhwa 这怎么伪造？伪造出来的 github 识别不了吗？
|
|
41
StarkWhite 264 天前
@tangkikodo graphql 胜在迭代几乎不用改代码，还是很值得推荐的
|
|
42
StarkWhite 264 天前
@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 |
|
43
tangkikodo 264 天前
@StarkWhite 看迭代的变化程度， 如果是增减字段还是 ok 的， 如果接口要做大变化的话， 我感觉维护 query 也是额外成本。
给 client 一种这么灵活的工具， 有时搞不好会玩出花最后不好维护。 比如本来可以通过一个新接口+过滤来获取的数据，client 为了图方便避免沟通， 走了一个绕路的查询， 而路径长的查询又可能引起性能问题。 |
 |
44
diagnostics 264 天前
你笑别人搞传销，别人笑你不懂“信创”
|
|
45
QWE321ASD OP @StarkWhite 哈哈哈,原来作者被拿下了,我还寻思他怎么没放过 v2ex,原来是 V2EX 没放过他
|
|
46
StarkWhite 264 天前
@cedoo22 有个从腾讯出来的人说，以前在隔壁办公室，经常看到他带几个人去打球，见人都笑呵呵的，还托人带下女同事
|
|
47
StarkWhite 264 天前
还拿了个公司的技术奖，请了整个中心几十个人吃饭
|
|
48
StarkWhite 264 天前 1
@zjp
|
|
49
StarkWhite 264 天前
@tangkikodo 社区早就有一堆代码生成器了，这个影响不大，而且如果都是 js/ts ，前后端都可以共用的
|
 |
50
shixuedela 264 天前
看到这个人，突然想起了鱼皮。两个人当时不会在 TX 有交流把？
|
|
51
tangkikodo 264 天前
@StarkWhite 确实，追写生成器帮助下，这个还是好解决的。
我感觉疼的还是 client 整的查询比较魔幻的时候的性能问题。 约等于丢失了慢查询的调优空间。 |
|
52
StarkWhite 264 天前
@shixuedela 腾讯高级布道师鱼皮？好像还帮忙推广过 apijson
|
|
53
StarkWhite 264 天前
@tangkikodo n+1 问题，可以用 dataloader 解决，还有 join-monster 这类 graphql 相关库也可以试试
|
 |
54
putyy 264 天前
666
|
|
55
tangkikodo 264 天前
@StarkWhite 说到 n+1 和 dataloader 感觉现有的 在 context 里面集中初始化的写法，维护起来稍嫌麻烦， 不能放开手脚随便定义
|
|
56
StarkWhite 264 天前
|
|
57
StarkWhite 264 天前
@icyalala 椰树椰汁可真会请模特，看起来得有 E 罩杯了吧 😂
|
|
58
tangkikodo 264 天前
@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 } } 当然，这些是属于某种深水区的使用困扰 :< |
|
59
tangkikodo 264 天前
@StarkWhite
fix ```graphql query { MyBlogSite { name blogs { id title comments { id content } comment_count # comments count for blog } comment_count # total comments } } ``` |
 |
60
anoyi 264 天前
看了这么啰嗦的 README ，就懒得用
|
 |
61
qwerasdf123 264 天前
哈哈哈哈作者是之前传音的同事，他当时的岗位就是写安卓客户端的，当时刚出来的时候在公司推广，我们一堆后端就在说这玩意咋用，谁愿意开放底层的权限给你，没想到今年刷到 16k+ start 了，这玩意正经人谁用啊。。
|
|
63
StarkWhite 264 天前
@qwerasdf123 原来就一个写安卓的，这属于是强行跨领域外行指导内行了吧，瞎搞什么后端 😂
|
 |
64
churchmice 264 天前
what is the jb 玩意
|
 |
65
wukaige 264 天前
流量为王的时代什么时候能过去？
|
|
66
qwerasdf123 264 天前
@StarkWhite #63 我倒觉得跨行其实无所谓，有部分大佬都是跨行而且精通的，我只针对这个项目本身来说，后端提供一个 API ，你让调用方写一大堆逻辑，那调用方不用学习成本吗，我换位思考，我要是写前端你让我调个接口写这么一大堆东西，纯费劲，前端本来就是关注交互+页面呈现效果
再换个角度来说，如果是后端，那他为什么要用这个东西？ mybatis (plus)不香吗 |
|
67
tangkikodo 264 天前
@qwerasdf123 是， 打着“不用对接” 的旗号， 其实挖了个深坑
|
|
68
qwerasdf123 264 天前
@tangkikodo #67 是的 懂的自然懂 任何一次小的技术选型 / 方案设计都有可能给后面的迭代埋下坑，何况这么多花样的东西
|
|
69
StarkWhite 264 天前
|
|
70
StarkWhite 264 天前
还是 fb 的 graphql 好用多了
|
|
71
StarkWhite 264 天前
@tangkikodo gql 转换数据可以在 resolver 中写，前端传对应字段就行了
|
|
72
tangkikodo 264 天前 1
@qwerasdf123 在项目中体验过 gql 之后，得出了这个工具，要用也是应该放在后端代理查询， 用最简洁的形式和前端做沟通。 这样如果请求有性能问题， 后端也有足够的方案来优化， 代替。
以一个个功能明确的 API 的方式， 类似 gql 查询， 但是前端不同提供描述， 如果有 ts sdk 传递类型信息会更好。 如果是 python 后端的话， 推荐一把 pydantic-resolve ，面向前后端一同迭代的场景，通过构建前端恰好可用的视图数据， 让前端专注在展现和交互功能上。 |
|
73
tangkikodo 264 天前
@StarkWhite gql 本身没问题， 问题出在 gql 查询到的字段要转换成前端直接可用的结构， 往往是会有落差的。
因为后端结构相对固定， 但是前端视图数据却是各种天马行空。 如果不是具体专供的 gql 接口的话， 前端做转换的工作量一般都是存在的。 如果是专供接口的话， 那前端重写一遍 query 就有点多余。 这是我使用的一些感受~ |
|
74
StarkWhite 264 天前
@qwerasdf123 我看 ta 之前也就在传音这种不知名小公司待过，难道腾讯的 bar 这么低，靠 apijson 这种水平的开源项目都能进去了吗？
|
|
75
tangkikodo 264 天前
而“前端自己要做数据转换”， 这件事在前后端分离的项目中， 就是容易积累“技术债” 和 “遗留代码” 的地方。
|
 |
76
sampeng 264 天前
@StarkWhite 传音 不知名小公司？？？？？你是不是搞错了什么。。。
|
|
77
StarkWhite 264 天前
@tangkikodo 复杂度不可能凭空消失，最多只能转移，要么前端处理，要么后端处理，用啥技术都解决不了吧。。。就算是 被作者吹得神乎其神无所不能的 apijson ，我看也还是 “没有银弹”
|
|
78
StarkWhite 264 天前
@sampeng 刚在两个几千人技术群里问了，就没几个人听说过，都不知道是干啥的
|
|
79
StarkWhite 264 天前
话说 gql 可是 twitter, uber, paypal, ebay 等一堆大厂在用
https://graphql.org/users |
|
80
tangkikodo 264 天前
|
 |
81
Rorysky 264 天前
我就找到 性别写成 sex 这个槽点
这项目确实隔靴搔痒 |
 |
82
AndyZhuAZ 264 天前
没看懂这个项目在做什么😂
|
|
83
StarkWhite 264 天前
@tangkikodo 那就是后端通过 resolver 内部实现业务逻辑了
|
|
84
StarkWhite 264 天前
@anoyi 都不用看 readme ，光是 国产 这个点就可以毙了
|
 |
85
Pony69 264 天前
有点意思
|
 |
86
WindProtect 264 天前
KPI 考核了吧。。。
|
|
87
qwerasdf123 264 天前
@StarkWhite #78 传音做非洲、印度市场的，市值千亿左右，不过国内确实少听说，在深圳的应该大部分都知道
|
|
88
qwerasdf123 264 天前
@StarkWhite #69
这个 issue ，给人一种没有没有功劳也有苦劳的感觉，作者一页页截 Stargazers 怪累的 https://github.com/Tencent/APIJSON/issues/197 |
 |
89
moonvstod 264 天前
@StarkWhite #78 全球前五的手机商，主要做非洲市场
|
|
90
StarkWhite 264 天前
|
|
91
tangkikodo 264 天前
@qwerasdf123 这份执着也真的只能佩服
|
|
92
StarkWhite 264 天前
@qwerasdf123 我也是纳闷，谁点赞了收藏了这种数据也能放在首页介绍里？
https://github.com/Tencent/APIJSON#%E7%BB%9F%E8%AE%A1%E5%88%86%E6%9E%90 |
|
93
StarkWhite 264 天前
@WindProtect 这还真有可能，以前看到过有些大厂开源点 star 发红包送礼的。。。
|
|
94
StarkWhite 264 天前
|
|
95
StarkWhite 264 天前
@diagnostics 听说近几年有很多打着 “信创” 的名头坑蒙拐骗拿 zf 经费的
|
Select Language