PokemonGoers / Catch-em-all

Now that we have tons of data about Pokemon (what they are, where they are, what’s their relationship, what they can transform into, which attacks they can perform, aso) we want to integrate it all into a comprehensive website. This website should contain sections about each Pokemon and its details. Additionally, the website should register the user’s location and tell the user how close is that the predicted pokemon to him/her. Additionally you will be incorporating the apps that were created by project B,C and D into the website. Your group will need to create automated builds and testing for this apps and use continuous integration to pull in new changes in the code repositories. Apps from projects B-D should be packaged and made available on NPM. Ideally when you completed these tasks the webapp component would integrate the apps by “requiring’ them. Here is a possible user story: when a user opens the website or the app the current location of the user will be shown. Additionally, the website/app will show automatically where the pokemons that are currently active are and where the pokemons that we predict to active in the nearest future (i.e. within half a day) will be located (all of this will be available from the app developed in project D). Hopefully, the website will be somewhat crowded by that data. Then, there needs to be a menu bar or something available (e.g. above the map or on the right side to it) that will list currently active or predicted pokemons. Clicking on one of them will make other pokemons on the map disappear, except of this clicked one. Separate web pages would allow the search and presentation of individual Pokemons and the information we gathered about them, including third party data (project A) and twitter analysis (project C)
9 stars 7 forks source link

Cache Pokémon predictions #93

Closed marwage closed 7 years ago

marwage commented 7 years ago

Hi ;) I'm from the predictions team and we would like to know if you cache our predictions when there is an equal request (location and time)? We are asking for that because predictions need processing power and therefore time. Have you already implemented something or are you planning to?

AlexanderLill commented 7 years ago

Hello @marwage,

as far as I know we are not planning to cache those predictions. It would make sense if your team @PokemonGoers/predictpokemon-2 could do that, e.g. by saving them in the mongoDb of team @PokemonGoers/pokedata or some other database.

Our team does not have any persistence layer yet and just uses the APIs from all other teams to gather data, so imho it would make sense if your API would cache those results.

What do you guys think? @PokemonGoers/catch-em-all

johartl commented 7 years ago

I agree with @AlexanderLill. As we don't have a database (or some other kind of storage) installed alongside our server the only way we could achieve caching would be locally on the client. This means that multiple subsequent requests by the same client can be answered by the cache but if different clients request predictions for the same location this would still result in multiple requests to your prediction API.

bensLine commented 7 years ago

Thanks for the heads up! If we cache them in the DB of @PokemonGoers/pokedata we would only store them for a short time, as we predict only for the current time. Is this correct @goldbergtatyana or do we provide predictions for which the user can specify the time?

sacdallago commented 7 years ago

Hey. I think that storing them in a db such as mongo would add a tremendous overhead. You can set TTLs on documents in mongo but it's tricky and I'd rather avoid that.

There are some out-of-the-box solutions for caching on the server side (usually storing a cache on disk), so if the predictions are serviced by the api guys (which, given the circumstances, seems to be the most reasonable solution), they can just import a package and cache requests that look similar for a given amount of time (which if I'm not mistaken, they are already doing, correct @PokemonGoers/pokedata ?) So: problem solved?

If you really wanna go fancy, you can even go redis but that's like mega overhead

goldbergtatyana commented 7 years ago

yep, I agree with @sacdallago, lets keep it all clear and simple :) No time specifications for a user and no storings of predictions in mongodb.

AlexanderLill commented 7 years ago

Created an issue in the @PokemonGoers/pokedata project: https://github.com/PokemonGoers/PokeData/issues/180

( @marwage @johartl @bensLine @sacdallago )