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