Make everything available on the API websocket

[ArtOfCode-]

TL;DR: for all models (with security measures), send creates and updates to the API websocket.

Currently, we only send a select amount of stuff down the API websocket. I've heard a number of times over the past few timescales that X wants Y other thing sent down it. Debate then ensues about whether it's worth doing it for the number of people who will actually use it.

I propose we make everything (within limits, of course - no sending secure fields) available across the websocket, filterable by clients on connection. For example:

GET /cable?events=flag_logs;posts;feedbacks HTTP/1.1
Host: metasmoke.erwaysoftware.com

would result in a WS upgrade to a socket that only sends that specific client creates and updates for flag logs, posts, and feedbacks - and nothing else.

This solves issues of both bandwidth and having to make things available case by case.

I have an idea or few of how to do this, but if I'm doing it it'll need to wait until I get back from holiday.

[j-f1]

I’d recommend passing parameters like the API key is currently passed so official ActionCable clients can still consume it easily.

[ArtOfCode-]

Sure, I just don't know how that is so I couldn't use it in an example. That's just the initial HTTP request, not the WS upgrade handshake.

[j-f1]

https://github.com/rails/rails/tree/master/actioncable#passing-parameters-to-channel:

You can pass parameters from the client side to the server side when creating a subscription. For example:

# app/channels/chat_channel.rb
class ChatChannel < ApplicationCable::Channel
  def subscribed
    stream_from "chat_#{params[:room]}"
  end
end

If you pass an object as the first argument to subscriptions.create, that object will become the params hash in your cable channel. The keyword channel is required.

# Client-side, which assumes you've already requested the right to send web notifications
App.cable.subscriptions.create { channel: "ChatChannel", room: "Best Room" }

[ArtOfCode-]

Would have to confirm, but I suspect those end up as the query string on the HTTP request. Anyway, we probably don't need to go into implementation details yet.