Pros and Concierge: How We Rebuilt HT Pros with ReactJS

One of HotelTonight’s differentiating features is HT Pros — a digital concierge service that connects bookers with live agents (aptly named “Pros”) through an in-app live chat. Capable of providing bookers with everything from local restaurant recommendations to extra toothbrushes, HT Pros has become one of our most popular features since we rolled it out of beta in April.

The growth of HT Pros, however, came with a few hiccups, mostly related to volume. The chat application used by Pros wasn’t originally built to work at such large scale — it was initially built just as an MVP. Since we needed to quickly adapt to the demand, we ended up patching and building on top of it. Moreover, after seeing how successful the chat system was becoming, we decided to add our customer service chat to the same application, which ended up complicating the UX for our Pros even more.

The problem started to surface during high-volume days; the chat function would become slow, buggy and difficult to manage. For example, when we approached around 400 active users, users would lose their place in the queue as the app automatically refreshed the chat lists. And by this point, we were experiencing that volume nearly every weekend.

Although these problems were something our Pros agents would handle gracefully, we didn’t want to push our luck as we grew it even more. We wanted to be able to handle even twice the maximum capacity of chats. To do this, we needed a fix that would require more than just a little tweaking and housekeeping. We decided to rebuild the functionality from scratch, switching from using a single Rails application for the entire chat system, to splitting out the front-end side of the application completely into its own application.

ReactJS: Breaking Up is Easy to Do

There were two main elements required to achieve what we wanted in scale and functionality: manageability and speed. Separating the front-end side as a ReactJS application and the API side as a Rails application allowed us to achieve both.

First and foremost, this allowed us to build very focused REST API’s in the backend application, while focusing on the user interface logic in a separate application. This way, both are more easily maintainable and testable. And given ReactJS is a JavaScript framework, the front-end logic would be much more organized (no more hunting down callback functions hidden in a random file somewhere!).

In addition, using ReactJS would allow us to achieve a faster and more reactive user experience. One of ReactJS’s main value propositions is its speed of updating elements on a page, as well as promoting usage of asynchronous calls.

There were a host of additional side benefits that we received from this change as well. For one, making changes to the application became much easier and we were able to improve our bug alerting integration. Though the coolest added benefit of having a backend that focuses just on api requests, in my opinion, is that other clients can consume that same API as well, making this code reusable by any channel! All very cool stuff.

Today, the HT Pros chat functionality runs smoothly at scale, helping bookers get whatever it is they’re looking for from their stay. And it’s not just our bookers that are satisfied — our Pros are able to more easily do their jobs. Separating the API and front-end with ReactJS was a huge success for us, and it’s put the application in the perfect position to expand the HT Pros service to even more of our bookers.