For example: Github, Twitter and Vimeo uses API rate limiting and will return ( in the response's headers ) something like this:
For now, I am dealing with Vimeo's API and it will allow ( 500 request per 15 minutes ) and I was thinking of doing it like this:
Should I uses the database to store these values ? or using something like radis cache to store them ( I don't know if radis will cache these values forever or what happens to these values if the cache size reaches its limit ? or is there a better way?
you need something that is persisted across multiple sessions so either database table, redis or a simple text file. It really depends how much activity you expect.
What are you going to do if the rate is exceeded? You might as. well just try the request and catch the error rather than trying to count if you have any requests left
The reason why I want to store how many ( requests left ) is because I am using Vimeo's API ( which will block my app, if I exceeded the limit repeatedly - It will not just send back an error ) so I need to store these information somewhere...
https://developer.vimeo.com/guidelines/rate-limiting
Is it reliable to store these info in redis cache? and use cache::forever
Yes redis is reliable and after all you don't care about anything that is more than 15 minutes old.
But what about ;
Store API responses locally, especially if you expect a lot of traffic. In general, don’t call the API on every page load. Instead, call the API independently and load from cache on each page load.
Store API responses locally, especially if you expect a lot of traffic. In general, don’t call the API on every page load. Instead, call the API independently and load from cache on each page load.
Yes, this will be helpful if I use GET requests, but I am using POST ( upload a video file ) and Delete ( a video file ).
in Laravel docs it says:
If you are using the Memcached driver, items that are stored "forever" may be removed when the cache reaches its size limit. https://laravel.com/docs/5.6/cache
Doesn't this apply on redis also?
Maybe, but the entries in the redis cache should not live more than 15 minutes?
You can use the redis expiry functions to remove entries that are over 15 minutes old and then all you need to do is count them to know if it is safe to make the api call.
If you can use queues and redis for this (sounds like you could), it has throttling built in and would fit what you're trying to do pretty much perfectly, as far as I can see.
It's as simple as telling the queue how often it can hit it within a given time period, and it will automatically adjust/delay things so it won't go over that limit.
if your application interacts with Redis, you may throttle your queued jobs by time or concurrency. This feature can be of assistance when your queued jobs are interacting with APIs that are also rate limited. For example, using the throttle method, you may throttle a given type of job to only run 10 times every 60 seconds. If a lock can not be obtained, you should typically release the job back onto the queue so it can be retried later:
Please or to participate in this conversation.