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

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

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 的前端路由匹配机制）。