search

schachmat / wego

weather app for the terminal
ISC License
7.85k stars 477 forks source link

Data caching required to reduce API calls #196

Open VinVorteX opened 1 month ago

VinVorteX commented 1 month ago

Implement caching to reduce the number of API calls, especially if the user requests the same location multiple times.

VinVorteX commented 1 month ago

i would like to work on this feature

kordianbruck commented 1 month ago

I think the question is: is any of the api vendors actually complaining or are we doing this for users, because they are running into quota issue?

kordianbruck commented 1 month ago

Also: why don't we persist the cache into /tmp or disk at least? It seems that would be more useful as a long term solution that just an in-memory cache.

VinVorteX commented 1 month ago

For the API vendors, I think we’re mainly doing this for users who might run into quota issues. We want to help them avoid hitting those limits, even if the vendors aren’t complaining right now.

As for caching, using in-memory caching was a quick and simple solution for speed. It’s great for short-term use since weather data changes often. But I totally agree that persisting the cache in /tmp or on disk would be a better long-term solution. It would help users keep data across sessions and reduce loading times. I can definitely look into adding that feature in the future!

kordianbruck commented 1 month ago

As a oneshot terminal CLI in-memory cache does nothing. Once the program terminates, the cache is gone. So as implemented the code does nothing to my understanding. Without file persistence this makes no sense to me.

marcofeltmann commented 2 weeks ago

Interesting task. Yet which timeout should that cache have for invalidation? If you ask the same API for the same location over and over again you might receive to different results within a second.

The thing with weather is: It constantly changes. Hence the thing with weather forecasts is: They do, too.

Shouldn't each API have it's own "rate limiting" solution that the backends have to respect?

Like: First request the HEAD of the API, have a look at the "Last Modified" HTTP header and decide if you really want to download the body content.

Or have some "lastUpdated" endpoint for a location to get that same information.

You'll still call the endpoint every time the user wants to, yet save some bandwidth by only downloading larger amounts of data when things changed.

And: How does in-memory-cache work in an application that is started, downloads all the data, displays it and exits?