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?
I built BrawlerStats 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.
The stack
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.
That split keeps static pages fast while letting dynamic player pages, widgets, and sitemaps come from the service.
The hard part: history that does not pretend
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.
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.
This sounds small, but it matters. A smooth chart is not useful if it invents continuity.
Public discovery without accounts
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.
Club data follows the same rule: show a current roster when public data is available, and say when it is not.
Keeping the service efficient
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.
What I learned
- Current-state APIs need an explicit snapshot model before you can promise history.
- Honest empty states are better than interpolated data.
- Mobile layouts need separate verification; desktop success is not enough.
- Public pages, share images, widgets, and sitemaps are product features, not an afterthought.
- A fan tool should clearly disclose that it is independent and not affiliated with the game publisher.
BrawlerStats currently supports English and German. It is an independent fan project and is not affiliated with Supercell.
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.
Top comments (0)