腾讯 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 不一定合适。它更像是一个能让内部业务长得快、迭代成本压得低的工具，把后端开发从重复劳动里解放出来去做更值钱的活。

像是一个能让内部业务长得快、迭代成本压得低的工具，把后端开发从重复劳动里解放出来去做更值钱的活。