An equivalent of Phoenix Channels

[happysalada]

Hi, first of all, thank you for the great software!

I'm writing here to discuss an idea, not to ask for a feature.

Coming from Elixix/Phoenix, I feel one of the features that truly made it unique was the channels. You could ask from a client to subscribe to a particular topic through a websocket and be notified of the changes. The really killer feature was that you could communicate from outside that process and send some information. To clarify with an example, a user could subscribe to room:random_id and receive updates of the room. The killer feature being that if there was information external to that channel (some new movie that could be of interest to that room), then you could broadcast it as soon as the new movie was released (assuming that there is a way to know for the process releasing the movie who the potential interested rooms are).
It seems to me that the case of just having a channel open that users could send and receive message to could be implemented with a regular websocket. However the case of sending a message from outside of the websocket, seems to me that it could only be implemented with an actor model (since you need to a way to send messages to the socket) (I could be wrong on this one).
Both of those use case might not be common or might not be desirable. I was curious to know if those made any sense at all in rust and for this framework. (I've briefly looked at actor models, but there seems to be even less consensus than on the async runtime).

Thanks again!

[jbr]

Absolutely, #11 is on the horizon. I don't think an actor model is essential, trillium can use async channels like broadcaster or async-channel to communicate between different instances of handlers without introducing any lock contention

[happysalada]

Amazing!

Thinking about it more, for the channels to be externally addressable, you would need some kind of bus. That could be just a central channel that you keep in the State and that holds a hashmap of all the channel addresses with a sender to those.
So in essence I think I see why an actor model is not necessary. The only problem being is a panic happens somewhere (due to the person writing the code inside those channels being lazy for example) then you don't have the whole let it crash peace of mind. With rust though, you can have more guarantees on your code at compile time, so it might not be needed in the first place.

[jbr]

trillium-channels v0.1.0 has now been released, offering a phoenix-channels compatible backend for trillium