请教一个前端暂存数据的问题

[yanz123]

我们有个功能会在前端记录客服的行为，积累了 5 分钟或者积累了 20 条记录就会调接口统一发到后端处理。
如果后端接口报错了，前端就会把这些记录继续暂存在前端，等接口恢复之后统一发给后端。
这种模式下前端可能会无限积累数据。
比较极端的情况是 前端把数据暂存在 localstorage 里面，localstorage 被修改后会有脏数据，这样前端把脏数据发到后端会报 4XX 错误，导致前端永远无法再调通后端接口，除非把 localstorage 清空。
不知道还有没有常见的情况会导致这种无法恢复的场景发生。
这种情况下通常应该怎么设计？
1.前端积累到一定的数据量之后，进入另一个逻辑，比如 100 条就分 5 段发送，有一段不成功就丢弃那段的所有数据？
2.不知道有没有更好的方法。

[a13761839322]

@yanz123 埋点感觉也没必要这种 积累上传...直接 img ping 的形式上报就行了
不行就是 indexDB + rxjs 定时 observable 和数量 合并，还可以用 web worker 不影响主线程（不过这样有点过度设计，大多数产品也没多大并发，直接一次次往后台扔得了

[Finnn]

Google analysis 的数据就是比较智能上报的, 数据出问题不能靠前端, 数据都到后台了后端也不处理的吗

[Finnn]

@Bijiabo 用来接收日志的功能接口就不应该返回给前端错误, 没有这样做的

[adoal]

后端返回 4 了前端还“自己感知不到”？正常设计里难道 4 不是表示后端正常、前端传的数据有问题？“如果后端接口报错了，前端就会把这些记录继续暂存在前端”，难道你们的设计是后端接口返回任何非 2/3 的代码前端都当成是后端出问题了？

[darlinghsu]

我们是统一收集发送，后端去存储，至于脏数据的问题自然有数据团队去做清洗和处理（也会和我们确认，写清理规则的时候

如果明确错误数据需要改进的，就再反馈回来 优化埋点。

[wellerman]

都 4XX 了，不就是前端问题了吗。后端再返回具体的错误码，前端根据具体的错误码去处理数据不就行了。

[joesonw]

4xx 丢弃，5xx 才保存呗。

[ArcherD]

用 graphql 和 relay 的话框架里面对于这些问题都覆盖了 参见 Fetch Policies ，Error States with ErrorBoundaries
后台不用 graphql 的话 就另说

[litchinn]

@darkengine 现在有 wasm ，浏览器都可以跑 postgresql

[gausszhou]

让后端改成只要接收到埋点数据就返回 200

[gausszhou]

另外无限积累数据可不行
1. 存储空间有限，localStorage 上限为 5MB
2. 随着数据变多，localStorage 读写和 JSON 序列化 会占用较多的 CPU 时间，影响用户网页的正常业务和性能指标。

[paopjian]

sqlite 现在支持 wasm,其实没必要累计记录数据吧,重要数据肯定 post 发了,不重要的日志扔给 mq 管他到底收没收到

[MMMMMMMMMMMMMMMM]

看起来客服平台应该是第三方的了
建议开个 ws ，这边发一条，直接同步发送到这个 ws 里去

如果担心后端 IO 压力的话，可以在后端处理接到多少条推送之后再统一插入数据库