Proposal: Websocket/Channel Mechanism

[gerred]

Proposal: Websocket/Channel Mechanism

Abstract

High-level constructs around websockets provide a framework within Buffalo for application developers to offer real-time features to their users. Currently, a raw websocket handler is exposed on the context. A higher level abstraction would provide event-style broadcasting, presence, and other features targeted at providing a productive real-time development stack for Buffalo developers.

Prior Art / Other Implementations

• Ruby on Rails ActionCable
• Phoenix Channels
• Socket.IO (especially event broadcasting)

Considerations

• Distribution of sockets in multi-node environments (backed by Redis? etc)

Implementation

Buffalo would provide a channels folder that specific channels could be created in. These would be exposed on a websocket, and would provide scoped send, receive, and broadcast access to the application. As part of this, a client-side channel implementation would also have to be written and added to the asset pipeline.

So far I don't have any further implementations or a PR, but wanted to at least start the discussion and get ideas rolling, plan upfront, and then spike an implementation that we can PR in.

[rpwatkins]

It would be great as well to have a mux implementation that can route socket message types (based on model and action) to handler functions similar to how the gorilla mux router routes paths/verbs to handler functions. In effect, a sort of subprotocol for the socket that will route a message (say for model "users" and action "create") to a handler function. This would require a standardised message protocol so that every socket message has a target model and action.

[nikoksr]

@sio4 what's the status on this?

[sio4]

Hi @nikoksr,

Thank you for the comment. Unfortunately, we have no solid plan for this proposal for now but I just put it into the proposal queue.