Read recent history
The history API returns events and resume_from. It is the handoff to a live connection, not a next-page cursor.
Realtime browser events
SSE uses regular HTTP and native EventSource reconnects. WebSocket fits infrastructure built around upgraded connections. In MsgMesh both are downstream-only; publishing uses HTTP.
Quick choice
| Dimension | SSE | WebSocket |
|---|---|---|
| Direction | Server → client | MsgMesh is server → client only; upstream frames are discarded |
| Native browser reconnect | Built into EventSource | No; the official SDK handles it |
| Resume cursor | Last-Event-ID or the from parameter | Resume mode with the from parameter |
| Node.js | The JavaScript SDK stream() currently supports browsers only | Browser or Node 22+ |
| Best for | Notifications, dashboards, job progress, and common live views | Networks that block SSE or teams already operating WebSockets |
History and resume
The history API returns events and resume_from. It is the handoff to a live connection, not a next-page cursor.
SSE uses Last-Event-ID or from; WebSocket resume mode also uses from. The official SDK stores and returns the cursor.
At-least-once allows small overlaps. Official SDKs deduplicate by partition cursor; native API users must do this themselves.
Past retention or the 5,000-message replay limit, msgmesh-resync tells the app to rebuild a snapshot from its own system.
Browser security
Browser code and requests are inspectable. Long-lived keys do not belong in bundles, HTML, or localStorage.
Use your token-broker to issue a token for at most 15 minutes, limited by action, topic, and room.
With a token callback, the SDK refreshes before expiry and uses the new token after reconnecting.
Keep reading
No registration. Switch protocols, send one event, and observe the difference.