Decide where to store/cache queried data

[cyrlop]

We need to decide where and how to store/cache queried data to avoid spamming Riot's API like you mentioned @kevinrue. I don't think there is a built-in solution in FastAPI. We can:

1. Use a NoSQL (document) database
   • Use MongoDB directly
   • We can use MongoDB with Pydantic models like explained here or here
2. Use cookies on the client side (annoying with regulations?)
3. Use files
4. Use a SQL database
   • If we choose this option, the best way is probably to use SQLAlchemy like explained here
5. Another caching option I didn't think of?

[kevinrue]

As I mentioned in #17 , I think we should only cache assets, not queries.

If we cache queries (e.g. table of champion names and IDs), it means we risk cross-referencing new queries (e.g. list of recent games) with old potentially out of date queries (e.g. list of champions when the app was deployed). If a new champion was added, it may not be present in the cache, and would cause problem if it's present in the list of recent games.

If we take the example of listing recent games and champions played:

• Query the list of N recent games, which includes the ID of champion played in each game
• Query the table of champions once
• Use that table to convert each champion ID into champion name

Which is basically two queries in this case.

Bad example:

• For each recent game, send a query to convert the champion ID into champion name (1 for the list of recent games + N queries to convert each champion ID)

Basically, it's just about designing our queries well, to minimise the number of queries that are sent each time users navigate to a new page, but not necessarily caching queries between pages.

[cyrlop]

Ok that makes sense for:

• The assets (solved in #17)
• Not blindly caching queries on a central DB to avoid using out-of-date data

Now should we close the issue for now or do you think we might might still need to store something?