Rails ActionCable  - the good and the bad

Rails 5 has introduced WebSocket support via ActionCable, a significant move towards real-time functionality for the Rails community. While it helps remove boilerplate code and provides a simple API, developers should understand its strengths and weaknesses before deploying it in production environments. The architecture of ActionCable is based on Redis Pub/Sub feature, with each stream using a separate Redis channel. WebSocket connections are made from clients to the server, allowing data to flow in both directions between servers and client browsers or devices. ActionCable has several advantages such as simple connection objects and shared authentication, bi-directional Sockets, and Redis backend. It also supports common use cases like site notifications and alerts, single page apps, content streams, and live chat for websites. However, it also has some limitations including loss of connection state during abrupt disconnections, single point of failure backed by Redis Pub/Sub, latency issues due to geographical distance between servers and clients, and lack of acknowledgement or recovery mechanisms for message failures. Moreover, ActionCable does not support older browsers or devices where WebSockets are blocked, and it lacks platform interoperability and decoupling as there are no client libraries available for other platforms like iOS, Android, Go, Python etc. Performance testing revealed that connection time is not linear with ActionCable, and the time taken per server for publishing operations grows exponentially as workload increases. In conclusion, while ActionCable provides a significant step forward for Rails developers in terms of real-time functionality, it may not be suitable for all applications due to its limitations. Developers should consider these factors when deciding whether to use ActionCable or an alternative pub/sub messaging system.