Idea: option to write all messages to table, not just >8kb

[bensheldon]

I wanted to suggest a configuration option to always write messages to the table (rather than only the ones over the size limit).

The reason is that would unlock "reliable streams" so that one could re-broadcast messages. for example, when subscribing to a channel, one could pass a timestamp and upon subscribe the channel would rebroadcast any messages to the subscription's streams after that time. This would address problems with the gap between a page being rendered on the server and successfully subscribing on the client.

I'm happy to implement this.

[dbackeus]

Is reliable streams a feature available in standard ActionCable via some other adapter or would this be a new concept for this particular adapter?

[bensheldon]

Reliable Streams isn't an Action Cable feature. It's the name of an AnyCable feature. I totally understand if that puts it out of scope for this project.

Just to discuss/sketch it, the changes I'm imagining are:

• Write every message payload to the database table. Still only broadcast payloads over 8kb, but have every message persisted a short period of time (2 minutes right now), not only the big ones.
• Add a channel name to the table. I don't think that would benefit from encryption like the payload, but it could be. Add an ordered index for [channel, created_at]
• Add a method that was like ActionCable::SubscriptionAdapter::EnhancedPostgresql.messages(channel_name, after: <created_at>) that would query the table and return all of the matching messages.

I think that is all that's necessary to effect a feature that was like (would require more patches in these methods too:

<%= turbo_stream_from @conversation, updated_at: @conversation.updated_at %>

class Turbo::ReliableChannel < Turbo::StreamsChannel

  def subscribed
    super
    
    ActionCable::SubscriptionAdapter::EnhancedPostgresql.messages(stream_name, after: params[:updated_at]).each do |message|
      transmit message.payload
    end
  end
end

[dbackeus]

Nice to know that there is some prior art to be found for this in AnyCable! 👍

I think the right approach for now is for you to start by trying this our in a fork and iron out an implementation in a production environment (provided you have a real world use-case for it).

After some time in production I'd be more inclined to consider this to become an integrated feature of this adapter.

The challenge for me is that, as I'm unlikely to have a production use-case for this myself, it could be troublesome for me to maintain the feature long term.