添加一个反馈按钮很容易。构建一个反馈系统则更难。
区别不在于输入表单，而在于有人按下发送之后发生的事情：
- 在应用程序接口响应之前，报告是否已存储？
- 它是否包含足够的上下文以供调查？
- 谁负责下一步行动？
- 团队能否通过原始渠道进行回复？
- 当通知失败时会发生什么？
- 如何在旧报告被遗忘之前使其可见？
本教程使用类型脚本、快速框架和 PostgreSQL 构建一个小巧但可运行的反馈工作流。相同的设计适用于错误报告、功能请求、支持问题以及产品内对话。
从工作流开始，而不是从组件开始
一个有用的反馈生命周期可以建模为：
已捕获 -> 新建 -> 已确认 -> 已计划/已解决/已关闭
|
+-> 需要更多信息
每个活跃项目应具备三个属性：
- 负责人：负责做出下一个决策。
- 下一步行动时间戳：使不活动状态可被查询。
- 回复路径：当报告者期望得到回应时使用。
如果没有这些属性，统一的收件箱仅仅创造了一个统一的忽略场所。
我们将构建的系统包含四个部分：
浏览器或应用
|
v
反馈应用程序接口 -----> PostgreSQL 数据库
|
v
事务性发件箱
|
v
通知工作器
|
v
聊天工具、电子邮件或问题追踪器
PostgreSQL 数据库是单一事实来源。聊天工具和电子邮件是交付渠道，而非数据库。
1. 存储反馈、上下文和交付状态
启用通用唯一识别码生成并创建三张表：
CREATE EXTENSION IF NOT EXISTS pgcrypto;
CREATE TABLE feedback (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
idempotency_key uuid NOT NULL UNIQUE,
source text NOT NULL CHECK (
source IN ('web', 'mobile', 'chat', 'email', 'api')
),
message text NOT NULL CHECK (char_length(message免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
