客户管理插件 — 三种实现方案

选择最适合项目架构和交付目标的实现路径

A

纯 WASM 插件 + 增强插件 UI 引擎

数据层:全部通过 WASM Host API,5 个动态表存储在 JSONB

UI 层:扩展 PluginCRUDPage,新增 ui_widget 类型(tree、graph、timeline)

关系图谱:新增 "graph" ui_widget,前端用 D3/AntV G6 渲染

优势

  • 完全在插件架构内,验证插件系统能力
  • 新增的 ui_widget 可被所有未来插件复用
  • 动态安装/卸载,热插拔

劣势

  • JSONB 查询性能弱于原生列
  • 复杂关系查询需多次 Host API 调用
  • ui_widget 扩展工作量大(3-4 种新控件)
B

WASM 插件数据层 + 专用前端页面(推荐)

数据层:WASM 插件管理 5 个实体,通过 Host API 操作

UI 层:前端新增 CRM 专用页面组件(客户列表、联系人、沟通时间线、关系图谱)

路由:插件的 manifest.ui.pages 声明自定义页面,前端按 pluginId 匹配加载

优势

  • 最佳 UX — 专为 CRM 设计的交互
  • 关系图谱可用专业图表库(AntV G6)
  • 数据层仍验证 WASM 插件系统
  • 前后端分离,UI 可独立迭代

劣势

  • 每增加一个插件需写前端代码
  • 插件 UI 不能完全动态化
  • 数据查询仍受 Host API 限制
C

内置 erp-crm crate + 独立前端

数据层:新建 erp-crm crate,直接 SeaORM Entity,原生列存储

UI 层:独立前端页面,直接调用 CRM API

关系图谱:数据库原生支持关系查询,前端 AntV G6

优势

  • 性能最优 — 原生 SQL + 索引
  • 复杂关系查询简单高效
  • 完全控制数据模型

劣势

  • 不走插件架构,违背"插件优先"原则
  • 编译时耦合,不能动态安装
  • 不适合作为"第一个插件"验证目标

💡 推荐方案:B(WASM 数据层 + 专用前端)

作为"第一个插件",方案 B 在验证插件系统交付可用产品之间取得最佳平衡: 数据层走 WASM Host API 验证插件架构的可行性,UI 层不受 schema 驱动的限制, 可以提供真正好用的 CRM 交互体验。同时为未来的插件 UI 定制建立模式(manifest.ui.pages 的前端路由匹配机制)。