Remaining monthly allowance
Remaining monthly allowance
So, it appears that the API has a monthly allowance for queries set to 1000...
"remaining_monthly_allowance":981
Isn't that a bit low? Depending on the application, that can be consumed in less than 1 day.
Just to get the genre list and platform list is 2 queries. Granted that doesn't need to be called every time they are needed, but it's still 2 queries deducted every time they are called.
"remaining_monthly_allowance":981
Isn't that a bit low? Depending on the application, that can be consumed in less than 1 day.
Just to get the genre list and platform list is 2 queries. Granted that doesn't need to be called every time they are needed, but it's still 2 queries deducted every time they are called.
Re: Remaining monthly allowance
We're asking dev to be considerate of their usage, the previous api was massively abused that neither the main site nor the api was in a usable state due to very occasional timeouts and incredibly long response times. the limit will be reviewed again in the future based on the usage and performance on the new api.
Regards
Zer0xFF
Zer0xFF
Re: Remaining monthly allowance
I'm all for rate limiting. Usually rate limits are per second, not per month.Zer0xFF wrote: ↑Thu Jul 05, 2018 12:45 amWe're asking dev to be considerate of their usage, the previous api was massively abused that neither the main site nor the api was in a usable state due to very occasional timeouts and incredibly long response times. the limit will be reviewed again in the future based on the usage and performance on the new api.
With a limit of 1000 calls per month, you're limiting people to a little over 16 calls per day (30 days, 2 queries per game, 1 for main info, 1 for screenshots/fanart).
IMHO that is extremely low.
Re: Remaining monthly allowance
160 calls per day by that logic, each request can process 20 calls.
We're curious to see how new projects use TGDB API.
If you have a new public project, please provide a link to it so we can highlight cool new applications!
If you have a new public project, please provide a link to it so we can highlight cool new applications!
Re: Remaining monthly allowance
Unfortunately my application only processes one request at a time. It's not something where multiple games can be retrieved at once.
It's based on the user inputing the TGDB link, it extracts the game ID from the link and processes it for other uses.
Re: Remaining monthly allowance
If you're not using arrays because of the app structure, that's something we can consider for the per-key limits. Right now we're mostly shaking out the bugs and globally curtailing excessive use, but in your unique case, they do sound a bit low.
We're curious to see how new projects use TGDB API.
If you have a new public project, please provide a link to it so we can highlight cool new applications!
If you have a new public project, please provide a link to it so we can highlight cool new applications!
Re: Remaining monthly allowance
Unfortunately I couldn't use the other type of key.
The application gets distributed to other web sites, and I couldn't include my key if it were the other type of key.
The application builds discussion threads about individual games in forums.
I honestly don't see a site going over the limit, but the possibility exists. There are some active sites out there.
The application gets distributed to other web sites, and I couldn't include my key if it were the other type of key.
The application builds discussion threads about individual games in forums.
I honestly don't see a site going over the limit, but the possibility exists. There are some active sites out there.
Re: Remaining monthly allowance
Ideally speaking, the app should draw from its own mirror, with API calls limited to syncing actually new data. That way, single-use "full syncs" could be used to bring the apps current, then API calls could keep them current, without forcing end-users to sync the entire site on every new installation. That's not even counting the scrapers that just parsed the entire site, resulting in massive performance hits.
The other benefit to having a dedicated mirror is that at no time is the app key out of your control, the app simply syncs to your mirror.
The other benefit to having a dedicated mirror is that at no time is the app key out of your control, the app simply syncs to your mirror.
We're curious to see how new projects use TGDB API.
If you have a new public project, please provide a link to it so we can highlight cool new applications!
If you have a new public project, please provide a link to it so we can highlight cool new applications!
Re: Remaining monthly allowance
That would just make the limits worse if I were to hold the info for hundreds of sites. The individual sites grab the data once from here and don't call the site again unless there's info missing, then a cron task checks for missing info once per day using the updates call.Leo_Pride wrote: ↑Thu Jul 05, 2018 10:11 pmIdeally speaking, the app should draw from its own mirror, with API calls limited to syncing actually new data. That way, single-use "full syncs" could be used to bring the apps current, then API calls could keep them current, without forcing end-users to sync the entire site on every new installation. That's not even counting the scrapers that just parsed the entire site, resulting in massive performance hits.
The other benefit to having a dedicated mirror is that at no time is the app key out of your control, the app simply syncs to your mirror.
Example done with old API...
https://yaketys.com/threads/diablo-iii- ... ouls.7755/
Re: Remaining monthly allowance
That's how top-down distribution works.
You mirror us, we limit you, your users mirror you, you limit your users.
You don't let your users hammer the site because you can't or won't maintain a proper mirror.
This whole idea that a centralised database is a permanent thing with infinite resources is fundamentally flawed, and the time where we let app design issues override the needs of well-behaved clients is over.
Remove the plank from your own eye before complaining about the speck in ours.
You mirror us, we limit you, your users mirror you, you limit your users.
You don't let your users hammer the site because you can't or won't maintain a proper mirror.
This whole idea that a centralised database is a permanent thing with infinite resources is fundamentally flawed, and the time where we let app design issues override the needs of well-behaved clients is over.
Remove the plank from your own eye before complaining about the speck in ours.
We're curious to see how new projects use TGDB API.
If you have a new public project, please provide a link to it so we can highlight cool new applications!
If you have a new public project, please provide a link to it so we can highlight cool new applications!