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

[QWE321ASD]

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

[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 ，就懒得用