后台表格、查询、流程总在重复写？我用ToolJet把PostgreSQL直接做成可远程访问的业务系统

后台表格、查询、流程总在重复写？我用ToolJet把PostgreSQL直接做成可远程访问的业务系统

前言

后台系统最容易消耗时间的地方，往往不是业务有多难，而是一遍遍重复做表格、表单、查询、按钮、权限和数据绑定。很多内部工具本质上只是把已有数据库和业务接口组合成一个可操作页面，却还是要重新搭前端、写接口、联调和部署，项目一多，这些重复工作就会越来越明显。

这次我把 ToolJet 部署到极空间上，先用 Docker 跑起 8083 Web 页面，再完成初始化、连接 PostgreSQL、创建应用、读取 users 表，并通过组件面板把查询结果直接展示成表格。

接着继续体验工作流和 ToolJetDB，新建数据表，把"页面、数据源、查询、流程"几部分串起来。

本地功能跑通以后，再把 8083 提供给外部设备访问，并配置固定二级子域名。整篇重点不是把 ToolJet 写成"几分钟替代所有开发"，而是看它在内部管理工具、数据查询和简单业务流程里，到底能省掉哪些重复工作。

这也是我觉得ToolJet最值得测试的一点：它不是单纯给页面套一个模板，而是把数据库、查询、组件和工作流放进同一个编辑环境。对于那些"业务并不复杂，但后台又不能没有"的需求，真正节省的不是几行代码，而是把一整套重复开发过程缩短。

1 ToolJet适合解决什么问题

ToolJet更适合这类场景：

• 内部管理后台；
• 数据查询页面；
• 表单录入；
• 简单审批；
• 数据看板；
• 自动化流程；
• 已有数据库和API的快速整合。

这些系统通常不是业务逻辑特别复杂，而是页面、查询和操作高度重复。

如果每次都从：

数据库 → 后端接口 → 前端页面 → 联调 → 部署

重新开始，时间很容易耗在重复工作上。

ToolJet的思路是把这些通用能力提前做成：

• 组件；
• 数据源；
• 查询；
• 工作流；
• 内置数据库；
• 页面配置。

开发时更多是在"组合"，而不是从空白项目开始。

2 低代码不是完全不写代码

ToolJet的优势是减少重复代码。

它可以直接拖拽：

• 表格；
• 按钮；
• 输入框；
• 下拉框；
• 日期选择；
• 弹窗；
• 图表；
• 表单组件。

同时还能连接：

• PostgreSQL；
• MySQL；
• Redis；
• REST API；
• GraphQL。

但真正遇到：

• 自定义查询；
• 数据转换；
• JS / Python处理；
• 条件逻辑；
• 复杂业务规则；

仍然需要写SQL、脚本或配置逻辑。

所以更准确的理解是：

把常规后台开发里大量重复部分压缩掉。

不是完全替代开发。

3 这篇实际跑通了哪些能力

这次会实际完成：

• Docker部署；
• 8083访问；
• ToolJet初始化；
• PostgreSQL数据源连接；
• 创建应用；
• 查询users表；
• 表格组件展示数据；
• 工作流；
• ToolJetDB建表；
• 外部访问；
• 固定二级子域名。

也就是说，重点不只是把首页打开。

而是把：

数据源 → 查询 → 页面 → 流程

真正串起来。

4 准备极空间SSH环境

先开启SSH。

终端连接：

ssh root@IP

这里只要能够正常进入极空间终端，就可以继续后面的Docker部署。

5 检查Docker环境

执行：

docker -v
systemctl status -v

这一步按本次环境继续检查Docker状态。

后面ToolJet全部跑在Docker容器里。

6 拉取ToolJet镜像

执行：

 sudo docker pull tooljet/try

这里使用的是：

tooljet/try

体验版镜像。

镜像拉取完成以后，再启动容器。

7 启动ToolJet容器

执行：

sudo docker run  --name tooljet  --restart unless-stopped  -p 8083:80  -v tooljet_data:/var/lib/postgresql/13/main tooljet/try:latest

这一条命令同时做了几件事：

• 容器名：tooljet
• 自动重启：unless-stopped
• 宿主机端口：8083
• 容器端口：80
• 数据卷：tooljet_data
• PostgreSQL数据目录持久化

也就是：

极空间8083 → ToolJet容器80

8 浏览器打开8083

访问：

http://极空间IP:8083

页面能打开以后，说明：

浏览器 → 极空间8083 → ToolJet

这一层已经正常。

9 第一次进入先完成初始化

开始初始化：

填写注册信息：

继续：

登录成功：

如果需要，可以调整界面主题：

到这里，ToolJet本身已经可以正常使用。

10 接下来先连接真实数据源

这次用PostgreSQL作为示例。

进入应用后：

1. 点击 Create new app
2. 进入 Data Sources
3. 添加 PostgreSQL
4. 填写数据库连接信息
5. 点击 Test connection
6. 保存数据源

页面：

继续填写：

连接验证：

做到这里，ToolJet已经能够访问外部PostgreSQL数据。

11 创建第一个应用

进入应用编辑页面：

继续：

接下来通过SQL读取：

users

表。

查询结果：

这一步真正体现了低代码平台的价值：

数据库已经存在时，不需要重新写一套前端表格和查询页面。

SQL返回的数据可以直接绑定到表格组件。

12 从数据库到页面，中间少了很多重复层

传统方式做一个后台列表页，通常还要处理：

• 接口定义；
• 参数；
• 返回结构；
• 前端请求；
• 表格；
• 列配置；
• 交互状态；
• 加载和异常。

ToolJet把其中很多通用部分放进组件和查询配置。

所以这类：

查表 → 展示 → 筛选 → 操作

场景会比较合适。

13 组件面板负责把数据变成页面

组件面板：

这里可以直接使用：

• Table；
• Button；
• Modal；
• Input；
• Date Picker；
• Select；
• Switch；
• Checkbox。

不需要先建立完整前端项目。

14 编辑器里最重要的是"数据和组件联动"

完整编辑界面：

左侧可以看到：

• 查询；
• 页面；
• 组件；
• 变量；
• 常量。

中间负责页面布局。

右侧负责：

• 标签；
• 默认状态；
• 事件；
• 校验；
• 显隐；
• 禁用状态；
• 提示。

底部继续管理数据库查询。

所以ToolJet更像是：

把页面、数据和动作放在同一个编辑器里。

15 低代码真正省下的是后台模板工作

像内部工具这类系统，经常重复：

• 列表；
• 新增；
• 修改；
• 查询；
• 状态切换；
• 弹窗；
• 数据展示。

这些部分如果每次都从零开发，收益很低。

ToolJet更适合把开发时间放到：

• 数据结构；
• 查询逻辑；
• 业务规则；
• 权限；
• 流程。

16 再看工作流能力

进入工作流：

创建：

工作流画布：

可以从：

Start

开始，再加入：

• ToolJetDB；
• REST；
• JS；
• 数据库操作；
• 条件判断；
• 循环；
• 返回响应。

继续：

这里的价值不是"完全不用写逻辑"。

而是：

复杂步骤可以直接用流程图串起来。

17 工作流适合做跨系统动作

比如：

• 查询数据库；
• 判断状态；
• 调用API；
• 更新数据；
• 返回结果。

如果完全用代码实现，需要自己处理执行顺序和条件。

工作流把这些步骤变成节点以后，整个流程更容易看懂。

18 ToolJetDB还能直接建表

进入表管理：

继续：

这次创建的数据表名称：

shan

包含两列：

• id
• name

其中：

id

使用serial自增，并设置Primary。

name

使用varchar，并设置NOT NULL。

继续：

这样在不额外准备业务数据库时，也可以直接使用ToolJetDB做一些简单数据表。

19 到这里已经不只是"低代码页面"

现在已经跑通：

• 外部PostgreSQL；
• SQL查询；
• 页面组件；
• ToolJetDB；
• 工作流。

所以这篇真正体验到的是：

ToolJet把数据源、页面和流程放到了同一个开发环境。

这比单纯"拖一个表格"更有代表性。

20 什么时候适合用ToolJet

比较适合：

• 内部管理工具；
• 数据维护后台；
• 运营后台；
• 简单CRM；
• 查询系统；
• 数据看板；
• 快速原型；
• 内部自动化。

这类应用通常：

业务明确，但不值得重复做大量通用页面。

21 什么时候不要为了低代码强行使用

如果项目本身：

• 交互非常复杂；
• 页面高度定制；
• 大规模面向C端；
• 高并发；
• 大量复杂业务状态；
• 有特殊前端性能要求；

就不应该因为"拖拽方便"而硬套低代码。

ToolJet更适合内部系统和工具型应用。

22 本地跑通以后，再考虑远程访问

到这里已经完成：

• ToolJet部署；
• PostgreSQL；
• 应用；
• SQL查询；
• 表格；
• 工作流；
• ToolJetDB。

如果团队都在同一内网，8083已经够用。

后面的步骤解决：

人在外面怎么打开这套ToolJet。

23 安装cpolar

执行：

sudo curl https://get.cpolar.sh | sh

查看服务：

sudo systemctl status cpolar

然后进入：

极空间IP:9200

24 给8083创建公网入口

配置：

• 隧道名称：tooljet
• 协议：HTTP
• 本地地址：8083
• 域名类型：随机域名
• 地区：China Top

创建以后：

从外部设备访问：

页面能够打开以后，说明：

外部浏览器 → 公网地址 → 极空间8083 → ToolJet

这一条网络链已经通了。

25 公网访问和团队协作不是同一件事

公网地址解决的是：

外面的设备能不能打开ToolJet。

真正团队使用还要考虑：

• 用户账号；
• 成员权限；
• 数据源权限；
• 应用权限；
• 谁能编辑；
• 谁只能查看。

ToolJet负责应用和权限。

cpolar负责网络入口。

这两层不要混在一起。

26 内部业务系统更应该控制暴露范围

ToolJet里可能包含：

• 数据源；
• 数据查询；
• 内部业务信息；
• 工作流；
• 成员账号。

所以远程访问更适合：

• 明确用户范围；
• 单独账号；
• 最小权限；
• 不共享管理员账号。

尤其如果这是内部业务后台，不应该因为"有公网地址"就默认适合公开。

27 配置固定二级子域名

进入预留：

设置名称：

tooljet

再回到隧道列表：

修改：

• 域名类型：二级子域名
• Sub Domain：已经保留的名称
• 地区：China Top

更新：

查看结果：

这样随机入口就切换成了固定二级子域名。

28 固定地址最大的价值是"入口稳定"

固定地址更适合：

• 团队收藏；
• 浏览器书签；
• 演示；
• 长期访问。

它解决的是：

地址不用频繁变化。

但真正业务系统能不能长期使用，仍然取决于：

• ToolJet服务；
• 极空间；
• 数据库；
• 权限；
• 网络；
• 账号。

29 最后把整条链重新看一遍

运行：

极空间 → Docker → ToolJet → 8083

数据：

PostgreSQL / ToolJetDB → Query → Components

流程：

Start → 数据库 / API / JS / 条件 / 返回

远程：

外部浏览器 → 公网地址 → 8083 → ToolJet

真正跑通：

• Docker部署
• 初始化
• PostgreSQL
• users表查询
• 表格展示
• 组件编辑器
• Workflow
• ToolJetDB
• cpolar
• 随机公网地址
• 固定二级子域名

这才是这篇完整的技术主线。

总结

这次实际跑下来，ToolJet最适合的不是"替代所有开发"，而是把内部后台里高度重复的那部分压缩掉。数据库已经存在时，可以直接接数据源、写查询、拖组件，把一个查询结果快速变成可操作页面。

从PostgreSQL到表格、再到工作流和ToolJetDB，这篇已经把ToolJet几个核心能力串起来了。它真正省下来的，是大量通用后台页面和基础交互的重复工作。

远程部分只解决访问入口，团队协作还要依赖ToolJet自己的用户和权限体系。尤其涉及内部业务数据时，账号、数据源和应用权限要和公网地址分开管理。

如果需求本身就是内部管理、数据查询、表单和简单流程，这类低代码平台会比从零搭一套前后端更省时间；如果业务已经非常复杂，则更适合作为辅助工具，而不是强行承担所有系统开发。