Skip to content

Commit dbcc94a

Browse files
committed
docs(plugin): add design document for plugin
1 parent 5cc0de4 commit dbcc94a

File tree

1 file changed

+85
-12
lines changed

1 file changed

+85
-12
lines changed

docSite/content/zh-cn/docs/guide/plugins/design_plugin.md

Lines changed: 85 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -9,15 +9,88 @@ weight: 301
99

1010
## 背景
1111

12-
原先 FastGPT 的各项功能均采用单体应用,子 packages 的方式进行构建。随着用户范围增多,个性化需求丰富,以及多次交付时遇到的系统工具定制困难问题,导致我们对
13-
我们决定设计一种更为灵活的扩展
14-
15-
主要有如下的目的:
16-
1. 解耦合,模块化。
17-
2. FastGPT-plugin 可以快速迭代,版本不依赖于 FastGPT
18-
3. 降低开发复杂度(不需要运行 FastGPT 环境)
19-
4. 插件市场
20-
21-
更远期的设想:
22-
1. 以纯代码的形式构建应用
23-
2. 加入其他可以自定义的模块
12+
原先 FastGPT 的各项功能均在 FastGPT 的 Next.js 的框架内,通过 Monorepo 的方式进行组织。
13+
系统插件也作为一个 sub-repo 存在于 FastGPT/packages/plugin 下。
14+
15+
然而随着用户的增加,这种组织模式的弊端凸显:
16+
17+
1. 虽然 FastGPT 以每周一次的频率进行发版,但同样,系统插件必须伴随 FastGPT 的发版而发版,极大限制了系统插件的迭代速率。
18+
2. 如果社区希望为 FastGPT 提供插件,则需要将 FastGPT 整个应用运行起来,并且直接向主仓库发起 PR。
19+
3. 如果社区希望使用自定义的插件,则需要维护一个 FastGPT 的 fork 版本,并且手动维护更新和代码的合并,增加了开发的难度。
20+
4. 由于 Next.js/webpack 的限制,无法在运行时挂载新的插件,实现热插拔。
21+
22+
## 设计方案
23+
24+
因而,我们决定将系统插件拆分出来,到一个独立的 repo 中。
25+
26+
[FastGPT-plugin](https://github.com/labring/fastgpt-plugin)
27+
28+
拆分出来,主要有如下的目的:
29+
1. 解耦合,模块化:不只是 系统工具可以作为热加载的模块,也可以是其他的插件,例如知识库的插件,RAG 等等。
30+
2. FastGPT-plugin 可以快速迭代,版本不依赖于 FastGPT:FastGPT-plugin 可以更高频率的发版,支持热插拔可以在不发版的情况下更新插件。
31+
3. 降低开发复杂度(不需要运行 FastGPT 环境):贡献插件时只需要独立运行 FastGPT-plugin 中提供的调试套件即可。
32+
4. 插件市场:后续可以实现插件市场,用户可以通过插件市场发布、获取自己需要的插件。
33+
34+
## 技术选型
35+
36+
37+
1. 使用 ts-rest 作为 RPC 框架进行交互,提供 sdk 供 FastGPT 主项目调用
38+
2. 使用 zod 进行类型验证
39+
3. 用 bun 进行编译,每个工具编译为单一的 `.js` 文件,支持热插拔。
40+
41+
```mermaid
42+
graph LR
43+
A[FastGPT] --> |RESTful API|B[FastGPT-plugin]
44+
B <--> C(Minio)
45+
```
46+
47+
## 项目结构
48+
49+
- **modules**
50+
- **tool** FastGPT 系统工具
51+
- **api** 接口实现逻辑
52+
- **packages** 系统工具目录(每一个都是一个 package)
53+
- getTime
54+
- dalle3
55+
- ...
56+
- **type** 类型定义
57+
- **utils** 工具
58+
- **scripts** 脚本(编译、创建新工具)
59+
- **sdk**: SDK 定义,供外部调用,发布到了 npm
60+
- **src**: 运行时,express 服务
61+
- **test**: 测试相关
62+
63+
系统工具的结构可以参考 [如何开发系统工具](/docs/guide/plugins/dev_system_tool)
64+
65+
## 技术细节
66+
67+
### ts-rest 构建 contract,自动构建 openapi 对象,导出 client
68+
69+
[ts-rest](https://ts-rest.com/) 是一个 ts 的 restful api 框架。构建 contract 后,可以根据 contract 的定义
70+
编写处理逻辑,自动生成 openapi 对象、通过 createClient 导出 client 进行请求。
71+
72+
类似的 `tRPC` 也是一个 ts 的 RPC 框架。
73+
然而 tRPC 使用自己的一套请求格式,导致其他工具不方便接入。而使用 ts-rest 本质就是对 RESTful API 的简单封装,也能直接生成 openapi 对象。
74+
75+
### zod 类型校验
76+
77+
我们使用 zod 来实现类型校验。
78+
zod 可以实现在运行时的类型校验,也可以提供更高级的功能,例如参数转换,对象合并等。
79+
80+
### 使用 worker 实现插件的并行运行以及环境隔离
81+
82+
为了保证插件之间不会相互干扰,同时提高并发处理能力,FastGPT-plugin 采用 Worker 线程来实现插件的执行。每个工具在被调用时都会在独立的 Worker 中运行,
83+
这带来几个重要的优势:
84+
85+
1. 环境隔离:每个插件都是一个独立的 Worker 进程,插件之间不会影响。
86+
2. 并行处理:每个插件可以并行处理,提高整体性能。
87+
88+
### 使用 bun 进行打包
89+
90+
将插件 bundle 为一个单一的 `.js` 文件是一个重要的设计。这样可以将插件发布出来直接通过网络挂载等的形式使用。
91+
92+
## 未来规划
93+
94+
1. 可视化开发工具:提供可视化的插件开发和调试工具,降低开发门槛。
95+
2. 插件市场:建立插件市场,允许开发者发布和分享自己的插件。
96+
3. 更多插件类型:除了系统工具外,扩展到知识库插件、模型插件、RAG 插件等更多类型。

0 commit comments

Comments
 (0)