WebSockets

[jwoertink]

Purpose

Fixes #554

Description

I wanted to get the discussion moving on how WebSockets might look in Lucky. The idea here would be that Lucky provides a very basic interface to using WebSockets from the backend, but it would be up to the developer to implement the client side portion on their own with whatever tools they know.

This implementation tries to stick as close to current actions as we can while maintaining all of the type-safety features that Lucky gives us. It shouldn't feel like a ton of setup to get using.

Imagine you just generated a fresh Lucky app with this in it (maybe the wizard asks if you need websockets?), here is code that would be in your generated app:

# src/app_server.cr
def middleware : Array(HTTP::Handler)
    [
      Lucky::ForceSSLHandler.new,
      Lucky::HttpMethodOverrideHandler.new,
      Lucky::LogHandler.new,
      Lucky::ErrorHandler.new(action: Errors::Show),
      Lucky::RemoteIpHandler.new,
      Lucky::WebSocketRouteHandler.new, # <-- this line added
      Lucky::RouteHandler.new,
      Lucky::StaticCompressionHandler.new("./public", file_ext: "gz", content_encoding: "gzip"),
      Lucky::StaticFileHandler.new("./public", fallthrough: false, directory_listing: false),
      Lucky::RouteNotFoundHandler.new,
    ] of HTTP::Handler
  end

Then you add your action:

# src/actions/chats/create.cr
class Chats::Create < Lucky::WebSocketAction
  SOCKETS = [] of HTTP::WebSocket

  ws "/chats" do
    SOCKETS << socket
    socket.on_message do |message|
      SOCKETS.each do |s|
        s.send(message)
      end
    end

    socket.on_close do
      cleanup
    end
  end

  private def cleanup
    # cleanup socket
  end
end

And your JS:

document.addEventListener("DOMContentLoaded", ()=> {
  const room = document.getElementById("room");

  if (room) {
    const socket = new WebSocket("ws://localhost:5000/chats");
    socket.onopen = () => { socket.send("PING"); };
    const form = document.getElementById("form");

    form.addEventListener("submit", (e)=> {
      e.preventDefault();

      const input = document.getElementById("msg");
      socket.send(input.value);
      input.value = ""
    });

    socket.onmessage = (message) => {
      const chat = document.createElement("p")
      chat.innerText = message.data
      room.appendChild(chat)
    };
  }
});

Note

This setup "works", but it's still early planning stages. It'll probably change drastically before being ready for a real review.

Checklist

• - An issue already exists detailing the issue/or feature request that this PR fixes
• - All specs are formatted with crystal tool format spec src
• - Inline documentation has been added and/or updated
• - Lucky builds on docker with ./script/setup
• - All builds and specs pass on docker with ./script/test

[jwoertink]

My thought was by having these abstract, the websocket can proxy to them, and forces you to set these up. Websockets have a few other methods though.... are any of them as necessary? Is there ever a time you'd use a websocket and not use these?

[jwoertink]

If we don't make on_message and on_close abstract, then we can't guarantee they will exist which means we can't do this proxy. You'd just have to use them on your own. Not bad, but is this the better path?

[fernandes]

accepted_formats [:plain_text, :json], default: :plain_text doesn't make sense for a WS action

why does Chats::Index inherits from WebSocketAction, the behavior is totally different

[jwoertink]

@fernandes With websockets, would you ever need to send an Accept header to say the messages being passed back and forth are of any specific type? Or does that not matter? I'm wondering if there should be a default accepted_formats set? 🤔

Also, I inherited the action from a base class just because that's what you'd normally do in any other action. My hope here is that this can feel like the rest of the actions (i.e. BrowserAction, ApiAction). Then you could have all of your websocket actions inherit from the same parent class in case they all need to do something like ensure you're logged in before connecting or whatever.

[confact]

This comes in nice timing. I was actually planning to use @fernandes cable repo for this.

What I want in WebSocket support is:

• on message handling
• on connected handling
• on disconnect/close handling
• subscribe/channel handling

[fernandes]

@confact ohhh that's nice to hear! I'm working with @jwoertink in some stability/scalability issues, so I'd advice to not use in production atm, hope to fix this soon 🤞

anything you can ping me on lucky discord server 😉

[jwoertink]

I built a mini chat app using this setup over the weekend. Worked pretty well, but now I have a better idea of how I want to do this. It's going to require a TON more work than I originally wanted, but will be much better in the long run.

I'll try to get a PoC out to flesh out the details, but in the end, I think this may have to be a post 1.0 feature. For now, anyone coming to this looking for WebSocket support, use https://github.com/cable-cr/cable

[grepsedawk]

As part of this PR, I think you'll also need to add wss to the possibilities for https://github.com/luckyframework/lucky/pull/1662/files#diff-88f9201f12cf1493e98c2358834dbae535ac1be4d45fe1f01429dd526b280ecaR51

[jwoertink]

I have a better idea of how I want to do this
I'll try to get a PoC out to flesh out the details

I wish I would have done this 😭 I was going to come back to this, and I don't have any of that code I worked on now.... I guess I'll have to just re-imagine the whole thing 😮‍💨

[jwoertink]

Would need wss too

[jwoertink]

This would create a new handler for every websocket action you added. I'm not sure how many a person would add, but it seems like you should only have 1, and the handler would just route to each action based on where it connected. This looks like what Kemal seems to be doing too. A single instance that just adds each route and the handler.