腾讯 APIJSON：让后端 CRUD 写到怀疑人生的 ORM 工具
文章目录
- 腾讯 APIJSON：让后端 CRUD 写到怀疑人生的 ORM 工具
- 1、这工具解决的是什么问题
- 2、它能做到什么程度
- 3、前端怎么用
- 4、谁在用
- 5、适合什么场景
腾讯 APIJSON：让后端 CRUD 写到怀疑人生的 ORM 工具
APIJSON 在 GitHub 上拿到了 18.3K Star。
腾讯开源了这个项目，定位是一个基于 JSON 的 ORM 库，外加一整套接口通信协议。它要做的事情很聚焦：把后端 CRUD 接口的开发工作量压到接近零。
1、这工具解决的是什么问题
写过中等规模后端的人都知道，大部分接口都是 CRUD。增删改查五个动作，每个表写一遍，写完还要写文档，写完文档还要陪前端对接口字段，前端口偏差一点回头改后端代码再重发一次。一个项目里 70% 的后端代码都在干这个体力活。
APIJSON 想把这层体力活干掉。它直接让前端通过 JSON 描述要什么数据、要哪些字段、关联哪几张表，后端拿到 JSON 后自动解析、自动拼接 SQL、自动返回结构化的 JSON。
整个流程下来，后端开发者几乎不用写增删改查接口。配置好表结构和权限，剩下的让协议自己处理。
2、它能做到什么程度
支持的特性里，比较关键的几条：
- 前端一次请求可以同时查多张关联表，返回的 JSON 结构由前端自己定
- 支持模糊搜索、远程函数调用、CRUD 全套读写
- 自动生成接口文档，前端不再依赖后端口头描述字段含义
- 兼容老版本接口，后端升级时旧 App 不会突然挂掉
数据库支持横跨 MySQL、PostgreSQL、SQLServer、Oracle、DB2、MariaDB、TiDB、ClickHouse、DuckDB、Elasticsearch、Redis、Kafka、Snowflake、Hive、MongoDB Atlas、Cassandra、InfluxDB、TDengine、TimescaleDB 等，差不多覆盖了主流关系型、时序型、文档型、搜索型的数据库。
3、前端怎么用
前端这一侧的逻辑变了。原来调接口要看后端定义了什么 endpoint，现在前端可以自己拼 JSON 描述想要的数据形状。
举个例子，要查用户的朋友列表里朋友的帖子评论，传统做法是后端写一个专门的接口，前端调一下拿结果。APIJSON 里前端直接在自己的请求 JSON 里把三张表的关系写出来，发给同一个 endpoint，后端解析后一次返回所有数据。
这种做法的好处是接口数量大幅压缩，不用为了每个新需求新增 endpoint。坏处是前端需要理解表结构，权限控制必须配置得很严，否则容易查到不该查的字段。
4、谁在用
README 列出的使用方包括传音控股、社保中国、厦门小鱼网等公司。腾讯自己内部也在用，毕竟是腾讯开源出来的项目。
5、适合什么场景
- 中后台管理系统、企业内部工具，CRUD 接口数量爆炸、迭代频繁的项目
- 需要快速搭原型、对接多个数据源的小团队
- 愿意接受协议约束、能投入精力配置权限规则的团队
如果是面向外部的高并发 C 端接口，或者对 SQL 执行计划有严格定制需求的项目，直接套 APIJSON 不一定合适。它更像是一个能让内部业务长得快、迭代成本压得低的工具，把后端开发从重复劳动里解放出来去做更值钱的活。
像是一个能让内部业务长得快、迭代成本压得低的工具，把后端开发从重复劳动里解放出来去做更值钱的活。