TokShow: You can do it, put your back-end into it

Our goal for the back end of the TokShow application was to make it as simple as possible while supporting a couple thousand people.

The biggest concern for performance was moving a new fan on stage. When that happens, everyone in the TokShow needs to hit the server to get the connection ID of the next fan. We thought the ‘aha’ moment of a fan meeting the artist for the first time would be a major part of the experience, so making the transition smooth and simultaneous for all of the viewers was critical.

To keep things simple, we used PHP and MySQL on the server. There is very little state saved for the application. We basically need to know:

  1. Who is on stage
  2. Who is in the line
  3. Whether the show has started yet
  4. What time the show is scheduled to start.

We had one PHP file to wrap our reads and writes to the server, and that’s about it. For our TokShows we needed only one PHP server, which also hosted the database.

While relying on a single server will limit us at a certain size, our hope is to move off of this infrastructure and use the Session State API we are adding to the OpenTok API.

There are two big advantages that the new API gives this application. First, we do not need to manage a database or handle writes to the server. The only dynamic component left is generating authentication tokens.

Secondly, the State API removes the biggest scaling bottleneck we had, which was telling everyone who should be the next person on stage. Instead, notifications will be handled by an event in the API. Events in the OpenTok API will be faster than having all the participants making simultaneous AJAX requests, and a less powerful (and cheaper) server will be able to handle a large scale event.

As developers on the OpenTok platform, we’re excited by the possibilities the Session State API will give us to build scalable applications on a lightweight back end.