@/all Hey everyone!
Here is the survey for AnyCable users: https://evilmartians.typeform.com/to/W35uRm.
We want to learn more about you to make this piece of software better)
Hi!
how do the steps below allow one to bypass that issue?
The described configuration assumes that you run both AnyCable RPC and AnyCable-Go on the same dyno. Thus HTTP2 traffic is running locally and is not affected by Heroku limitations.
Also, check the newer version of the docs: https://docs.anycable.io/#/heroku
Hi!
Currently, AnyCable provides this information only via anycable-go server instrumentation: http://docs.anycable.io/#/anycable-go/instrumentation
If you want to get this information from the Ruby app, you can make an HTTP request to the metrics endpoint and grab the anycable_go_clients_num from there.
Hi everyone. I have a design question. We are splitting our monolithic backend into smaller services. Suppose I have two Rails services (let's say A and B). Service A already uses AnyCable, handling the connection and providing some channels used by our Frontend. I want to make Service B broadcast some events through the same WS connection. It may implement a different Channel, for instance, a specific channel that only concerns the code of Service B. To this end, I think I can use the structure of the ActionCable's channels on Service B, right?
However, I think it does not make sense to implement any connection logic in Service B since Service A is already handling connections and authentication. What do you suggest?
Does anyone have experience in using a single WS server for multiple services (with different codebases)?
Hey!
That’s an interesting case.
Right now, out-of-the-box, the best option is to have a connection/server per service.
In theory, it’s possible to create a custom AnyCable-Go build with a kinda RPC routing: connect some channels to Service A and others to Service B. So, you’ll have two RPC servers, for each service, but only one WS server and thus, a single WS connection per client.
That’s something I have in mind for the future versions, to make this “routing” configurable and out-of-the-box. Currently, the only way to do this is to fork the project and write some Go code 🙂
class EventsChannel < ApplicationCable::Channel
def subscribed
@app = App.find_by(key: params[:app])
@user_data = get_user_data
@app_user = find_user
stream_from "messenger_events:#{@app.key}-#{@app_user.session_id}"
end
def send_message(options)
options.delete("action")
@app_user.visits.create(options) ## here it raise error, @app_user is nil
end
should I query again the authorization ,like something like this ?
def send_message(options)
@app = App.find_by(key: params[:app])
@user_data = get_user_data
@app_user = find_user
@app_user.visits.create(options)
endwell.. I can confirm that way will work, but it does not feel all right because I will authorize on every message, that will generate many queries to the database
Hi!
Yeah, instance variables are not supported.
You can perform authorization once only in subscribed method, and only fetch user and app records in send_message (from params). However I’m not quite sure by authorization.
Also, authorizing every action makes more sense: a user might have lost the access to the app but the connection is still open, so sending messages is possible.
def send_message(options)
@app = App.find_by(key: params[:app])
@user_data = get_user_data
@app_user = find_user
@app_user.visits.create(options)
end