I was super excited to finally be able to use ActionCable for a new project (late to the party!) but was a little bewildered that guaranteed message delivery (and delivery ordering) wasn’t baked in. Messages are not delivered unless a client is connected at the time the message is broadcast, even if they reconnect shortly afterward.
I know this would make ActionCable heavier (it’d need to hold on to messages longer, and also keep track of delivery status for each subscribed user) but I think this would be a good feature to add.
https://logux.io has already solved most of the details around this, but they’re trying to solve a much deeper problem there (concurrent editing). Their strategies for message recovery look good though.
I think a great outcome would be for the message_bus gem to ship a “back-end / front-end adapter” for ActionCable, that way you could just install the gem to get reliable messaging for free. If anyone wants to work on this … let me know.
Over the years Rails has been very open to … opening up the menu so I am sure if someone was keen to take on such a project the team would be open.
I’m excited that @julianrubisch has a functioning alpha implementation of StimulusReflex - and by extension, ActionCable - working with message_bus in this PR.
@samsaffron, in all my searching I never came across message_bus! Possibly because I was looking for alternative web socket solutions. I’ll definitely take a look at it though
Is there a reason message_bus doesn’t use web sockets as a transportation option?
@leastbad, Interesting to see that PR. I’ll keep an eye on it.
