Introduction to Talking to the Server

Communicating with the server is an important part of client-side apps. The server is usually the source of data truth, and it has information the client needs. For example, server information may have changed, or we may need updated data to draw a new part of the client application. The server also often needs to be informed of actions taken on the client.

In this chapter, we’re going to look at two basic ways of communicating with the server: making asynchronous Ajax calls and using WebSockets via the Rails ActionCable library. On the Stimulus page in our sample app, we’re going to get information from the server about which concerts are sold out. On the React page, we’re going to send and receive data about which seats in the concert have already been held.

However, before we dive into more complication of getting information from the server, I want to mention a quick and cheap technique that is sometimes exactly what you need: the Gon gem, which is a tool that allows your Rails server-side to set up arbitrary global data visible to your JavaScript client side.

Cheating with the Gon gem

No matter what else your app does, you always have one big moment of communication between the server and the client: the server sends down the initial page and its assets containing HTML, CSS, and JavaScript. In a typical Rails application the server manages the rendering of the initial page and its associated scripts.

The server could, perhaps, throw in an extra script tag with some global data that the JavaScript could then use. If this method of data transfer sounds appealing, the Gon gem is here to make this communication path easy to use. The Gon gem allows you to set some data in your controller, which you can then render in your view as global JavaScript and therefore be able to access from your client-side code.

You may be thinking that this is a terrible idea. The data that the Gon gem passes is global and unstructured, and there’s no way to use this channel to communicate back to the server. On the other hand, the Gon gem is very easy to use and explain. Data authentication is already being handled in the Rails controller, and using it saves you an HTTP connection that you might otherwise need to get your initial data.

Here’s how we might use it.

Let’s imagine we’d like to display real-time availability information on our schedule and concert pages. Right now we have static text reading “On Sale” next to each concert in the schedule. Let’s change that. Our first step, using the Gon gem, won’t give us real-time data, but we can use Gon as an example of how we might use server-side data on the client.

To use the Gon gem, we need to include it in our Gemfile:

gem "gon" 

And then bundle install.

There are two steps to using Gon. On the Rails side, we need to put data into a global object called gon, typically you’d do this in your controller.

What I’d like to do is have the server send a list of sold-out shows to the client. Then we’ll have a Stimulus controller catch that information and change the text from “On Sale” to “Sold Out.” In this particular case, we could just set the text to “On Sale” or “Sold Out” on the Rails side, but I’m imagining a world where we are continually updating this information on the client and using Gon merely to help us set the initial status.

In this branch of the code (server/01), I’ve added some Rake tasks to simulate ticket purchases. Right now we have rails nxns:reset_all_tickets, which changes the status of all the tickets in the system to unsold. (You do not want this task to exist in a real system.) And we also have rails nxns:sell_out_shows, which randomly picks three concerts and converts all of their tickets to sold.

If we run the second task at the command line:

$ rails nxns:sell_out_shows

the task will print the names of newly sold-out concerts to look at.

To use Gon to get this information into our TypeScript code, we need to update the show method of our SchedulesController, like this: