The latest articles on DEV Community by Axioms of Singularity (@brawlerstats). https://dev.to/brawlerstats https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4070313%2Fe7a85b46-59dc-43de-8527-0357410ad249.png https://dev.to/brawlerstats en Axioms of Singularity Sun, 09 Aug 2026 23:17:19 +0000 https://dev.to/brawlerstats/how-i-built-brawlerstats-honest-trophy-history-with-firebase-and-cloud-run-4bl2 https://dev.to/brawlerstats/how-i-built-brawlerstats-honest-trophy-history-with-firebase-and-cloud-run-4bl2 <p>BrawlerStats started with a simple question: if a Brawl Stars profile is public, why is it still difficult to understand how a player is progressing over time?</p> <p>I built <a href="https://brawlerstats.com/" rel="noopener noreferrer">BrawlerStats</a> as a free, no-login companion for public Brawl Stars data. You can search a public player tag, review trophies and brawler progress, inspect recent tracked battles, open public club rosters, and create daily trophy races between players.</p> <h2> The stack </h2> <p>The frontend is intentionally lightweight: HTML, CSS, and JavaScript hosted on Firebase Hosting. The API runs as an Express service on Node.js in Google Cloud Run, with Firestore storing discovered profiles, ranking snapshots, clubs, and race history.</p> <p>That split keeps static pages fast while letting dynamic player pages, widgets, and sitemaps come from the service.</p> <h2> The hard part: history that does not pretend </h2> <p>The Brawl Stars API returns the current state. It does not hand you a complete timeline for every player and brawler. So BrawlerStats only charts snapshots that were actually captured.</p> <p>Race charts use daily closing values. If a player joins today, the chart starts today. When current live data is available, it is clearly marked as a live point instead of being silently rewritten into the historical series.</p> <p>This sounds small, but it matters. A smooth chart is not useful if it invents continuity.</p> <h2> Public discovery without accounts </h2> <p>BrawlerStats does not require a user account. A player tag is enough to open a profile. Public profile pages and share cards are generated with canonical URLs and structured metadata, while dynamic sitemaps expose discovered profiles to search engines.</p> <p>Club data follows the same rule: show a current roster when public data is available, and say when it is not.</p> <h2> Keeping the service efficient </h2> <p>The service reuses stored discovery records and batches scheduled ranking work instead of refetching everything for each page view. Scheduled jobs capture race snapshots and country-ranking samples, while the public site reads the latest verified snapshot and displays its refresh time.</p> <h2> What I learned </h2> <ul> <li>Current-state APIs need an explicit snapshot model before you can promise history.</li> <li>Honest empty states are better than interpolated data.</li> <li>Mobile layouts need separate verification; desktop success is not enough.</li> <li>Public pages, share images, widgets, and sitemaps are product features, not an afterthought.</li> <li>A fan tool should clearly disclose that it is independent and not affiliated with the game publisher.</li> </ul> <p>BrawlerStats currently supports English and German. It is an independent fan project and is not affiliated with Supercell.</p> <p>If you work on game-data tools, I would be interested to hear how you model sparse history or keep scheduled public-data refreshes efficient.</p> webdev javascript firebase gamedev