The `ActionCable.server.broadcast` call places a message in the Redis' pubsub queue under the broadcasting name of "web_notifications_1".
The channel has been instructed to stream everything that arrives at "web_notifications_1" directly to the client by invoking the
The `ActionCable.server.broadcast` call places a message in the Redis' pubsub queue under the broadcasting name of `web_notifications_1`.
The channel has been instructed to stream everything that arrives at `web_notifications_1` directly to the client by invoking the
`#received(data)` callback. The data is the hash sent as the second parameter to the server-side broadcast call, JSON encoded for the trip
across the wire, and unpacked for the data argument arriving to `#received`.
...
...
@@ -193,7 +194,8 @@ messages back and forth over the websocket cable connection. This dependency may
be alleviated in the future, but for the moment that's what it is. So be sure to have
Redis installed and running.
The Ruby side of things is built on top of Faye-Websocket and Celluiod.
The Ruby side of things is built on top of [faye-websocket](https://github.com/faye/faye-websocket-ruby) and [celluoid](https://github.com/celluloid/celluloid).
## Deployment
...
...
@@ -224,7 +226,7 @@ Action Cable will move from rails/actioncable to rails/rails and become a full-f
framework alongside Action Pack, Active Record, and the like once we cross the bridge from alpha
to beta software (which will happen once the API and missing pieces have solidified).
Finally, note that testing is a unfinished, hell unstarted, area of this framework. The framework
Finally, note that testing is a unfinished/unstarted area of this framework. The framework
has been developed in-app up until this point. We need to find a good way to test both the framework
itself and allow the user to test their connection and channel logic.