Closed ArtOfCode- closed 7 years ago
I’d recommend passing parameters like the API key is currently passed so official ActionCable clients can still consume it easily.
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.
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 keywordchannel
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" }
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.
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:
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.