如何将Camunda异步回调结果从后端Service A传递至前端页面？

针对你描述的场景（客户端发起单次请求，后端异步处理完成后需要主动通知前端展示结果），以下是几种实用的实现方案，各有优劣，你可以根据场景选择：

1. 短轮询（Polling） #

• 实现方式：前端在收到Service A返回的“请求已受理”和唯一请求ID后，每隔固定时间（比如1~5秒）调用Service A的查询接口，传入请求ID查询结果状态，直到拿到最终结果或超时。
• 优点：零额外依赖，代码实现极简，所有浏览器都兼容，不需要后端做特殊配置。
• 缺点：存在大量无效请求，浪费服务器带宽和资源；结果展示有延迟，延迟时长等于轮询间隔。
• 适用场景：结果处理周期较短（比如几秒到十几秒），对实时性要求不高的场景。

2. 长轮询（Long Polling） #

• 实现方式：前端发送查询请求后，Service A如果未获取到结果，会挂起该请求不返回，直到结果生成或超时（比如30秒）；前端收到响应后立刻发起下一次查询请求。同样需要用请求ID标识对应任务。
• 优点：大幅减少无效请求次数，结果延迟比短轮询小；基于HTTP协议，无需额外技术栈。
• 缺点：服务器需要维护挂起的请求连接，高并发场景下会占用更多资源；超时后仍需重新发起请求。
• 适用场景：对实时性有一定要求，且不想引入复杂协议的场景。

3. Server-Sent Events（SSE） #

• 实现方式：这是HTTP原生支持的单向推送协议。前端在发起初始请求后，建立SSE连接并携带请求ID；Service A在收到Camunda的回调结果后，通过对应的SSE连接将结果推送给前端，推送完成后主动关闭连接。
• 优点：原生API支持，无需额外库；连接开销比WebSocket小，浏览器默认支持自动重连；完全满足单次推送需求。
• 缺点：仅支持服务器单向推送，无法通过该通道实现前端到服务器的通信；IE浏览器不支持（现代浏览器均兼容）。
• 适用场景：仅需要服务器单向推送结果，追求简洁实现和较低资源消耗的场景。

4. WebSocket #

• 实现方式：前端发起初始请求的同时，建立WebSocket连接并携带请求ID；Service A收到Camunda的回调结果后，通过该WebSocket连接推送结果，随后主动关闭连接。
• 优点：实时性最高，延迟几乎为零；支持双向通信，后续如果有交互需求可复用连接。
• 缺点：需要后端集成WebSocket功能（或单独部署WebSocket服务器），相比HTTP协议实现复杂度更高；单次推送确实存在一定的连接开销，但用完即关可有效降低浪费。
• 适用场景：对实时性要求极高，或后续有双向交互需求的场景。

5. 离线通知（补充方案） #

如果用户可能离开当前页面，可结合浏览器的Notification API或Push API实现桌面通知：

• 前端提前申请通知权限，当Service A拿到结果后，通过上述方式触发桌面通知，提醒用户查看结果。
• 优点：即使页面不在前台也能触达用户；
• 缺点：需要用户授权，Push API还依赖Service Worker。

选型建议 #

• 优先考虑SSE：兼顾实现简洁、低资源消耗和实时性，完美匹配单次推送的需求；
• 追求极致兼容性选短轮询：代码最简单，不用考虑浏览器兼容问题；
• 实时性要求极高选WebSocket：用完即关，不会造成过多资源浪费；
• 不想维护长连接选长轮询：比短轮询更高效，又无需引入新协议。

内容的提问来源于stack exchange，提问作者SorryForAsking