Websocket handler API limitations

[lpil]

Hello!

This is the current API for websocket handlers.

fn websocket_handler(
  message: websocket.Message,
  subject: Subject(HandlerMessage),
) -> Result(Nil, Nil) {
  Ok(Nil)
}

It's good but I think there's some limitations with it currently:

It cannot hold state as unlike the actor and gen_server abstractions there's no state parameters. Statefulness is a key feature of websocket sessions, for example, without it we could not implement LiveView in Gleam.

There is no way for the handler process to handle other messages beyond the ones from the websocket. Without this we could not implement things like pub-sub where we would want to send a message to many websocket processes so that they can each relay the message to their client.

The subject with with to reply is sent with each message, modelling a request-response relationship between messages. This means the process cannot send a message before receiving one. It's also slightly unusual as it implies that a different subject is to be used after each received message, but I think all the messages will be going to the same place. (Or could they directly write to the socket rather than using a subject?).

I think the solution here may be to use more-or-less the actor API for handlers. A handler is a normal actor which an init function (in which the mechanism for sending messages is injected, either a subject or some kind of socket writer type, and multiple messages can be subscribed to via a receiver), and a message handler function is invoked per message, giving the actor the chance to perform behaviour and also update state.

Thanks, Louis

[rawhat]

I mentioned this in the Discord, but I have some pending changes in glisten that should enable this pretty easily. Will update this when I get that in!

[rawhat]

I think this should be covered with the latest changes! Will be doing a release soon, but feel free to let me know if this doesn't cover it 😁

[lpil]

Thank you!!