bernie-sits
bernie-sits copied to clipboard
nicksawhney
Caching
The biggest cost for this site was API requests. Caching will help offset this greatly. It would be nice to cache from some kind of unique image identifier instead of input string, since different inputs can cause the same image to be returned.
looks like we can request metadata for free, and then maybe cache on lat/lng? https://developers.google.com/maps/documentation/streetview/metadata
@keevie Do you wanna go ahead and implement this in a PR? I can assign it to you if you'd like
Also this is great, goes nicely with the automated heroku deploy we've got going in the README https://github.com/nicksawhney/bernie-sits/discussions/22#discussioncomment-306946
hosting and api cost. Let's keep this discussion to how we want to implement caching.
Sure, I can take a crack at it -- I think I'm about done for the day though, so I might not get to it for a few days at least.
This is also going to be more dependent on where it's running than other things -- if you want to keep it tied to heroku that could make sense to me! That said I tried for a few minutes to get it running using that magic button and got a mysterious error, so I think it might need a little tweaking.
As for implementation details after thinking about it for a minute I think something dead simple with redis makes sense. We can turn persistence on and use pano_id as the keys, cache the images, and then just set whatever max size makes sense and an eviction policy of LRU or LFU.
The app code should be as simple as
pano_id = get_pano_id_from_google(location_string)
if redis.get(pano_id):
return redis.get(pano_id)
else:
image = get_image_from_google()
redis.set(pano_id, image)
return image
Looks great. Keeping it tied to heroku for now seems like a solid idea -- more deployment options can be added over time (a great first issue for interested contributors). if you're working on this in a fork I'd be happy to contribute there as well. I'll figure out the magic button errors.