Recent years have seen the rise of the real-time web. So what is real-time web?
The real-time web is a network web using technologies and practices that enable users to receive information as soon as it is published by its authors, rather than requiring that they or their software check a source periodically for updates.
Examples of the real-time web are Facebook’s newsfeed, Notifications, and Twitter, implemented in social networking, search, Chat Applications and news sites.
Apart from increased user engagement (“user experience”) real-time also decreases the load on the servers.
First, let us see some of the commonly used technologies that are used to achieve this. Then we will dive into how Ruby on Rails uses Action Cable to achieve real-time features that we have seen such as Real Time Messaging, Chat Applications etc.
Technologies Used In Real Time Applications
-
Polling.
Polling or Ajax Polling is the process in which the client periodically requests data from the server.
-
Long Polling.
In Long Polling the client makes a request to the server to load a resource, If it has the necessary data then the server responds with the data otherwise the request is held on to until the necessary resource is available.
Once the client gets the resource it restarts the process with the request. -
Server-sent events(SSE).
SSE is a standard where the client requests server for a resource, this request is held on to and subsequent iterations with this client will happen over the created connection via events.
-
WebSockets.
WebSockets are protocol built over the TCP/IP protocol. This allows the connection between the client and the server to be “bi-directional” (full-duplex).
-
Commet.
Commet is an umbrella term encompassing multiple techniques for achieving client-server interaction.
Having seen some of the common technologies behind Real Time applications, let us try to understand why we need Real Time applications and see how it is different to the classical approach.
What Are Real Time Applications?
Most webpages implement the HTTP (request/response protocol) to render HTML content from a server.
That is, a request is made to the server and the server responds with either the necessary data or a error.
Think of this as taking on a walkie-talkie only one of the participants gets to talk at a time. And usually, we need some means of communicating that one of the parties is “done”, (“over”).
Real-time implementations enable both (or all) of the participants to interact with one another simultaneously. Think of a telephone call, where users can talk at once with no restrictions.
With this basic understanding of what Real Time applications are, we can dive deeper into how Ruby on Rails implements it. Though Ruby on Rails maintainers took a long time to come out with this, I feel this inclusion of Action Cable is a more than a welcome move.
Introduction to Action Cable
Prior to the introduction of Action Cable Ruby on Rails, developers had to use 3rd party libraries such as faye or other technology stacks like Socket.IO on node.js, Elixir/Phoenix.
With the introduction of Action Cable as a full stack offering, Ruby on Rails developers now need not look for other technology stacks.
Action Cable implements Web Sockets. And as the documentation quotes
It’s a full-stack offering that provides both a client-side JavaScript framework and a server-side Ruby framework. You have access to your full domain model written with Active Record or your ORM of choice.
Action Cable Concepts
Action Cable utilizes the Pub/Sub approach for communicating data between the server and client(s).
Action Cable internally uses Rack Hijacking to take control of the connection that comes in from the application server and then manages the connections internally. So essentially for every instance of your application server, there is a hijacked version of the Action Cable instance.
Action Cable uses Redis as a data store for transient data, to sync content across instances. The following diagram explains the same.
Components of Action Cable:
i. Pub/Sub
Pub/Sub or Publish-Subscribe at the core is a message queue. Where Senders (Publishers) send data to a queue and Subscribers (Recipient) is listening for messages on a queue(s).
A simple way to visualize this would be to think of you viewing a program on a Television where you are the Recipient (Subscriber) and the TV channel is the Publisher (Sender).
ii. Connection
As you probably have guessed the client will be interacting with the server (Rails application) via a browser/mobile, the Rails application needs to know who has connected and has to maintain this connection in order for real-time communication to be possible. Thus Connections forms the fundamental foundation for a client-server relationship.
iii. Channels
Channels is a means of sending and receiving data. Technically it encapsulates a logical unit of work (either sending or receiving data) similar to what a
Controllerdoes (handle requests and sends responses).
Usually channels are defined based on the type of message they need to communicate.
Ex. All Chat messages can be transmitted via aChatChannel.
While there could be a channel that solely transmits data pertaining to who is online
(ApperaranceChannel)
A consumer could then subscribe to either or both the channels. (More on subscriptions below)
iv. Subscriptions
A user’s connection to a channel is considered as a subscription. Going back to the Television example from earlier, When you start watching a certain Television channel then it can be considered that you have a subscription to that channel.
v. Streams
Streams are a mechanism by which channel route the messages/data published to their subscribers.
vi. Broadcasting
Broadcasting is where anything transmitted by a publisher is routed directly to all the subscribers. Broadcasts are purely time dependent, that is if a consumer (subscriber) is not streaming (Subscribed to a channel) they will not be notified about the broadcast.
Again going back to the Television example you can relate to this as, Television channels are always broadcasting their shows, for you to be able to consume/view a particular channel (program) you have to have the television switched on and tuned to that channel otherwise content transmitted earlier will be lost.
I hope this short blog post gave you more insights into the working of Action Cable. I would also recommend the following blogs which give a good practical hands on, on how to use Action Cable.
Action Cable Projects and References
Friday Hug is a weekly round up of best articles, tutorials, analysis across the Web, hand curated by our Tech Team.
