APIJSONBoot 对比 SSM/SSH+生成代码 等开发效率可提升 20 倍以上

[TommyLemon]

群友：

”除非提供非常大的便利，才能单独建立一种新的技术体系。“

作者：

对，至少要提升 1 倍，才能覆盖 学习成本(约 10%，看文档、跑 Demo 等) + 迁移成本(约 30%，改用新的库 API、工具链、开发流程等) + 风险成本(约 60%，万一不行还得再迁回去重新用以前的方式去做)。

为了对比方便，以下
APIJSONBoot 指 Spring+SpringBoot+APIJSON，
SSM 指 Spring+SpringBoot+Mybatis(且允许配套 PageHelper 等简化 分页 和简单 CRUD 的插件以及生成代码工具)，
SSH 指 Spring+SpringBoot+Hibernate/JPA 等 ORM 库，
SSMH 指 SSM + SSH。
(注：业内 SSM, SSH 通常分别指 Spring+SpringMVC+Mybatis, Spring+Struts+Hibernate，
但 SpringMVC 和 Struts 目前在大部分场景都已被 SpringBoot 包含或取代)

假设表数量为 T， 字段数量为 C，不考虑业务逻辑处理(业务逻辑代码处理基本一致，两者用时相当)，
APIJSONBoot 在 适用场景 的项目中一般都是 20 倍以上的开发效率提升：
平均 2 分钟配置好一张表的增删改查权限，即可实现各种条件( C! x 每个字段 28 种条件功能 x @combine 与或非 3 种 x 2^C 组合数 的 单表单记录 + 单表多记录 + 结合已配置过权限的其它表各种排列组合 ( T! 个) 总共 C! x 28 x 3 x 2^C x T! 个 细粒度 RESTful 查询接口，
再花 3x1xC 分钟配置增删改校验规则，即可相当于实现了 单表单记录+单表多记录 总共 2xT 个 RESTful 增删改接口，总共用了 2xT + 3xC 分钟开发，然后花最多 5 分钟调热更新接口来热重载配置即可部署生效；

假设一个开发很熟练地同样实现 APIJSONBoot 总共 2xT + 3xC 分钟实现的各种增删改查功能，用 SSMH 实现 RESTful API，并且还不做任何权限及参数校验，那么
查询需要 平均每表 30 分钟完成单表不带查询条件的 Controller, Service, Mapper, DTO/VO/BO …，加每个字段 28 个功能 x C， 60 分钟完成一个多表关联查询接口，总共 30xT + 28xCxT + 60x2^T 分钟)，
增删改(假设用了 PageHelper, Mybatis-Plus 等免写 SQL 封装工具) 需要 每张表在写查询接口实现过的 Controller, Service 中新增对应的 3x2 个方法，约 5 分钟，总共 5xT 分钟，然后假设没冲突且不出错的情况下 推送、合并代码，再顺利重启服务部署到开发/测试环境，一般最快也要 10 分钟。

总结下，只是完成接口开发和自测，不算部署时间，
APIJSONBoot(按慢估计) 相比 SSMH(按快估计) 这种传统方式开发总时间对比为：
(2xT + 3xCxT) : (30xT + 28xCxT + 60x2^T + 5xT)
简化为：
(2xT + 3xCxT) : (35xT + 28xCxT + 60x2^T)

假设需要对 1 张表(3 个字段)开发接口，即 T = 1, C = 3 ，那么总时间对比为
11 min(约十分钟) : 239 min(3.98 小时，约一上午)，速度提升 20.73 倍！

假设需要对 5 张表(平均每张表 4 个字段)开发接口，即 T = 5，C = 4，那么总时间对比为
70 min(约一小时) : 44.25 hour(朝九晚六 5.53 天，约一星期)，速度提升 36.93 倍！

假设需要对 10 张表(平均每张表 10 个字段)开发接口，即 T = 10，C = 10，那么总时间对比为
320 min(约一上午) : 44.85 day(996 工作 3.45 月，约一季度)，速度提升 200.84 倍！

假设需要对 20 张表开发接口(平均每张表 15 个字段)，即 T = 20，C = 15，那么总时间对比为
940 min(约上班两天) : 1456.57 month(全年无休 11117 工作 239.44 年，接近美国建国至今 243 年！)，速度提升 66,939.06(约 7 万) 倍！

假设需要对 50 张表开发接口(平均每张表 20 个字段)，即 T = 50，C = 20，那么总时间对比为
3100 min(约上班一周) : 128527386625.93 year(时刻工作、一秒不停也要 1285 亿年，超过宇宙年龄 138.2 亿年！)，速度提升 21791611100189(21 万亿) 倍！

为什么表数量越多，开发总时间差距会指数暴增呢？
因为 APIJSONBoot 支持任意表关联组合查询，把 SSMH 随表数量指数暴增的 RESTful API 开发时间 降到了线性稳定增长！

为什么后面 SSMH 开发 20 张表 CRUD 接口的时间需要几百年，50 张表甚至超过宇宙年龄了，实际上也就几个月开发完了啊？
因为实际上需求并不会覆盖 表的所有 CRUD、 表的所有排列组合、字段的所有条件、字段的所有组合。

因为主要是表排列组合导致了指数暴增，所以我们再根据实际情况，把 表的所有排列组合 减少至常规的 两两 排列组合，
那就只有 T! / (T - 2 )! 种情况，SSMH 开发 RESTful API 的公式变为：
(35xT + 28xCxT + 60xT! / (T - 2 )! )

而 APIJSONBoot 的公式不变，所以对比为：
T = 1 时：11 : 179
T > 1 时：(2xT + 3xCxT) : (35xT + 28xCxT + 60xTx(T - 1) )

简化为：
T = 1 时：11 : 179
T > 1 时：Tx(3xC + 2) : Tx(60xT + 28xC - 25)

按照一般互联网中小型项目情况可得出以下对比表格：

表数量 T	平均每表字段数 C	SSMH 按快估计	APIJSONBoot 按慢估计	APIJSONBoot 提速倍数
1	3	179 min(约一上午)	11 min(约十分钟)	15.27
5	4	1935 min(约朝九晚六一周)	70 min(约一小时)	26.64
10	10	8550 min(大小周超半个月)	320 min(约一下午)	25.72
20	15	31900 min(约 996 两个月)	940 min(约上班两天)	32.94
50	20	176750 min(11117 超半年)	3100 min(约上班一周)	56.02

这还是在 APIJSONBoot 实现了权限和参数校验、SSMH 不做权限和参数校验的情况下！
如果 APIJSONBoot 也不做权限和参数校验(全局关闭)，那么根本不用花任何时间，总时长总是 0 ！

[TommyLemon]

欢迎大家积极讨论，如果有以上内容有任何错误，敬请指正，非常感谢^_^

[TommyLemon]

有梦不弃：
“对于前后端开发，带来了很大的便利（有了它，后端不再需要写常规的业务代码，简单的，复杂的，增删改查）”

腾讯 IEG 数据产品开发组负责人 xinlin：
”腾讯的 APIJSON 开源方案，它可以做到零代码生成接口和文档，并且整个生成过程是自动化。

当企业有元数据的时候，马上就可以获得接口“

腾讯科技 后台开发高级工程师 雷大锤：
“可以抽出时间来看apijson了，这个可以为T10做准备，也是业界很火的东西，可以提升个人影响力！”

JAVA道人：
“apijson适应于中小应用,可以做到忽略后端.它相当于有着自己的格式,可以构造各式各样的查询条件及其他操作”

百度智慧城市研发 lpeng：
“很兴奋的发现APIJSON很适合我们的一个开发场景，作为我们协议定义的一部分”

辛苦耕种的农民工：
“APIJSON帮助了我们后端简化了很多步骤，让我们开发效率可以大幅增加”

BAT 技术专家、apijson-practice 作者 vcoolwind：
“实践一下apijson，对做管理平台还是能有不少提效的~ apijson orm本身就一个orm工具，更好的一点是不需要编码”

Akily：
“在官网使用了一波，个人觉得对于后端来说事真的省事很多了”

华为 minshiwu：
“demo工程，默认使用apijson-framework，可以做到无任何配置即可体验apijson的各种能力。”

万物可盼：
“以我多次使用过的感受来说：当我们搭建好APIJSON，后台开发已经结束了！”

计算机技术 硕士 团团you：
“最近因搬砖需要看这个，用来简化持久层，所以学了一下，写了个教程，还是比较容易上手的。”

中兴工程师 duyijiang：
“感谢腾讯大大提供的框架，很好用”

kls：
“初步使用了下APIJSON ，确实是个厉害的作品 好上手，对效率提升明显”

APIJSONParser 作者 Zerounary：
“使用这个项目作为后端的支持的话，是不需要对每个表写增删改查等接口的，只需在该项目连接的数据里进行表的创建，以及配置接口权限即可。无需进行过多的开发，哪怕是要改结构也仅仅只需要修改表字段而已。”

APIJSON-test 作者 JYbill：
“APIJSON开发效率还是蛮高的，适合那种需要快速开发中小项目”

cnlinjie：
“作者想法是非常前卫的，眼前一亮”

happyyangyuan：
“向大佬致敬，apijson协议设计得非常优雅，让我爱不释手。”

SphereEx 工程师、前社保科技工程师 钟红胜：
“之前公司(注：指的是社保科技)还用过APIJSON呢，开发效率挺高的”

hegphegp：
这个项目可以让后端从curd的业务解放出来 缩减前后端对接的时间，提高效率”

JavaLitteBoy：
“APIJSON 非常棒 想法很给力 我以前也一直在思考这些东西 你这个简直茅塞顿开”

Grey Zeng：
“这个组件很好用，希望持续改进~”

apijson_role_extend、apijson_todo_demo 作者 jerrylususu：
“感谢 APIJSON 提供了一个高校而简洁的开发方案。”

MaDaMaDaMaDa：
“祝这个社区越来越繁荣~”

圆通 ED：
“目前3个项目用了。其中一个项目，apijson接口的占比是40%左右。apijson还是低代码解决了很大的问题，释放了一部分开发资源，还是很降本增效的。”

苏显斌：
“apijson这样的设计理念，我觉得是未来的趋势（特别有利于微服务架构的API开发），我个人非常看好。”

尘记：
“能减少前后端不少工作量，给作者点赞！”

cnlinjie：
“作者想法是非常前卫的，眼前一亮”

CSDN认证博客专家、Java领域优质创作者 ZWZhangYu：
“前辈好，感谢开源APIJSON，非常强大的工具”

bloy：
“赞，使用很爽”

Tom-Lin：
“很棒。我原来也是想用 json 来代替 接口的，你实现了！”

itbencn：
“刚刚接触apijson，相见恨晚，真的很给力”

Terry05：
“支持，很不错的项目”

cyssxt：
“楼主做这个很厉害 ！”

liyuanba：
“能做这么大一个 open source 的 repo，lz 牛逼”

小柑橘：
“从17年知道APIJSON开始，看着它一步步成长到今天，也见识到它年轻生命所拥有的强大力量；一路上离不开作者和其他贡献者的付出与坚持。”

langxj：
“这个确实好用，大厂出品，质量确实有保证”

zhangjie617：
“作者的态度和理念我十分赞同，支持下”

Ritr：
“能做出来，很厉害了。对于中小型项目来说基本就够用了，极大的降低了开发成本”

shengqiang025210：
“apijson还是很棒的，看了你们的智慧就越觉得精彩，做东西这过程中的要付出的可不是一般的辛苦，希望好东西能越来越强一直延续下去。”

neginegi：
“国内低代码平台，感觉这个比较有前景。”

flogyin：
“有过类似的需求和想法，你这个是落到实处了，真心不错”

gemufeng：
“非常感谢帮忙，你们的项目给我们的产品带来了巨大的好处，我们需要深度的使用apijson，非常感谢。”

腾讯 bodian520：
“在调试GET、POST、PUT接口时遇到了一些问题，把个人的摸索经验分享一下，希望作者能梳理下文档，方便我们更好的接入”
#189

字节跳动 qiujunlin：
“初次见到这个项目，觉得太惊艳了，眼前一亮。根据教程完成了 demo 。
给我的感受是，项目大大简化了开发流程，开发效率提升了很多倍。”

[TommyLemon]

Alibaba 阿里巴巴】飞猪前端团队也推荐了 APIJSON
#461

【Alibaba 阿里巴巴】 技术专家艾小仙也推荐了 APIJSON
#459

某人【Tencent 腾讯】 TEG 一面面经：被问了 APIJSON
#385

【Alibaba 阿里巴巴】【Aliyun 阿里云】网络二面：APIJSON 介绍一下，难点在哪，你解决了什么问题，
#389

【Huawei 华为】云开发者联盟 转载：APIJSON教程：上手apijson项目，学习apijson语法，并实现持久层配置
#465

【WeBank 微众银行】 微众开源也 fork 了 APIJSON
#464