Create a Chat App with Rails 5, ActionCable, and Devise

Key Takeaways

• Rails 5 introduces ActionCable, a feature that seamlessly integrates WebSockets for real-time communication in your Rails application, enhancing interaction in applications like chat systems.
• Utilize Devise for user authentication in your Rails app, ensuring that access to chat features is secure and managed efficiently.
• Create and manage multiple chat rooms using Rails models and controllers, providing a structured way to organize conversations and maintain data integrity.
• Employ client-side JavaScript to enable users to send and receive messages in real-time without needing to refresh their browser, leveraging ActionCable’s subscription mechanisms.
• Integrate background jobs for broadcasting messages, which helps in managing the load and improving the performance of the chat application.
• Prepare and deploy your chat application to Heroku, including setting up necessary add-ons like Redis for managing live chat data and configuring environment variables for secure and scalable production use.

Rails 5 has introduced a bunch of new great features, but one of the most anticipated ones is of course ActionCable. ActionCable seamlessly integrates WebSockets into your application and offers both client-side JS and server-side Ruby frameworks. This way, you can write real-time features in the same styles as the rest your application, which is really cool.

Learn more on ruby with our tutorial Simulate User Behavior and Test Your Ruby App on SitePoint.

Some months ago I wrote a series of articles describing how to build mini-chat with Rails using AJAX, WebSockets powered by Faye and Server-sent events. Those articles garnered some attention, so I decided to pen a new part of this series instructing how to use ActionCable to achieve the same goal.

This time, however, we will face a bit more complicated task and discuss the following topics:

• Preparing application and integrating Devise
• Introducing chat rooms
• Setting up ActionCable
• Coding client-side
• Coding server-side with the help of background jobs
• Introducing basic authorization for ActionCable
• Preparing application to be deployed to Heroku

The source code can be found at GitHub.

The working demo is available at sitepoint-actioncable.herokuapp.com.

Preparing the Application

Start off by creating a new application. Support for ActionCable was added only in Rails 5, so you will have to use this version (currently 5.0.0.rc1 is the latest one):

$ rails new CableChat -T

Now add a couple of gems:

Gemfile

[...]
gem 'devise'
gem 'bootstrap', '~> 4.0.0.alpha3'
[...]

Devise will be used for authentication and authorization (you may read this article to learn more) and Bootstrap 4 – for styling.

Run

$ bundle install

Add Bootstrap’s styles:

stylesheets/application.scss

@import "bootstrap";

Run the following commands to install Devise, generate a new User model, and copy views for further customization:

$ rails generate devise:install
$ rails generate devise User
$ rails generate devise:views
$ rails db:migrate

Now restrict access to all pages of the site to authenticated users only:

application_controller.rb

[...]
before_action :authenticate_user!
[...]

Chat Rooms

The next step is to add support for chat rooms, so generate the following model:

$ rails g model ChatRoom title:string user:references
$ rails db:migrate

A chat room should have a creator, so make sure you establish a one-to-many relation between chat_rooms and users:

models/chat_room.rb

[...]
belongs_to :user
[...]

models/users.rb

[...]
has_many :chat_rooms, dependent: :destroy
[...]

Code a controller to list and create chat rooms:

chat_rooms_controller.rb

class ChatRoomsController < ApplicationController
  def index
    @chat_rooms = ChatRoom.all
  end

  def new
    @chat_room = ChatRoom.new
  end

  def create
    @chat_room = current_user.chat_rooms.build(chat_room_params)
    if @chat_room.save
      flash[:success] = 'Chat room added!'
      redirect_to chat_rooms_path
    else
      render 'new'
    end
  end

  private

  def chat_room_params
    params.require(:chat_room).permit(:title)
  end
end

Now a bunch of really simple views:

views/chat_rooms/index.html.erb

<h1>Chat rooms</h1>

<p class="lead"><%= link_to 'New chat room', new_chat_room_path, class: 'btn btn-primary' %></p>

<ul>
  <%= render @chat_rooms %>
</ul>

views/chat_rooms/_chat_room.html.erb

<li><%= link_to "Enter #{chat_room.title}", chat_room_path(chat_room) %></li>

views/chat_rooms/new.html.erb

<h1>Add chat room</h1>

<%= form_for @chat_room do |f| %>
  <div class="form-group">
    <%= f.label :title %>
    <%= f.text_field :title, autofocus: true, class: 'form-control' %>
  </div>

  <%= f.submit "Add!", class: 'btn btn-primary' %>
<% end %>

Messages

The main star of our app is, of course, a chat message. It should belong to both a user and a chat room. To get there, run the following:

$ rails g model Message body:text user:references chat_room:references
$ rails db:migrate

Make sure to establish the proper relations:

models/chat_room.rb

[...]
belongs_to :user
has_many :messages, dependent: :destroy
[...]

models/users.rb

[...]
has_many :chat_rooms, dependent: :destroy
has_many :messages, dependent: :destroy
[...]

models/message.rb

[...]
belongs_to :user
belongs_to :chat_room
[...]

So far, so good. Messages should be displayed when a user enters a chat room, so create a new show action:

chat_rooms_controller.rb

[...]
def show
  @chat_room = ChatRoom.includes(:messages).find_by(id: params[:id])
end
[...]

Note the includes method here used for eager loading.

Now the views:

views/chat_rooms/show.html.erb

<h1><%= @chat_room.title %></h1>

<div id="messages">
  <%= render @chat_room.messages %>
</div>

views/messages/_message.html.erb

<div class="card">
  <div class="card-block">
    <div class="row">
      <div class="col-md-1">
        <%= gravatar_for message.user %>
      </div>
      <div class="col-md-11">
        <p class="card-text">
          <span class="text-muted"><%= message.user.name %> at <%= message.timestamp %> says</span><br>
          <%= message.body %>
        </p>
      </div>
    </div>
  </div>
</div>

In this partial three new methods are employed: user.name, message.timestamp and gravatar_for. To construct a name, let’s simply strip off the domain part from the user’s email (of course, in a real app you’d want to allow them entering a name upon registration or at the “Edit profile” page):

models/user.rb

[...]
def name
  email.split('@')[0]
end
[...]

timestamp relies on strftime to present message’s creation date in a user-friendly format:

models/message.rb

[...]
def timestamp
  created_at.strftime('%H:%M:%S %d %B %Y')
end
[...]

gravatar_for is a helper to display user’s gravatar:

application_helper.rb

module ApplicationHelper
  def gravatar_for(user, opts = {})
    opts[:alt] = user.name
    image_tag "https://www.gravatar.com/avatar/#{Digest::MD5.hexdigest(user.email)}?s=#{opts.delete(:size) { 40 }}",
              opts
  end
end

The last two things to do here is to style the messages container a bit:

#messages {
  max-height: 450px;
  overflow-y: auto;
  .avatar {
    margin: 0.5rem;
  }
}

Add routes:

config/routes.rb

[...]
resources :chat_rooms, only: [:new, :create, :show, :index]
root 'chat_rooms#index'
[...]

Finally, preparations are done and we can proceed to coding the core functionality of our chat.

Adding ActionCable

Client Side

Before proceeding, install Redis on your machine if you do not already have it. Redis is available for nix, via Homebrew and for Windows, as well.

Next, tweak the Gemfile:

Gemfile

[...]
gem 'redis', '~> 3.2'
[...]

and run

$ bundle install

Now you may modify the config/cable.yml file to use Redis as an adapter:

config/cable.yml

[...]
adapter: redis
url: YOUR_URL
[...]

Or simply use adapter: async (the default value).

Also, modify your routes.rb to mount ActionCable on some URL:

config/routes.rb

[...]
mount ActionCable.server => '/cable'
[...]

Check that inside the javascripts directory there is a cable.js file with the contents like:

javascripts/cable.js

//= require action_cable
//= require_self
//= require_tree ./channels

(function() {
  this.App || (this.App = {});

  App.cable = ActionCable.createConsumer();

}).call(this);

This file must be required inside application.js:

javascripts/application.js

[...]
//= require cable
[...]

Consumer is a client of a web socket connection that can subscribe to one or multiple channels. Each ActionCable server may handle multiple connections. Channel is similar to an MVC controller and is used for streaming. You may read more about ActionCable’s terminology here.

So, let’s create a new channel:

javascripts/channels/rooms.coffee

App.global_chat = App.cable.subscriptions.create {
    channel: "ChatRoomsChannel"
    chat_room_id: ''
  },
  connected: ->
    # Called when the subscription is ready for use on the server

  disconnected: ->
    # Called when the subscription has been terminated by the server

  received: (data) ->
    # Data received

  send_message: (message, chat_room_id) ->
    @perform 'send_message', message: message, chat_room_id: chat_room_id

Here, we basically subscribe a consumer to the ChatRoomsChannel and pass the current room’s id (at this point we do not really pass anything, but that’ll be fixed soon). The subscription has a number of self-explaining callbacks: connected, disconnected, and received. Also, the subscription defines the main function (send_message) that invokes the method with the same name of the server and passes the necessary data to it.

Of course, we need a form to allow users to send their messages:

views/chat_rooms/show.html.erb

<%= form_for @message, url: '#' do |f| %>
  <div class="form-group">
    <%= f.label :body %>
    <%= f.text_area :body, class: 'form-control' %>
    <small class="text-muted">From 2 to 1000 characters</small>
  </div>

  <%= f.submit "Post", class: 'btn btn-primary btn-lg' %>
<% end %>

The @message instance variable should be set inside the controller:

chat_rooms_controller.rb

[...]
def show
  @chat_room = ChatRoom.includes(:messages).find_by(id: params[:id])
  @message = Message.new
end
[...]

Of course, you might use the basic form tag instead of relying on the Rails form builder, but this allows us to take advantage of things like I18n translations later.

Let’s also add some validations for messages:

models/message.rb

[...]
validates :body, presence: true, length: {minimum: 2, maximum: 1000}
[...]

Another problem to tackle here is providing our script with the room’s id. Let’s solve it with the help of HTML data- attribute:

views/chat_rooms/show.html.erb

[...]
<div id="messages" data-chat-room-id="<%= @chat_room.id %>">
  <%= render @chat_room.messages %>
</div>
[...]

Having this in place, we can use room’s id in the script:

javascripts/channels/rooms.coffee

jQuery(document).on 'turbolinks:load', ->
  messages = $('#messages')
  if $('#messages').length > 0

    App.global_chat = App.cable.subscriptions.create {
        channel: "ChatRoomsChannel"
        chat_room_id: messages.data('chat-room-id')
      },
      connected: ->
        # Called when the subscription is ready for use on the server

      disconnected: ->
        # Called when the subscription has been terminated by the server

      received: (data) ->
        # Data received

      send_message: (message, chat_room_id) ->
        @perform 'send_message', message: message, chat_room_id: chat_room_id

Note the jQuery(document).on 'turbolinks:load' part. This should be done only if you are using Turbolinks 5 that supports this new event. You might think about usng jquery-turbolinks to bring the default jQuery events back, but unfortunately it is not compatible with Turbolinks 5.

The logic of the script is pretty simple: check if there is a #messages block on the page and, if yes, subscribe to the channel while providing the room’s id. The next step is to listen for the form’s submit event:

javascripts/channels/rooms.coffee

jQuery(document).on 'turbolinks:load', ->
  messages = $('#messages')
  if $('#messages').length > 0

    App.global_chat = App.cable.subscriptions.create
    # ...

    $('#new_message').submit (e) ->
      $this = $(this)
      textarea = $this.find('#message_body')
      if $.trim(textarea.val()).length > 1
        App.global_chat.send_message textarea.val(), messages.data('chat-room-id')
        textarea.val('')
      e.preventDefault()
      return false

When the form is submitted, take the message’s body, check that its length is at least two and then call the send_message function to broadcast the new message to all visitors of the chat room. Next, clear the textarea and prevent form submission.

Server Side

Our next task will be to introduce a channel on our server. In Rails 5, there is a new directory called channels to host them, so create a chat_rooms_channel.rb file there:

channels/chat_rooms_channel.rb

class ChatRoomsChannel < ApplicationCable::Channel
  def subscribed
    stream_from "chat_rooms_#{params['chat_room_id']}_channel"
  end

  def unsubscribed
    # Any cleanup needed when channel is unsubscribed
  end

  def send_message(data)
    # process data sent from the page
  end
end

subscribed is a special method to start streaming from a channel with a given name. As long as we have multiple rooms, the channel’s name will vary. Remember, we provided chat_room_id: messages.data('chat-room-id') when subscribing to a channel in our script? Thanks to it, chat_room_id can be fetched inside the subscribed method by calling params['chat_room_id'].

unsubscribed is a callback that fires when the streaming is stopped, but we won’t use it in this demo.

The last method – send_message – fires when we run @perform 'send_message', message: message, chat_room_id: chat_room_id from our script. The data variable contains a hash of sent data, so, for example, to access the message you would type data['message'].

There are multiple ways to broadcast the received message, but I am going to show you a very neat solution based on the demo provided by DHH (I’ve also found this article with a slightly different approach).

First of all, modify the send_message method:

channels/chat_rooms_channel.rb

[...]
def send_message(data)
  current_user.messages.create!(body: data['message'], chat_room_id: data['chat_room_id'])
end
[...]

Once we receive a message, save it to the database. You don’t even need to check whether the provided chat room exists – by default, in Rails 5, a record’s parent must exist in order to save it. This behavior can be changed by setting optional: true for the belongs_to relation (read about other changes in Rails 5 here).

There is a problem though – Devise’s current_user method is not available for us here. To fix that, modify the connection.rb file inside the application_cable directory:

channels/application_cable/connection.rb

module ApplicationCable
  class Connection < ActionCable::Connection::Base
    identified_by :current_user

    def connect
      self.current_user = find_verified_user
      logger.add_tags 'ActionCable', current_user.email
    end

    protected

    def find_verified_user # this checks whether a user is authenticated with devise
      if verified_user = env['warden'].user
        verified_user
      else
        reject_unauthorized_connection
      end
    end
  end
end

Having this in place, we achieve even two goals at once: the current_user method is now available for the channel and unauthenticated users are not able to broadcast their messages.

The call to logger.add_tags 'ActionCable', current_user.email is used to display debugging information in the console, so you will see output similar to this:

[ActionCable] [test@example.com] Registered connection (Z2lkOi8vY2FibGUtY2hhdC9Vc2VyLzE)
[ActionCable] [test@example.com] ChatRoomsChannel is transmitting the subscription confirmation
[ActionCable] [test@example.com] ChatRoomsChannel is streaming from chat_rooms_1_channel

Under the hood Devise uses Warden for authentication, so env['warden'].user tries to fetch the currently logged-in user. If it is not found, reject_unauthorized_connection forbids broadcasting.

Now, let’s add a callback that fires after the message is actually saved to the database to schedule a background job:

models/message.rb

[...]
after_create_commit { MessageBroadcastJob.perform_later(self) }
[...]

In this callback self is a saved message, so we basically pass it to the job. Write the job now:

jobs/message_broadcast_job.rb

class MessageBroadcastJob < ApplicationJob
  queue_as :default

  def perform(message)
    ActionCable.server.broadcast "chat_rooms_#{message.chat_room.id}_channel",
                                 message: 'MESSAGE_HTML'
  end
end

The perform method does the actual broadcasting, but what about the data we want to broadcast? Once again, there are a couple of ways to solve this problem. You may send JSON with the message data and then on the client side use a templating engine like Handlebars. In this demo, however, let’s send HTML markup from the messages/_message.html.erb partial we created earlier. This partial can be rendered with the help of a controller:

jobs/message_broadcast_job.rb

class MessageBroadcastJob < ApplicationJob
  queue_as :default

  def perform(message)
    ActionCable.server.broadcast "chat_rooms_#{message.chat_room.id}_channel",
                                 message: render_message(message)
  end

  private

  def render_message(message)
    MessagesController.render partial: 'messages/message', locals: {message: message}
  end
end

In order for this to work, you’ll have to create an empty MessagesController:

messages_controller.rb

class MessagesController < ApplicationController
end

Back to the Client Side

Great, now the server side is ready and we can finalize our script. As long as we broadcast HTML markup, it can be simply placed right onto the page without any further manipulations:

javascripts/channels/rooms.coffee

[...]
App.global_chat = App.cable.subscriptions.create {
    channel: "ChatRoomsChannel"
    chat_room_id: messages.data('chat-room-id')
  },
  connected: ->
    # Called when the subscription is ready for use on the server

  disconnected: ->
    # Called when the subscription has been terminated by the server

  received: (data) ->
    messages.append data['message']

  send_message: (message, chat_room_id) ->
    @perform 'send_message', message: message, chat_room_id: chat_room_id
[...]

The only thing I don’t really like here is that, by default, the user sees old messages, whereas the newer ones are being placed at the bottom. You could either use the order method to sort them properly and replace append with prepend inside the received callback, but I’d like to make our chat behave like Slack. In Slack, newer messages are also placed at the bottom, but the chat window automatically scrolls to them. That’s easy to achieve with the following function that is called once the page is loaded:

javascripts/channels/rooms.coffee

jQuery(document).on 'turbolinks:load', ->
  messages = $('#messages')
  if $('#messages').length > 0
    messages_to_bottom = -> messages.scrollTop(messages.prop("scrollHeight"))

    messages_to_bottom()

    App.global_chat = App.cable.subscriptions.create
    # ...

Let’s also scroll to the bottom once a new message has arrived (because by default it won’t be focused):

javascripts/channels/rooms.coffee

[...]
received: (data) ->
  messages.append data['message']
  messages_to_bottom()
[...]

Great! Check out the resulting script on GitHub.

Pushing to Heroku

If you wish to push your new shiny chat to Heroku, some additional actions have to be taken. First of all, you will have install a Redis addon. There are many addons to choose from: for example, you could use Rediscloud. When the addon is installed, tweak cable.yml to provide the proper Redis URL. For Rediscloud it is stored inside the ENV["REDISCLOUD_URL"] environment variable:

config/cable.yml

production:
  adapter: redis
  url: <%= ENV["REDISCLOUD_URL"] %>
[...]

The next step is to list the allowed origins to subscribe to the channels:

config/environments/production.rb

[...]
config.action_cable.allowed_request_origins = ['https://your_app.herokuapp.com',
                                               'http://your_app.herokuapp.com']
[...]

Lastly, you have to provide the ActionCable URL. As long as our routes.rb has mount ActionCable.server => '/cable', the corresponding setting should be:

config/environments/production.rb

[...]
config.action_cable.url = "wss://sitepoint-actioncable.herokuapp.com/cable"
[...]

Having this in place, you can push your code to Heroku and observe the result. Yay!

Conclusion

In this article we’ve discussed how to set up ActionCable and code a mini-chat app with support for multiple rooms. The app includes both the client and server sides, while providing a basic authorization mechanism. We also employed a background job to power up the broadcasting process and discussed steps required to deploy the application to Heroku.

Hopefully, you found this article useful and interesting. Have you already tried using ActionCable? Did you like it? Share your opinion in the comments. Follow me on Twitter to be the first one to know about my articles, and see you soon!

Learn more on ruby with our tutorial Simulate User Behavior and Test Your Ruby App on SitePoint.

Frequently Asked Questions (FAQs) about Creating a Chat App with Rails 5, ActionCable, and Devise