APIJSON 3.2.0 发布， 4K Star 与 Hibernate 拉开差距

声明：
根据以往的发帖情况来看，由于时间和精力的限制，没法一一回复，但保证一定回复前 20 的评论（不包括自己的）。
在 V2EX 这样一个技术交流平台，欢迎大家开诚布公地探讨交流，请勿发泄情绪污染氛围。
如果我有哪些地方违反了 法律法规 或者 平台的规则，敬请指正，谢谢！

这个点赞

@shell314 感谢

"请勿发泄情绪污染氛围"，现在大家发分享贴都会带着这句了

这个帖子应该发布到“分享创造”，go/create

这个框架的意思是能够前端直接定义 API 对数据库的增删改查并且返回自定义的 json 数据结构，可以这样理解吗？

不错，赞。请教一下楼主长度如何校验的？ long 型，长度 15，可我输入的是字符串，长度不止 15，也没什么提示，返回值也是 200

文案比之前理性些了

支持开源，但是不支持以这样的标题发帖，也不赞同用 star 来作比较。如果要比较，建议比较一下贡献人数，单元测试完善度，文档完善度等等。

厉害 必须点赞

如果业务逻辑能让自己前端自行组织的话，那还要后端干嘛。
直接客户端连远程数据库完事了。

不要因为自己团队后端不给力，就自己想越界去搞后端的事。
复杂的后端业务不只是增删改查。

@liuxu 感谢，虽然和 程序员 话题相关，但确实放到 分享创造 话题下更合适

@TommyLemon 时间过了，管理功能只剩 “下沉 1 天”，没有改主题的入口了

@Neojoke 对的，不过中间会经过 Server 的权限、数据、结构、语法 等校验，Server 还会通过 预编译、白名单 等方式自动防 SQL 注入，保证安全性。

@pryhub 感谢反馈，初步断定这是一个 bug，fastjson 解析 json 时 getLongValue 得到一个负数值（超过 long 上限）导致查不到结果。查不到结果是对的，但其实应该直接返回一个错误码和错误信息，方便调试。
至于长度，数据库表字段配置的由数据库校验，如果是 Request 表里配置了对应的校验规则，则由 Server 代码校验。

@TommyLemon 数据字典文档的长度等属性是从数据库查的

@sagaxu 哈哈，我也在反思和总结

不是很了解,但是和 GraphQL 相比有什么特点吗?

@airyland 这个帖子主要是让大家看内容的，标题只是吸引阅读（当然是基于事实，没有虚假或夸大成分，和标题党不一样）。
提交代码次数 commits， 发版次数 releases， 贡献人数 contributors 都在第 2 张截图里了，都和 Hibernate 有大的差距。
单元测试完善度，文档完善度 没仔细对比过，粗略看也是比不上的，
但 APIJSON 现在也有比较完善的测试(自动化接口回归测试，提供机器学习版)和 文档（通用文档、部署文档、群里的详细入门文档等）。
目前只有 Star （一定程度上反映 Repo 在开源社区的被关注程度）这个指标确定是超过 Hibernate 的。

@fkdog APIJSON 提供 远程函数 来给后端扩展业务逻辑。
大部分接口开发中，提取参数、增删改查、封装返回 JSON
这几个步骤要写 Controller，Service，Dao，Mapper 等一堆代码，
APIJSON 的自动化 API 可以替代这些，大幅降低后端的开发工作量，
还能让前端灵活定制自己需要的数据和结构，减少和后端的沟通成本，提高开发效率。

如果是客户端直连数据库，安全性怎么保证呢？
APIJSON 是提供了自动化的权限管理、自动防 SQL 注入的。

后端业务当然不只增删改查，APIJSON 又不是啥都干，主页文档已经说明了它的适用范围。

APIJSON vs GraphQL，详细对比了 基础功能、权限控制、表关联查询 等
juejin.im/post/5ae80edd51882567277433cf

@TommyLemon #14 "数据库表字段配置的由数据库校验"
只由数据库校验？我理解的校验顺序是：1.前台要校验 2.后台逻辑代码校验 3.db 校验

@pryhub 你理解的校验顺序很对，基本上都是这么一个流程。
"数据库表字段“ 配置的由 ”数据库校验"，这句话也没错啊，就是第 3 个 db 校验。
前台校验是为了减少不必要的请求，后台逻辑代码校验是业务上的校验，可以自定义一些异常信息等。

比 start 没有意义

怎么没看明白。。。啥意思？

文档看了半天没有发现如何使用。。。

我怎么觉得和 swagger 挺像的，都是做 API 管理的，我感觉 swagger 挺好用的啊，搭起来也方便。能做这么大一个 open source 的 repo，lz 牛逼。

@lihongjie0209 Star 在一定程度上反映了 Repo 在开源社区的受欢迎程度，同类型的 Repo （ APIJSON 和 Hibernate 都是 ORM 库）对比是有参考意义的

@jingyulong
如果是前端使用，直接用这个网站，还可以看通用文档或视频教程（网站顶部有链接）
http://apijson.org/

如果是后端部署，看这个部署文档
https://github.com/TommyLemon/APIJSON/tree/master/APIJSON-Java-Server

@liyuanba
和 Swagger 像的是 APIJSONAuto 哈，这是一个接口管理工具。
https://github.com/TommyLemon/APIJSON/issues/27

APIJSON 主项目包括 协议、Java 版 ORM 库及 Demo，Android, iOS, Javascript 的 Demo 等

以前还会迷信 star 数，现在我更看重 issue 数量，数量多，修复快，说明用的人多

@liuhuansir
Hibernate 的 issue 多到官方都关闭 issue 了，现在没法看。
https://github.com/hibernate/hibernate-orm

issue 的确反映了用户的数量及频率，但太多了也可能是 bug 太多，
issue/star <= 10% 是可接受的，> 20% 我一般找别的同类库了，找不到合适的可能基于现有的定制或干脆自己写。

关于 GitHub 的 issue
1.issue 是一个公开的讨论区，可以发任何东西。
2.大部分 issue 都是 提交 bug、提建议、提问题（如何使用 XXX，怎么添加 XXX，有没有文档 等），还有些是灌水、发泄 等。
3.issue 的数量和 Repo 的 受关注程度、使用频率、用户群体、Repo 本身的代码与文档质量 等相关。

APIJSON 提供了自动化 API，只有配置权限需要写极少的代码，加上详细的文档、视频教程、测试工具，
已经做到非常简单易用了，所以很少有问“怎样配置 XXX ”，“如何部署 XXX ”之类的问题。

APIJSON 经过 2 年时间维护、1000+次 Commit、40+ 次 Release， 功能上已经很完善、稳定，
所以也很少有用户问“如何解决 XXX ”之类的问题。

还有 APIJSON 目前大部分用户都是 国内的开发者，他们更倾向于在首页提供的 QQ 群交流和讨论。

https://github.com/TommyLemon/APIJSON/issues/53

好像很厉害的样子，看看。

@loading 哈哈，试试发现可能比想象的还好用
https://github.com/TommyLemon/APIJSON/issues/17

粗略的看了一下文档，虽然没看懂但是还是有个疑问：数据都是由前端自由组合来获取的，目测是比较粗粒度权限控制，那么会不会存在 C 端任意构造访问参数获取到本应授权访问的数据？还是说能够做到参数条件的完全可控（就像我们手写的 api 一样，一个接口进行了什么样的查询都是我们说了算）？

@xiangyuecn
权限由后端控制，粒度细分到 每种角色、每种操作、每张表、每条记录，所以并不会出现越权访问的问题。
非开放请求（增删改，限制性查询）由后端控制参数 JSON 的数据和结构，所以非开放请求是后端说了算。

至于 开放请求（ get 查数据，head 统计数量），返回 JSON 的数据和结构都是前端说了算。

需要事务 或 对安全性要求高 的用 非开放请求，其它用开放请求。
https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.1

比 star 数....
感觉跟 hibernate 还是没得比...

@pexcn
Star 早就超过了，怎么没得比呢？上面的截图你不信的话可以 GitHub 上分别看下 APIJSON 和 Hibernate 的。

APIJSON 是增量更新，只更新传过来的非 null 字段；
github.com/TommyLemon/APIJSON/blob/master/Document.md#3.1

Hibernate 默认全量更新，需要麻烦的配置才能实现增量更新
blog.csdn.net/u012038649/article/details/52587404/


APIJSON 关联查询非常容易实现，
还支持自动化 JOIN，包括 LEFT JOIN, INNER JOIN 等 SQL JOIN，
还有可跨数据库的应用层联表 APP JOIN，
全都不用后端写代码，前端传对对应的参数即可。
github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2

比 Hibernate 注解 @OneToMany, @ManyToOne 等 或 写 HQL 好用很多
blog.csdn.net/kd_bright/article/details/79528818

看着不错。有考虑支持 mongodb

我觉得你对 API 有误解…我们公司对于 API 的定义就是精确接口调用，类似 DRY 原则，一个接口只干一个接口的事。按你这样设计我任何接口都可以强行拼接在一个 API 里面。API 设计出来就是让其他人用的，你这套设计我感觉只是自己方便而已，别人调用还要学习成本。我要自己方便我完全可以一个 model 直接生成服务端客户端代码，总之感觉还是一个挺鸡肋的东西… star 数不能说明什么，我记得有个 go web 教程有 2w7 star …

支持国产开源项目

c# 用你这玩意干啥啊 放着 EntityFramework 不用？ EF 不知道牛逼多少

@blless 他这个和 graphql 有些类似，主要想覆盖那些雷同重复的 CRUD 接口

@br00k MongoDB 语法和 MySQL 差异太大了，暂时不打算支持哦，先专注于 MySQL，PostgreSQL，Oracle 等关系型数据库，最近新增了 TiDB 的支持。
https://github.com/TommyLemon/APIJSON/commit/d8583de029e79bf47586d96d99ba21305098ddb0

支持，很不错的项目

一开始还以为是 swagger 的同类产品....深入理解发现原来是提供给前端自动生成 API....感觉用处不大.没想到是有什么人群在使用..

之前看过这个但真的为什么前端的痛点要让后端来做大量的改造。而且就像前面楼上说的实际生成环境的业务场景并不是简单地增删改。安全性还不是要后端做大量配合、大量并发的时候怎么办、类似 dubbo 调用数据在另一个服务器的情况也让后端配合你们改造？不要总想着越界前端做前端的后端做后端的

@Livid 麻烦移动到 推广节点

@Terry05 感谢

@diggerdu 感谢

@somnus
应该是给那些不想看 DTO 文档的前端，去自己弄明白表结构和业务逻辑顺带帮后端把简单的 CRUD 做了的前端
建议普及，这样后端就不需要做那些很无聊的 CRUD 啦 hhhhhhh
果然开发圈子里总有人能找出很多奇奇怪怪的需求呢

@blless 有关联的操作怎么就是强行放一个 API ？
你看下 微信好友详情界面，一个用户信息 + 最近发布的动态，按照传统 RESTful 方式，就是提供
GET /user?id=1
GET /moment/list?userId=1
两个接口，前端要调用两次，渲染界面也是两次。
这个还好，能并行请求，如果是需要 从前面的接口取出返回值 作为下一个接口的参数，
例如查评论列表，如果先
GET /comment/id=1
查出 comemnt 里的 userId = 1，然后回调里再调用
GET /user?id=1

代码很容易写成这种这样
```js
axios.get("/comment/id=1")
.then(function (response) {
console.log(response);

var userId = (response && response.data && response.data.data) ? response.data.data.userId
if (userId == null) {
console.log('axios.get("/comment/id=1").then userId == null >> return');
return
}
axios.get("/user/id=" + userId)
.then(function (response) {
console.log(response);
//TODO 渲染界面
})
.catch(function (error) {
// handle error
console.log(error);
})
})
.catch(function (error) {
// handle error
console.log(error);
})
```
如果是 Android 或 iOS 代码，那就更麻烦了。

至于你说的
“我要自己方便我完全可以一个 model 直接生成服务端客户端代码”
然后呢？这种只能生成简单的单表增删改查 API 的代码，能直接满足需求了？
多表关联查询怎么办？模糊搜索、分组排序 都生成了？
还不是要改，后面需求改了还不是要改后端代码或新增接口？

APIJSON Server 不生成任何静态代码，只生成动态的 SQL 语句，
前端改了 JSON 参数，后端就生成新的 SQL 语句， 满足新的需求，
不需要后端写任何代码来实现上面的说 模糊搜索、分组排序 等，
还有自动化 JOIN 也不需要后端写代码：
```js
{
"[]": {
"count": 10, // LIMIT 10
"join": "</User/id@", // Comment LEFT JOIN User
"Comment": {
"content~": "a", // content REGEXP 'a'
"@group": "momentId", //GROUP BY momentId
"@order": "date+" //ORDER BY date ASC
},
"User": {
"@column":"id,name", // SELECT id,name
"id@": "/Comment/userId" // ON User.id = Comment.userId
}
}
}
```
APIJSONLibrary 生成
```sql
SELECT `Comment`.*, `User`.`id`, `User`.`name` FROM `sys`.`Comment` AS `Comment` WHERE `Comment`.`content` REGEXP 'a'
LEFT JOIN (SELECT `id`, `name` FROM `sys`.`apijson_user`) AS `User` ON `User`.`id` = `Comment`.`userId`
GROUP BY `Comment`.`momentId` ORDER BY `Comment`.`date` ASC LIMIT 10 OFFSET 0
```
来，你介绍个其它的工具，能生成这样比较复杂的 SQL，让大家都见识见识。

“ star 数不能说明什么，我记得有个 go web 教程有 2w7 star …”
再次强调：
Star 在一定程度上反映了 Repo 在开源社区的受欢迎程度，同类型的 Repo （ APIJSON 和 Hibernate 都是 ORM 库）对比是有参考意义的。
“教程”，工具集合，AwesomeXX 库集合 这种大而全的项目，
本身就容易获得 Star，很多人都觉得收藏起来万一里面有东西可以用上，
反而是专注于解决某个场景的问题的一些库，除非有 名企 或 名人 光环，否则 Star 就相对难获得很多，
Hibernate 快 12 年了不也才 3.5 K Star 嘛，难道它的技术价值，使用率比不上你说的那个“ go web 教程”？
不同类型的项目拿到一起对比才基本没有参考价值。

@TommyLemon 有出错误，“教程” 一般不属于 大而全的项目，它的 Star 数往往和对应的 语言 /开源库 的热度有很大关系，Go 现在火得很，Star 多太正常了。几年前我一个同事翻译了 Swift 的文档，短短几个月就有好几千 Star 了。

@TommyLemon 至于学习成本，哪个开源库没有学习成本？你不看文档，不看例子等，直接就拿来用了？
APIJSON 简单易用，提供了丰富的文档、Demo、视频等，还有在线接口工具
apijson.org

首先 ，真的，楼主做这个很厉害 ！但是对于小企业来说有点用，但是对于类似于为服务这种或者业务逻辑复杂的项目来说 实用性并不大。然 git star 之前一方面是能展示受欢迎程度 ，但是现在 star 的水分已经很多了 麻烦楼主不要和 hibernate 比，使用 hibernate 的项目已经不计其数了！至于 star，我想没几个人用到 hibernate 还去 git 上面 star 一下吧！我觉得给出一个数据，比如使用 aoijson 的项目超过 hibernate 的项目多多少，这对我来说才是一个参考。最后，我觉得现在这个开源项目已经成为一个商业推广项目，而背离了开源的初衷!对了，为什么 issue 多就是 bug 多，bug 多是问题么？我觉得推广自己可以，不要这么伤害 hibernate 可以么？总之：用的人越多，项目的价值才越大。勿喷！个人想法！

和 hibernate 不比年代不比地位不比身经百战度，单拿星数当“参考价值”

你是作者你开心就好，也请理解不是所有人都吃这样的宣传

Hibernate 可没来过 v2 拉 star

@knightdf
我在很多评论和回复里都承认了 Hibernate 的历史地位，尤其还说明了它“是 Java 第 2 大 ORM 库”。

V2EX 又不是国外网站，Hibernate 团队不在这里发帖有什么奇怪的？
APIJSON 也没在 Twitter 和 Facebook 推广过
https://twitter.com/Hibernate
https://www.facebook.com/HibernateORM


jackson 主页
https://github.com/FasterXML/jackson
底部有对比其它 JSON 库的链接
https://dzone.com/articles/be-lazy-productive-android

Vue 对比其它框架
https://cn.vuejs.org/v2/guide/comparison.html#React

Tinker 对比其它热更新库
https://github.com/Tencent/tinker/wiki

对比已有的热门库是国内外都很普遍的做法，而且有时候不是作者一开始想要对比，而是一堆人说
“我为啥不用 XXX ”，“和 XXX 相比有什么优势？”，“和 XXX 很像”，“不就是 XXX 么？”...
作者为了消除误解，反对不经思考或验证随意说出来贬低自己项目的声音，有什么不可以吗？

@TommyLemon 另外现在确实有些库的 Star 很水，作假行为扰乱公平性，把社区搞得乌烟瘴气，
不过 求 Star 和 刷 Star 是有 真实 与 作假 的 本质区别的
https://www.zhihu.com/question/66587533/answer/244148558

至于 APIJSON 的 Star 的真实性，可以看趋势图
https://www.timqian.com/star-history/#TommyLemon/Android-ZBLibrary&TommyLemon/APIJSON
或者点 Star 的用户（基本没有三无账号），分别填 TommyLemon APIJSON
https://haochuan9421.github.io/stargazers/

@TommyLemon 三无账号是指 无非随机头像、无非随机用户名、无 repo

//-------------------------------------------------------------------------------------
20 个评论已满，后面的评论不再回复，前面剩下的看时间一个个回复。
//-------------------------------------------------------------------------------------

单纯的 reply #51
8102 年了，async/await 了解一下。

1. 后端查询条件规则，比如某条记录根据状态字段查询，有些记录是所有人可见，有些记录是创建者私有，如何实现？

2. 后端查询条件规则，某条记录的某个字段，对一部分人可见，一部分人不可见，如何实现？

@jimchen9999
官网的例子
```js
var cOntext= new SchoolContext();
var students = (from s in context.Students
where s.FirstName == "Bill"
select s).ToList();
```
http://www.entityframeworktutorial.net/basics/how-entity-framework-works.aspx

确实比很多 ORM 库写法简单不少，但 APIJSON 压根就不用后端写这些代码，前端传 JSON 参数过来就行了
```
{
"[]": {
"Student": {
"firstName": "Bill"
}
}
}
```
可以把里面的 Student 提取出来
```
{
"Student[]": {
"Student": {
"firstName": "Bill"
}
}
}
```
还可以把里面的 Student 的 firstName 提取出来
```
{
"Student-firstName[]": {
"Student": {
"firstName": "Bill"
}
}
}
```
都不用前端遍历再取值了。

@royzxq 原本 Node.js 有这种库，后面 ES6 加进来作为标准语法，
但问题是接手一个两年的项目，里面几十万行代码，基础设施敢随便升级？
出现生产事故别说奖金没了，可能还得扣工资。
而且即便用上了语法糖，一个请求能解决的为啥非得多个请求？
不仅代码写起来麻烦，http 连接也要多次，延时是累加的。

想问一下和.net 的 EF 比有什么优势和劣势

eeeee 也好多 k star，然而没啥意义。还是得点个赞，开发不易

@qqqss 欢迎提问，而不是没搞清楚就随便吐槽。
APIJSON 提供了自动化的权限管理，OWNER 指当前登录用户, LOGIN 指任何登录用户，UNKNOWN 指未登录用户，
给 表对应的 JavaBean 配置访问权限，然后 Request 表里配置对应的校验和补全规则即可。
https://juejin.im/post/5b17518c6fb9a01e75463096

@qqqss
对字段的控制，也可以通过上面的方法配置不同角色查询这张表的校验规则，
还可以在 SQLExecutor 查到后，根据角色和权限配置过滤调没权限访问的字段。
https://github.com/TommyLemon/APIJSON/issues/31

@kevinle #41 楼问了类似的问题，#64 楼有回复。

任何需要后端写代码实现 CRUD 的库，
和 APIJSON 的开发效率都不是一个级别的，
请大家了解清楚，APIJSON 是后端不用写代码的 ORM 库，
不要随便拿别的库来说比 APIJSON “不知道牛逼多少”，谢谢！

额，这也能置顶？

#65 @TommyLemon 你这自相矛盾啊。 都老代码了，自然没有 APIJSON， 也就不谈 async/await 了。
新写的 async/await 不能用吗，http2 下多一次请求很费时间吗？

还有就是看文档最后是把 JSON 作为 URL 的一部分，看上去挺别扭的。能 POST 而不是丢 URL 里么。

@TommyLemon #31 hibernate 不是关闭 issue 人家用的是 jira 管理 issue , 问题不在 github

https://hibernate.atlassian.net/projects/HHH/issues

@airyland 有道理，国内开发者喜欢在各个地方宣传，引导点赞，论技术影响力，hibernate 的影响力绝对比这个项目大

把后端要写的 query 搬到前端写 就改变世界了？数据结构变了 前端不得重来？ coupling 这么严重看不出来吗？

迷之比较，项目好像不错，这推广就比较恶心了。