完善后端联调链路与模拟器多通道支持
This commit is contained in:
@@ -30,9 +30,29 @@
|
||||
|
||||
所以 backend 现在最重要的不是再扩散接口，而是把当前契约和语义收稳。
|
||||
|
||||
当前已确认不再阻塞主链的事项：
|
||||
|
||||
- `evt_demo_001` 的 release manifest 现已可正常加载
|
||||
- 小程序已能进入地图
|
||||
- 模拟定位 / 调试日志问题已回到小程序与模拟器侧，不再属于 backend 当前阻塞
|
||||
|
||||
前端当前需要配合的事项：
|
||||
|
||||
- 正式联调时始终以 `launch.resolvedRelease.manifestUrl` 为准，不再回退到本地样例配置路径
|
||||
- 如果再出现配置加载失败，反馈完整上下文：
|
||||
- `eventPublicID`
|
||||
- `releaseId`
|
||||
- `manifestUrl`
|
||||
- 页面报错文案
|
||||
- 控制台 / 网络日志
|
||||
- 当前 demo 联调建议统一使用：
|
||||
- `eventPublicID = evt_demo_001`
|
||||
- `channelCode = mini-demo`
|
||||
- `channelType = wechat_mini`
|
||||
|
||||
## 3. P0 必做
|
||||
|
||||
## 3.1 固定 session 状态语义
|
||||
## 3.0 固定 session 状态语义
|
||||
|
||||
需要 backend 明确并固定：
|
||||
|
||||
@@ -51,7 +71,7 @@
|
||||
- 小程序现在已经按这个方向接
|
||||
- 如果 backend 想改这 3 个状态语义，需要先讨论，不要单边改
|
||||
|
||||
## 3.2 明确“放弃恢复”的后端处理
|
||||
## 3.1 明确“放弃恢复”的后端处理
|
||||
|
||||
这是当前最值得后端配合确认的一点。
|
||||
|
||||
@@ -87,7 +107,7 @@ backend 需要确认的目标语义是：
|
||||
|
||||
- 如果 backend 认可这套语义，小程序侧下一步就可以把“点击放弃恢复”改成同步调用 `finish(cancelled)`。
|
||||
|
||||
## 3.3 保证 start / finish 幂等与重复调用安全
|
||||
## 3.2 保证 start / finish 幂等与重复调用安全
|
||||
|
||||
联调和真实环境里，以下情况很常见：
|
||||
|
||||
@@ -110,7 +130,7 @@ backend 需要确认：
|
||||
|
||||
- 不把客户端补偿逻辑变成一堆冲突分支
|
||||
|
||||
## 3.4 固定 `launch` 返回契约，不随意漂移
|
||||
## 3.3 固定 `launch` 返回契约，不随意漂移
|
||||
|
||||
当前客户端已经按下面这些字段接入：
|
||||
|
||||
@@ -130,9 +150,38 @@ backend 现在需要做的是：
|
||||
- 先保持这些字段名稳定
|
||||
- 如果要调整命名或层级，先沟通
|
||||
|
||||
前端当前需要做的是：
|
||||
|
||||
- 只消费当前已约定字段
|
||||
- 不额外推断 release URL
|
||||
- 不把本地样例配置路径混进正式 launch 流程
|
||||
- 如果字段缺失或命名变化，直接在联调清单里标阻塞
|
||||
|
||||
## 4. P1 应尽快做
|
||||
|
||||
## 4.1 增加用户身体资料读取接口
|
||||
## 4.1 给首页 / play / result 的 ongoing 语义再做一次回归确认
|
||||
|
||||
当前前端已经开始走：
|
||||
|
||||
- 首页聚合
|
||||
- `event play`
|
||||
- `launch`
|
||||
- `session start / finish`
|
||||
- 本地故障恢复
|
||||
|
||||
backend 建议再回归确认这几个接口对“进行中 session”的口径一致：
|
||||
|
||||
- `/me/entry-home`
|
||||
- `/events/{eventPublicID}/play`
|
||||
- `/sessions/{sessionPublicID}/result`
|
||||
|
||||
重点确认：
|
||||
|
||||
1. `cancelled` 后不再继续出现在 ongoing 入口
|
||||
2. `failed` 后不再继续出现在 ongoing 入口
|
||||
3. `finished` 后结果页与首页摘要字段一致
|
||||
|
||||
## 4.2 增加用户身体资料读取接口
|
||||
|
||||
小程序侧已经有：
|
||||
|
||||
@@ -152,7 +201,7 @@ backend 下一步建议提供：
|
||||
|
||||
这样后面心率页和消耗估算就能真实接业务数据。
|
||||
|
||||
## 4.2 给 `session result` 补一点稳定摘要字段校验
|
||||
## 4.3 给 `session result` 补一点稳定摘要字段校验
|
||||
|
||||
客户端现在会上报：
|
||||
|
||||
@@ -170,7 +219,7 @@ backend 建议补两件事：
|
||||
|
||||
不要因为某个可选字段缺失就整局 finish 失败。
|
||||
|
||||
## 4.3 dev workbench 增加一组“恢复 / 取消恢复”场景按钮
|
||||
## 4.4 dev workbench 增加一组“恢复 / 取消恢复”场景按钮
|
||||
|
||||
当前 workbench 已经很好用了。
|
||||
|
||||
@@ -182,6 +231,17 @@ backend 建议补两件事：
|
||||
|
||||
这会很适合配合小程序故障恢复联调。
|
||||
|
||||
## 4.5 前端预埋“放弃恢复”调用位
|
||||
|
||||
这项先预埋，不要先自行定语义。
|
||||
|
||||
前端建议准备好：
|
||||
|
||||
- 在“放弃恢复”按钮点击后，预留调用 `finish(cancelled)` 的位置
|
||||
- 但是否正式启用，要等 backend 把 `cancelled` 语义确认完
|
||||
|
||||
这样一旦 backend 确认语义，小程序就能快速切过去，不需要再改一轮页面流程。
|
||||
|
||||
## 5. P2 下一阶段
|
||||
|
||||
## 5.1 配置后台 source / build / release 真正开始做
|
||||
@@ -205,6 +265,23 @@ backend 建议补两件事：
|
||||
|
||||
这部分不是当前联调阻塞项，但后面会成为业务壳的重要组成。
|
||||
|
||||
## 5.3 兼顾未来 APP 的统一后端约束
|
||||
|
||||
backend 后续建设需要继续坚持：
|
||||
|
||||
- 不做“小程序专用后端”
|
||||
- 用户模型保持平台级
|
||||
- `event / release / session / result` 不按终端拆两套
|
||||
- 终端差异只通过上下文字段和运行时适配处理
|
||||
|
||||
建议优先保持：
|
||||
|
||||
- 业务接口统一
|
||||
- 配置发布结构统一
|
||||
- 结果沉淀结构统一
|
||||
|
||||
这样后面 APP 接入时不会推翻现有 backend 结构。
|
||||
|
||||
## 6. 需要先讨论再动的边界
|
||||
|
||||
这些事项 backend 不建议自己先拍板：
|
||||
@@ -252,4 +329,4 @@ backend 现在最值得先做的，不是扩接口，而是先确认下面 3 条
|
||||
|
||||
当前 backend 最重要的任务不是“再加更多接口”，而是：
|
||||
|
||||
> 先把 session 运行态语义和故障恢复放弃语义定稳，再继续扩后台配置系统。
|
||||
> 先把 session 运行态语义、放弃恢复语义和 ongoing session 口径定稳，再继续扩后台配置系统。
|
||||
|
||||
Reference in New Issue
Block a user