问题
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
来源：https://stackoverflow.com/questions/42911942/actioncable-why-put-broadcasts-in-a-separate-job-for-forms-why-not-broadcast-f