Description
Extremely trivial operations in mit-tab, such as loading a single team's view, can result in 50+ DB queries. DB queries are very slow in the grand scheme of things. 1 or two are fine! 50 is borderline unacceptable. The hundreds of queries it takes to pair a round is unsustainable for a small app.
Memory access is very fast! We should cache much more aggressively than we currently do. I have two high-level ideas here:
Option 1: Decorators
Right now we have @cache() decorators, but the cache hit rate is very low since we only cache for a few seconds. In reality, statistics rarely change. We can use some sort of logical-timestamp based system to figure out when a cache entry is expired. Details to this would definitely need to be sorted out -- if it's a global timestamp, we need to know things like "when team A has a round updated, does that affect the ranking of team B," etc. If a team-based timestamp is possible and useful, that may be an option as well
Option 2: Wrap the entire DB access with an in-memory system
Ultimately we don't need to have that much data for one tournament, it should be pretty acceptable to have a process which just stores every result in memory and flushes to the DB for persistence. If all of the access goes through this source it should be lightning fast.