Possibly weapon stats like turf needed for special
User gear
I think we want a 3 part caching strategy for the stable data. Since the data is stable, we don't have to worry about invalidating the cache.
Cache to Disk
Read Data from a squidTracks firebase db
Get data from Splatnet
I'm not sure we want to push all the battle details to this db as then it'll be replicating functionality of stat.ink. I think I do want to at least push private battles.
For the unstable data, it's needed for historical reasons. We need the schedules to figure out what map modes league results correlate to and know what battles to group together in the last 50 battles section.
Records could be interesting for tracking a players progress in different map modes or with different weapons. Though it's possible stat.ink would be better for this kind of thing.
For the stat.ink hash tables, we need these to be updated dynamically, so there's more freedom for when to do releases. The on disk cache should be in invalidated if something is not found in the maps. Then the client can either try getting the hash map from the firebase db or from stat.ink.
I'll probably need to implement caching to disk of the battles to make exporting to csv work properly. Part of the groundwork was done in annie store branch.
I think there's 3 types of data we want to cache:
1. Stable Data
2. Unstable Data from Splatnet.
3. Other Data
I think we want a 3 part caching strategy for the stable data. Since the data is stable, we don't have to worry about invalidating the cache.
I'm not sure we want to push all the battle details to this db as then it'll be replicating functionality of stat.ink. I think I do want to at least push private battles.
For the unstable data, it's needed for historical reasons. We need the schedules to figure out what map modes league results correlate to and know what battles to group together in the last 50 battles section. Records could be interesting for tracking a players progress in different map modes or with different weapons. Though it's possible stat.ink would be better for this kind of thing.
For the stat.ink hash tables, we need these to be updated dynamically, so there's more freedom for when to do releases. The on disk cache should be in invalidated if something is not found in the maps. Then the client can either try getting the hash map from the firebase db or from stat.ink.