Get an overview of ActionCable, an important new feature in Ruby on Rails 5. ActionCable is a framework for working with WebSockets. It allows real-time, full duplex communications between a server and client. It is ideal for streaming video, interactive content such as online games, and for real-time chat applications. It requires a constant connection between the server and client, but is faster and requires less data overhead once a connection is created.
- [Voiceover] One of the biggest new features in Ruby on Rails 5 is ActionCable. We'll talk about how to use ActionCable, but first let's talk about what it is, and why you might wanna use it. ActionCable is a framework for working with WebSockets, and it allows real-time features using a constant connection between servers and clients. Imagine a pipe that stays open between the server and the client while they're communicating, or you might think of a telephone call between two people. The web does not normally work this way. Typically a single request is sent to a server, and then the server responds to that request, and after that the communication stops.
It's good for real-time communications such as chat. Now, you may have experienced simulated real-time communications in Rails apps in the past, and that's done using polling. In other words, if we're in a chat room and we wanna know whether anyone has asked anything. Then every few seconds we just ask the server if anything new is up there. That's not how this works. This is not polling and making requests to find out if there's something new. It's actually communication between the client and server that's constant. Let's take a look at the differences.
In the typical HTTP model, data is being exchanged between the client and the server, and it's independent of them having a connection. Each time communication needs to happen, a new connection is created, and because of that, that data that's being sent has to be wrapped. It has to be wrapped inside request headers. Those request headers can be large. It can be one or two kilobytes of data that includes things like cookies, that the browser has stored. Even if the data is tiny, it still has to wrap it in these headers, and the server overhead goes both ways.
From the client sending data to the server, and from the server sending data back to the client. Now that's fine for a webpage, but for an online game it can be crippling, so what we find with the HTTP model, is that we have a great deal of independence, but it comes at the cost of overhead. The fact that we're having to send these headers wrapping the data back and forth, and what we get is this request-response cycle of communication. The client makes a request to the server, the server responds back to the client again.
Now with WebSockets, it's different. With WebSockets, the data is being exchanged between the client and the server, and it's dependent on having a pre-established connection, so we have to make a connection first, and then we exchange data over that connection. The headers are only sent at the start of the communication. That means that we don't have to have that same amount of overhead every time we swap a message back and forth. Once we set things up, we only have to swap data back and forth across the connection, so we have dependence on that connection, but allows for significantly less overhead.
It also allows for something called full-duplex communication. Instead of having this request response cycle that takes place with the HTTP model, now with WebSockets, we can exchange information back and forth and we can swap information back and forth at the same time, because the connection is open, the client can send information to the server at the same time as the server is sending information back to the client, so why would you wanna use WebSockets? Because there's less data overhead, which makes it much faster to swap data.
It allows for real-time full duplex communication. Now, WebSockets is not perfect for everything, because WebSockets does monopolize a server connection. No one else can talk to the server across that connection while it's in use. Even when nothing much is happening and a lot of data's not being sent. One of the reasons why the HTTP model is so great is that, that request-response cycle can serve more clients. I can make a request for a webpage. The server sends me the webpage, and then while I'm reading the webpage and deciding what I want my next decision to be, my next request to the server, it can go ahead and serve other clients in the meantime.
WebSockets also don't allow for page caching. With HTTP requests, with something like a webpage, we can cache that page and send it very quickly back to the client. With WebSockets we have to dynamically respond all the time, and in fact, most applications just simply do not require real-time communication, so ActionCable and WebSockets is a great solution for people who need real-time communication, but if you don't need it then you're probably better going off with a more traditional HTTP model.
- Using ActionCable to work with WebSockets
- Rendering templates independently of controllers
- Creating JSON API applications
- Using Turbolinks for faster page loads
- Working with new ActiveRecord features
- Leveraging improvements to date and time, parameters, and more
- Understanding deprecations and deletions