Yes, that's coming at some point soon.


When this feature goes live, in addition to our native and popular alternative realtime protocols, we will provide a dead simple streaming protocol which includes a unique message ID for each frame (message) delivered that is also a cursor.  This cursor can be used  to keep track of your position in the message stream for theoretically a limitless amount of time (this is only constrained by the TTL of your app history).


For example, consider an example HTTP stream as follows:


GET /channel/stream
=> message with ID: 123456
=> message with ID: 123457
=> message with ID: 123458
=> message with ID: 123459


-- connection closed by client --


A few hours later, you wish to resume the stream and have persisted the cursor / message ID:


GET /channel/stream?from=123459
=> message with ID: 123460
=> message with ID: 123461
=> message with ID: 123462


However, for the purposes of this example, we assume that when processing message with ID 123462, the backend server crashed. As such, the last successfully stored cursor would in fact be 123461.  The server when restarted would now send a new streaming request as follows:


GET /channel/stream?from=123461
=> message with ID: 123462
=> message with ID: 123463


And the failed message will be delivered again.


See https://www.w3.org/TR/2011/WD-eventsource-20110310/#last-event-id for an example of how a last event ID is used for SSE (Server-Sent-Events) to achieve a similar thing.


Get in touch if you would like to discuss your streaming requirements before our streaming offering is made available.