docs: add document about how to deploy plugin

website/docs/plugins/guide/deploy.md

@@ -0,0 +1,54 @@
+---
+sidebar_position: 90
+title: Deploy Plugin
+---
+
+:::info
+The deployment strategy of the plugin will be optimized in the future. At present, tailchat is not convenient enough to customize the plugin during deployment, so it may be a little confusing. Therefore, this document only represents the status quo and will be continuously improved in the future
+:::
+
+First, let’s talk about the classification of Tailchat plugins. Tailchat plugins are divided into `pure frontend plugins`, `pure backend plugins`, `frontend plugins`
+
+`Pure frontend plugin` is the easiest to understand, which means that the plugin only runs in the frontend code, relies on the existing context for communication, and does not need Tailchat backend support. (In particular, frontend plugins that communicate with custom backends, such as the `com.msgbyte.ai-assistant` plugin)
+
+`Pure backend plugin is` a plugin that communicates with the Tailchat network, without a frontend interface, and calls actions of other services through rpc to achieve some purposes. For the backend plugin, it means that the plugin itself is connected to the Tailchat backend network, has the highest authority, and can access some actions whose visibility is `public` (by default, only actions at the `publish` level can be accessed externally, others level are only accessible to internal services), a frontend-free backend plugin such as `com.msgbyte.simplenotify` plugin
+
+`Frontend plugin` means a plugin with both frontend and backend. It is the most complex but most capable plugin type. It interacts with the backend through the frontend plugin and interacts with other services through the backend plugin without modifying the core code. Can complete most of the development work under the premise of
+
+You can check the corresponding plugin example in this document: [plugin list](/docs/plugin-list/fe)
+
+## Deployment process
+
+The process of deploying different plugins is different
+
+### Pure frontend plugin
+
+For pure frontend plugins, you can place the code in the `client/web/plugins` directory inside the project or use a separate static file service management. Make sure that the js documents of the project can be accessed normally.
+
+If this is a plugin for personal use, you can install it through the manual installation of the plugin center, and enter the json configuration of `manifest.json`. Pay attention to ensure that the addresses in the configuration file can be accessed normally.
+
+If you want all users to see the code, you need to add your own plugin configuration in `client/web/registry.json`.
+
+If you want to be a built-in plugin installed by default, you need to modify the `client/web/src/plugin/builtin.ts` file to let the frontend code load the plugin at startup.
+
+### Pure backend plugin
+
+In order for the plugin to be loaded automatically, you can place the code in the `server/plugins` directory or deploy it independently, just make sure you can connect to the same network (share the same TRANSPORTER)
+
+The plugin service deployed by default will uniformly load all backend plugins in this directory. Need to ensure that the name of the plugin service is `*.service.ts`/`*.service.js`
+
+*If you only want to run in the development environment and ignore it in the production environment, please name the file `*.service.dev.ts`*
+
+You can access the backend `/health` (such as: `http://localhost:11000/health`) route or use the `tailchat connect` tool to view the list of loaded microservices
+
+### Frontend and backend plugins
+
+The deployment of the frontend and backend plugins is similar to that of the backend, but the compilation command needs to be modified so that the frontend code of the frontend and backend plugins can be deployed to the `public/plugins` directory when building
+
+The specific method is: modify `package.json`, add the name of the plugin you want to compile in the `build:server` command
+
+> {BACKEND} in the configuration file refers to the backend address, because the backend address is not necessarily consistent with the frontend address due to the separation of the front and back ends
+
+--------
+
+Remember to rebuild the docker image after all operations are done

website/i18n/zh-Hans/docusaurus-plugin-content-docs/current/plugins/guide/deploy.md

@@ -0,0 +1,54 @@
+---
+sidebar_position: 90
+title: 部署插件
+---
+
+:::info
+插件的部署策略后续会进行优化，目前tailchat对部署时自定义插件还做的不够便利，因此可能会有些困惑。因此本文档仅代表现状，后续会不断改进
+:::
+
+首先说一下 Tailchat 插件的分类，Tailchat 的插件分为 `纯前端插件`, `纯后端插件`, `前后端插件`
+
+`纯前端插件`最为容易理解，表示插件仅运行在前端代码中，依赖已有的上下文进行沟通，无需Tailchat后端支持。（特别的，对于与自定义后端进行通信的也是前端插件，如`com.msgbyte.ai-assistant`插件）
+
+`纯后端插件为`为与Tailchat网络进行通信的插件，无前端界面，通过rpc调用其他服务的action来实现一些目的。对于后端插件来说，意味着插件本身接入了Tailchat后端网络，拥有最高的权限，可以访问一些可见性为`public`的action(默认只有`publish`级别的action可以被外部访问，其他级别的都是只有内部服务才能访问)，一个无前端的后端插件如`com.msgbyte.simplenotify`插件
+
+`前后端插件` 表示既有前端又有后端的插件，是最复杂但是能力最完全的插件类型，通过前端插件与后端交互，通过后端插件与其他的服务进行交互，在不修改核心代码的前提下能完成大部分的开发工作
+
+你可以在这个文档中查看对应的插件示例: [插件列表](/docs/plugin-list/fe)
+
+## 部署流程
+
+在不同的插件部署的流程是不一样的
+
+### 纯前端插件
+
+纯前端插件你可以将代码放置在项目内部`client/web/plugins`目录下或者使用单独的静态文件服务管理。确保项目的js文档都是能正常访问的。
+
+如果这是一个个人使用的插件，你可以通过插件中心的手动安装来安装，输入`manifest.json`的json配置即可。注意确保配置文件中的地址都是可以正常访问的。
+
+如果想让所有的用户都能够看见代码，你需要在`client/web/registry.json`中添加你自己的插件配置。
+
+如果想要成为一个默认安装的内置插件，需要修改`client/web/src/plugin/builtin.ts`文件来让前端代码在启动时加载插件。
+
+### 纯后端插件
+
+为了让插件能够被自动加载，你可以将代码放置与 `server/plugins` 目录下或者独立部署，只需要确保能够连入同一个网络即可(共用同一个TRANSPORTER)
+
+默认部署的插件服务会将该目录下的所有后端插件统一加载。需要确保插件服务的命名为`*.service.ts`/`*.service.js`
+
+*如果仅想在开发环境运行而在生产环境忽略，请将文件命名为 `*.service.dev.ts`*
+
+你可以访问后端 `/health`(如:`http://localhost:11000/health`) 路由或者使用`tailchat connect`工具查看已加载的微服务列表
+
+### 前后端插件
+
+前后端插件的部署与后端差不多，但是需要修改编译命令让构建时能够把前后端插件的前端代码部署到`public/plugins`目录下
+
+具体方式是: 修改`package.json`, 在 `build:server` 命令中追加想要编译的插件名称
+
+> 配置文件中的 {BACKEND} 指代后端地址，因为前后端分离的关系后端地址不一定和前端地址保持一致
+
+--------
+
+所有操作完毕后记得重新构建 docker 镜像