Create a Party With Ruby on Rails and the Vonage Video API – Part 2

Published May 13, 2020 by Ben Greenberg

This is the second part of a two-part series on creating a video watch party application using the Vonage Video API and Ruby on Rails.

In the first article, we went through the steps of building the backend of the app. If you have not read that post yet, it would be a good place to start. Now we are going to focus on the frontend of our application. While the backend was written mainly in Ruby, the frontend will be a lot of client-side JavaScript.

Once we are done, we will have a video watch party app that we can use to chat with our friends and watch videos together!

Landing Page

Let’s get started!

tl;dr If you would like to skip ahead and get right to deploying it, you can find all the code for the app and a one-click Deploy to Heroku button on GitHub.

Table of Contents

What Will We Be Building

Before we start coding, it is a good idea to take a moment and discuss what we will be building.

If you recall from the first post, we had instantiated a Video API Session ID, and are actively creating tokens for each participant. That information is being passed to the frontend by newly created JavaScript variables in the ERB view files. Additionally, we are also passing data from our environment variables to the frontend. We will be using all that information in the code we will write to create the experience of the app.

Ruby on Rails has come a long way in integrating client-side JavaScript directly into the stack with the introduction of Webpack in Rails starting with version 5.1. JavaScript is incorporated through packs placed inside /app/javascript/packs and added as either import or require() statements inside the application.js file inside the directory.

We will be separating out the various concerns of our code into different files so that at the end your folder will have the following files:

Each file, besides application.js, will contain code to cover distinct concerns:

  • app_helpers.js: Cross-functional code that is needed across the frontend
  • chat.js: Creating a Chat class that will be used to instantiate instances of the text chat
  • opentok_screenshare.js: The client-side code for the Screenshare view
  • opentok_video.js: The client-side code for the Video Chat view
  • party.js: Creating a Party class that will be used to instantiate instances of the video chat
  • screenshare.js: Creating a Screenshare class that will be used to instantiate instances of the screenshare functionality

Prior to creating the code, let’s add these files to the application.js file, which will instruct Webpack to compile them at runtime:

Creating the JavaScript Packs

In each subsection, we will create the JavaScript files that we enumerated above.

The app_helpers.js File

The app_helpers.js file will contain generic helper functions that we will export to the rest of the code to use throughout the app. We will create screenshareMode(), setButtonDisplay(), formatChatMsg(), and streamLayout() functions.

The screenshareMode() function will take advantage of the Vonage Video API Signal API to send a message to the browsers of all the participants that will trigger a window.location change. The Signal API is the same API we will use for the text chat, which is its simplest use case. However, as we will see in this function, the Signal API provides an intuitive and powerful way to direct the flow of your application simultaneously for all the participants without needing to write lots of code:

The next function, setButtonDisplay() changes the style for the HTML element containing the “Watch Mode On/Off” button to either be block or none depending on whether the participant is the moderator or not. There are many other ways to do this, including more secure methods. However, in order to keep things simple for this app to watch videos amongst friends, we will keep the keep minimalist:

The formatChatMsg() function takes in the text message the participant sent as an argument and formats it for presentation on the site. This function looks for any text bracketed by two colons and attempts to parse the text inside those colons as an emoji. It also appends the participant’s name to each message so everyone knows who is talking.

In order to add the emojis, we need to install a node package called node-emoji and we can do that by adding const emoji = require('node-emoji); to the top of the file and running yarn add node-emoji in the command line. The function will utilize match() with a regular expression to search for strings of text bookmarked by two colons, and if it matches, it will invoke the emoji const we defined to turn that string into an emoji:

The last function inside app_helpers.js we need to create is streamLayout() that takes in arguments of the HTML element and the count of participants. The function will add or remove CSS classes to the element depending on the number of participants in order to change the video chat presentation into a grid format:

The chat.js File

The chat.js code is going to create the Chat class using a constructor(). This Chat class will be called and instantiated in both the video chat and screenshare views:

We have given several properties to Chat, mostly based on different elemnts in the DOM and the Video API session. The last one, this.setupEventListeners() is invoking a function that we need to now add to the file:

setupEventListeners() creates an EventListener for the text chat submit button. When a new message is submitted it is sent to the Signal API to be processed and sent to all the participants. Similarly, when a new message is received a new <p> tag is added to the chat element, and the participant’s text chat window is scrolled to view it.

The next two files we will create perform similar functionality in creating new classes for the video chat party and for the screenshare view.

The party.js File

In this file we will create the Party class that will be used to instantiate new instances of the video chat:

The constructor() function is given the Video API session as an argument and passes that to this.session. The rest of the properties are defined and given values. The watchLink, subscribers, participantCount properties come from the HTML elements, while videoPublisher is provided a function as its value, and clickStatus is given default of off.

We will create the setupVideoPublisher() function at this point. The function invokes the Video API JavaScript SDK initPublisher() function to start the video publishing. It can take in optional arguments, and as such, we specify that the video should occupy 100% of the width and height of its element and should be appended to the element:

There are several actions we also must create event listeners for and add them to the class. We need to listen for when the session is connected, when a video stream has been created, when a connction has been added and when a connection has been destroyed. When a connection has been added or destroyed, we either increment or decrement the participant count, and share the number of participants in the participant count <div> element on the page:

Lastly, we add one more event listener. This event listener is attached to the click action on the “Watch Mode On/Off” button. When it is clicked it goes to the screenshare view, if the click status was off. You will recall that the click status is given a default of off in the construction of the class:

The screenshare.js File

The final class we will create is a Screenshare class that will be responsible for defining the video screenshare. The constructor() function takes the Video API session and the participant’s name as arguments:

Unlike the Party class, the clickStatus here defaults to on since we want to move away from the screenshare and back to the video chat mode, if the moderator clicks the “Watch Mode On/Off” button.

We also utilize toggle() to either share the participant’s screen, if the participant is the moderator, or subscribe to the screenshare for everyone else:

The shareScreen() function invoked in the toggle() needs to be defined:

This function itself has three functions that need to also be created. The first function will publish the screen of the moderator. However, the screen publishing by itself does not also include audio. Therefore, a second function will publish the audio from the moderator’s computer. Then, the final function in shareScreen() will move back to the video chat view if the “Watch Mode On/Off” button is clicked:

All the above is in order to create the screenshare for the moderator. Everyone else in the app will want to subscribe to that screenshare. We will use the subscribe() function to do that. This will be the last function inside the file:

We are now ready to make all these classes we have defined work in the application by creating instances of them inside the opentok_screenshare.js and opentok_video.js files.

Creating opentok_video.js

The opentok_video.js file will build a new video chat experience. Most of the work was done in the classes we defined above, so this file is relatively small. First, let’s import the Chat and Party classes:

Then, we will define a global empty variable to hold the Video API session:

Then we wrap the rest of the code in three checks to make sure we are on the correct website path, that the DOM is fully loaded and that the participant name is not empty:

The rest of the code initiates a new Video API session if one does not exist and instantiates a new Chat and new Party. At the end, we also listen for the Signal API to send a screenshare data message with the value of on. When that message is received the window.location is moved to /screenshare:

Creating opentok_screenshare.js

The last JavaScript file we will create is mightily similar to the last one. It is responsible for the screenshare view and leverages the Screenshare and Chat classes we defined earlier:

Before we can wrap this up, last but certainly not least, we need to define the frontend style of the application. All this code is useless if it is not accessible by the participants.

Styling the Application

The stylesheet for this application would not have happened without the help of my friend and former colleague, Hui Jing Chen who taught me a lot about front-end design through this process. The app primarily uses Flexbox Grid to order the elements.

Let’s start by creating a custom.css file inside app/javascript/stylesheets. We want to make sure that it is included in our application so add an import line to application.scss in the same folder, @import './custom.css';.

First, let’s add the core styling in custom.css:

Then, let’s add the styling for the landing page:

We also want to add the styling for the text chat, especially making sure that it stays in place and does not scroll the whole page as it progresses:

Now let’s create the styling for the video chat and screenshare elements:

Lastly, we will add a media query that will keep the text chat in proportion on smaller screens:

That’s it! The application, both the backend and the frontend, has been created. We are now ready to put it all together.

Putting It All Together

Even though the application is a combination of multiple programming languages, namely Ruby and JavaScript, with an intertwined backend and frontend, it is relatively straightforward to run it. This is because Rails allows us to seamlessly integrate it all together with one command.

From the command line, you can execute bundle exec rails s and watch your Rails server start. You will also see the following almost magical line in your console output the first time you run the app:

In fact, you will see that every time you make a change to any of your JavaScript or CSS packs. That output tells you that Rails is using Webpack to compile and incorporate all of your packs into the application. Once the [Webpacker] Compiling... is done you will see a list of all your compiled packs:

The file names reflect that they have been compiled down, but you can still see your pack names in there if you look closely, like opentok_screenshare, party, app_helpers, etc.

Running your application locally is great for testing with yourself, but you probably would like to invite friends to participate with you!

You can create an externally accessible link to your application running locally using a tool like ngrok. It gives an external URL for your local environment. The Nexmo Developer Platform has a guide on getting up and running with ngrok that you can follow.

If you would like to just get up and running, you can also deploy with one click this application from GitHub directly to Heroku. Click on the Deploy to Heroku button and within moments you will have a watch party app ready to be used and enjoyed.

I would love to hear what you built using the Vonage Video API! Please join the conversation on our Community Slack and share your story!

Leave a Reply

Your email address will not be published.

Get the latest posts from Nexmo’s next-generation communications blog delivered to your inbox.

By signing up to our communications blog, you accept our privacy policy , which sets out how we use your data and the rights you have in respect of your data. You can opt out of receiving our updates by clicking the unsubscribe link in the email or by emailing us at