My Story with Coffee Chat Bot

This blog post is about Coffee Chats, how I got involved and my initial direction I took in managing the project

What is Coffee Chats?

Recently, I have had the honor of taking over maintenance of Coffee Chat Bot, a microservice used at the Recurse Center(RC) that randomly pairs community members for informal one-on-one chats. These conversations are an enriching part of the RC experience as it provides time and structure for people to talk to other Recursers about their lives, programming projects and other interests in an otherwise unstructured environment.

Coffee Chats is built as a node/express.js server that communicates with users through Zulip, a real-time communication platform used at the RC. The coffee chat server was hosted on Glitch and would get pinged every morning by to make matches for that day. It would then notify each user who their coffee chat match was via a bot on Zulip. This original project was started by a former Recurser, Sheridan, and was already widely in use when I started my first batch last winter.

Switching Hands

Like every good adventure, I had no idea where “maintaining” this project would ultimately lead me to when I first volunteered to take over the project. After all, I had inherited a working prototype and Glitch managed the server. There seemed to be very few pressing tasks that I needed to attend to in order to keep coffee chat running.

As the maintainer, I had the responsibility of informing new Recursers about the service and skipping matches on the first day of a new batch. These would have to be done manually, the latter being done by commenting out code in the Glitch online IDE. While Glitch’s online editor is cool since it both autosaves and auto updates the server, it seemed to be a more error prone way to make changes to a service that was already in use. As I began to ponder more about possible features to implement to improve the project, I came to the realization that I could not merely tack on additional code without a) likely breaking the working prototype or b) increasing the complexity of the code in a manageable way.

From Prototype to Robustness

I decided to take a step back, to think about how I could refactor and reorganize the original project in a more robust way.

The original project bundled all the business logic of making matches, updating records in the database, handling user requests, and notifying users via the Zulip server into a single server.js file. It was an obvious first step to decouple and modularize the code into separate files organized by their functionality.

Another idea I had was to convert the original JavaScript project to TypeScript. Some of the reasons were personal, in that I really wanted to work in TypeScript (I suppose I am a bit of a fanboy). But I really believe that the benefits you get from having a typed system in a larger, more complicated project usually outweighs the minimal complexity of adding in the TypeScript. These benefits also include documentation of your code for other developers as well as great error catching as you developer, especially while refactoring code.

Part of my initial hesitation to add any code features was the fact that it would be hard to see if I had introduced any regression bugs or not without having to call console.log and manually inspect the console. Ideally it would be nice to know as soon as I have code that introduces a bug that there is an issue with that code. While I think TypeScript does a great job at catching otherwise unexpected runtime errors, there is no substitute for tests. I have come to learn that if you love something and want it to work, then you have to write tests.

Another change that I decided to pursue during this reorganization process was to move hosting services from Glitch to Digital Ocean. While Glitch provides a pain-free and actually free-free hosting service, I wanted to gain more experience with the deployment and setup of a microservice.

Thus began my journey with Coffee Chat Bot.