I have a service that pulls from a weather API which only allows me to call it 500 times a day as I can’t find any good free weather APIs that have hourly data. The service calls the api which returns a JSON array everytime the user hits the page as of right now.
Since I’m the only one using the service currently that is not a problem but for future I was hoping to cache search results and have them expire after an hour or two as the data just change rather frequently.
So if a user types in the their zip that result would be cached for 2 hours. If they pressed refresh it would pull the saved data from the cache or if another user came in and type the same zip it would pull from the cache.
What is the best way to cut down on the total API requests? I thought about using SQL but it seems it wouldn’t be a good fit since the data is somewhat dynamic and there are many different possibilities over 50,000+ zips.
Why not use a SQL database?
This seems fairly straight forward. The one thing to keep in mind, is to capture as much information as possible on each API call. If the API allows you to fetch more than just one piece of information at a time, fetch as much as you can so you don’t have to go back to the API.
Note: This solution does not get around the fact that you can only go to the API 500 times. It will simply provide a way for you to not have to go back to the API more than once per zip code.