Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API: 429 too many requests #26

Open
bnjmnrsh opened this issue Dec 27, 2023 · 0 comments
Open

API: 429 too many requests #26

bnjmnrsh opened this issue Dec 27, 2023 · 0 comments
Labels
API Issues related to the shape of API bug Something isn't working enhancement New feature or request

Comments

@bnjmnrsh
Copy link
Member

The problem

It's pretty easy to hit the API too often when first exploring the app. Of course, once you visit a route, the local store object will be served to you as a cache, which is nice and fast. However, if the Cloud Flare cache headers are stale, once you look at just a few routes, we start hitting 429 errors.

One possible solution:

Short of paying for more access from the NYT

Create a CF Worker chron to cash all the routes cyclically, so there is always something 'hot' in its cache. The trick here is to spread out which endpoint is being requested at any given request and march through them one at a time.

Practically speaking, each time a CF worker runs, it would update the key for the last run call in a KV store, and each time it runs, increment through the array.

I think I would like to run this as a separate worker, but I am unsure if workers can share cache objects. For example, if the chron job worker can cache results our current worker can then return. If not, we could add another URL param flag to our current worker to trigger the chron. It's already quite long, however.

Timeframe comparison

If done sequentially, say every 30 minutes, it would take 14.5 hours for a CF Cron worker to get through all 29 routes (a bit long). If we did it every five min, it would take 2.41 hours to refresh the cache. To do the whole thing in under an hour, we will have to hit the API with a route every two minutes.

NYT API Limits:

500 requests per day / five requests per minute / 12-second delay between requests (or an average of 20.83 requests an hour)
https://developer.nytimes.com/faq#a11

So, to stay within limits while tracking 29 endpoints:

500 / 29 endpoints = 17.24 (max times a route can be called daily)
1,440min / 500 = 2.88min (a day divided by the max number of calls in a day)

To be a touch conservative of the API use, a call every 3 minutes seems reasonable.

Cloudflare limits (possible fly in the ointment)

On the free plan, you are allowed up to 5 chron triggers. I believe a trigger is a scheduler, not the number of times a chron job runs. So, one schedule that sets up a chron to run every 3 minutes appears to be within the usage of the free tier.

https://developers.cloudflare.com/workers/platform/limits/

Fallback 'chron' strategy

If im misunderstanding the usage limits for CF chron, then we could look to replicate the behavior with something like UptimeRobot, which can ping an endpoint as often as every 5 minutes on the free tier. It could it be possible to set multiple 'watchers', to do it more often, but we would have to add more checks to the worker to check how log it had been since a an API endpoint was pinged, so that we dont accidentally overload our usage.

bnjmnrsh added a commit that referenced this issue Jan 6, 2024
bnjmnrsh added a commit that referenced this issue Jan 6, 2024
bnjmnrsh added a commit that referenced this issue Jan 6, 2024
bnjmnrsh added a commit that referenced this issue Jan 6, 2024
…nges.

Reason for Commit: issues #32 #26 #27

Summary:

Notes:
@bnjmnrsh bnjmnrsh added bug Something isn't working enhancement New feature or request API Issues related to the shape of API labels Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Issues related to the shape of API bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant