Open AccCreate opened 4 months ago
Update: call is loading in 1.55 sec now
Maybe this is a non-issue. Did something change today? I was having this forever wait issue for like 2 weeks.
Maybe we should just have for older patches only return "All maps" information. 7+ mb for a json response seems completely unnecessary when no one is looking older than the most recent 1 or 2 patches.
Compression, etc. just seems overkill anyways. We can also just completely replace the current api call with this function call.
IGNORE THIS PR. Will need to update. Will update existing make-race-wins and have the query parameters directly. By default, will have no behavior change. Also, no longer facing issue so this PR isn't needed.
What it does: Prepare faster stats tab with limited patch history. By default limits to 3 most recent patch + names that cannot be parsed as patch (eg: All)
TODO: Update FE code to call "map-race-recent-wins" instead of "map-race-wins". Or just have this on map-race-wins by default.
GetRecentRaceVersusRaceStat(int n = 3)
I think https://www.w3champions.com/OverallStatistics/winrates-per-race-and-map page is too inefficient at calls nowadays It looks like that page calls all the tabs without needing to. If that change is too difficult, I think we should at least do some filtering on https://website-backend.w3champions.com/api/w3c-stats/map-race-wins
maybe by default only return the 3 most recent balance patches or something (to keep it simple). Seems the javascript page cannot take that much data.
A simple GET request javascript page shouldnt need to take multiple minutes.
ofc ideally we want to only call when necessary but that might be too much work for a volunteer work site.
is the codebase for w3c available? Just annoyed by how slow that page is. 611k lines of json code in one get request call doesnt seem ideal.
the laziest/shortest way to fix without touching FE is to just have BE only pass in 3 most recent patches or whatever for now (no need even for query parameters, etc). That can be done in like a few minutes top. I'm not expecting much (no need to modify FE code to optimize calls per button or whatever)
- Since this a document database (mongodb), there's no way not to get all the data as 1 document in the BE to database call. But there's nothing stopping BE from sending filtered data to the FE.
Testing (screw unit test cause no one else has it)