B.A.R. Stats

Important! Use the username __Bear__ to test the PlayerStats page

Table of Contents

1. Overview
2. Role
3. Problem
4. Goal
5. Implementation
   • Data Collection
   • Frontend
   • Analysis
   • Operation
6. Thoughts

Overview

BarStats.pro is a tool for players of the game Beyond All Reason to analyze their gameplay as well as global trends within the game. Leveraging NodeJS on the backend to collect data, Postgres to store data, React/Remix for a stable and efficient frontend, and Kubernetes to orchestrate all the moving parts, BarStats.pro is a cross-discipline and fully-featured project.

👨‍💻 Role

Conceived, Designed, Developed, Deployed, Administrated

❓ Problem

Beyond All Reason players had no way to track their win rates across different maps, game types, match sizes, etc.

🎯 Goal

1. Create a site that presents match statistics to players quickly and simply
2. Use a local Postgres database to enable fast data presentation
3. Deploy without any cloud services onto a baremetal server using Kubernetes

✨ Implementation

Data Collection

Every thirty minutes, a Node application is spawned that scrapes the most recent match data from Beyond All Reason’s public API. Each scraped match is transformed into a format more appropriate for the local database. This is coordinated using a Kubernetes cronjob.

Frontend

For simplicity, I chose Remix. Other frameworks are overcomplicated for something like this, and Remix’s data handling model would work well here. All filtering is performed on client side, so that adjusting the filters after the initial query will be very quick.

Analysis

Once a day, a Node application is spawned that will process all matches in the database to aggregate data such as player count, faction breakdown, and game length. This analysis is also performed on the past month and the past week. The resulting data is saved as JSON in the Postgres database. (JSON columns in Postgres are surprisingly great) With this it will be possible to view day to day trends in gameplay.

Operation

I installed and configured microk8s, including a load balancer and ingress service, on a VPS. All of the services are deployed using kubernetes deployment files.

⚙️ Thoughts

1. I wish I had commited to TypeScript fully from the start. The backend applications don’t use TypeScript (frontend does), and I regret it every time I work on them. Oops!
2. A more robust CI/CD pipeline would have been ideal. Currently the modules are built and pushed to dockerhub using Github Actions, but I should have taken it a step further and auto-generated updated deployment files as well.
3. ChakraUI was a mistake. There were too many oddities and issues with it, and the jump from Chakra2 to Chakra3 is a huge undertaking.