ActionCable: Why put broadcasts in a separate job?

2019-07-25 04:10发布

问题:

Most of the tutorials out there are slightly altered versions of an example app DHH put out over a year ago. Most of them share the habit of moving broadcasting out into a job. But A) Isn't that the point of Redis already? B) Since I'm using Delayed::Job wouldn't it just be faster to broadcast directly?

When creating a model, or submitting a form through ActionCable it doesn't seem to have CSRF protection. Does actively restricting the origins eliminate the need for protect_from_forgery? The gem's Readme has a link to a tutorial which adds a signed cookie, and I saw another tutorial which finds_verified_user from warden['env'].user. Does this address the problem that protect_from_forgery solves?

And if not: I thought I could submit the form to the controller as usual and then broadcast to all the subscribed users direct from the controller?But since it seems so simple but I haven't seen that anywhere I'm worried there's some reason. Is there?

回答1:

Just to be able to give this question an answer here's a Heroku tutorial using the same architectural idea that I want to use. So, from a design standpoint it doesn't seem like an anti-pattern anymore

https://blog.heroku.com/real_time_rails_implementing_websockets_in_rails_5_with_action_cable#step-2-broadcast-to-the-channel