Remaining monthly allowance

Need help with your application? Ask here.
Snogs
Posts: 12
Joined: Fri Jun 29, 2018 9:06 am

Re: Remaining monthly allowance

Post by Snogs » Fri Jul 06, 2018 11:27 am

Leo_Pride wrote:
Thu Jul 05, 2018 10:44 pm
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.
Bear with me please. I'm trying to understand how my app might be misbehaving. And I don't see how it could hammer the site.

The way it is now..
1) User on a site enters a URL to a game
2) The game ID is extracted from the URL
3) The site makes an API call to TGDB for the info
4) The info is stored locally on the site and it is never called for again

What you're proposing...
1) User on a site enters a URL to a game
2) The game ID is extracted from the URL
3) The site makes a call to MY SITE for the info
4) My site makes a call to TGDB for the info
5) I store the info on my site
6) The info is stored locally on the original site and it is never called for again

Except in the unlikely event that several sites request the exact same game, TGDB still gets the same number of API calls either way. Or am I missing something obvious?

Leo_Pride
Posts: 330
Joined: Mon Apr 23, 2018 2:10 am

Re: Remaining monthly allowance

Post by Leo_Pride » Fri Jul 06, 2018 11:48 am

If an end user makes a single API request, then the 1000 calls per month per unique IP isn't an issue. If that IS an issue, your end users are making way more than single calls, and you should be providing them a proper mirror. Just scraping "on demand" with no consideration for other users isn't something that's going to continue.

Your site - in this case, more appropriately your mirror - maintains a subset of the data here, which it's hopefully been designed to make proper calls for 20,000 basic records - 40% of the database per month. How your users interact with your copy is then up to you, but at no time should they be directly using your app server's key.
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! 8-)

Snogs
Posts: 12
Joined: Fri Jun 29, 2018 9:06 am

Re: Remaining monthly allowance

Post by Snogs » Fri Jul 06, 2018 3:18 pm

Leo_Pride wrote:
Fri Jul 06, 2018 11:48 am
If an end user makes a single API request, then the 1000 calls per month per unique IP isn't an issue. If that IS an issue, your end users are making way more than single calls, and you should be providing them a proper mirror. Just scraping "on demand" with no consideration for other users isn't something that's going to continue.

Your site - in this case, more appropriately your mirror - maintains a subset of the data here, which it's hopefully been designed to make proper calls for 20,000 basic records - 40% of the database per month. How your users interact with your copy is then up to you, but at no time should they be directly using your app server's key.
I understand what you're saying and agree with you for the most part.

In this case, would you suggest I have the end users obtain their own API key? That's what I do for The Movie Database, The Audio Database and IMDB.

Or just leave it as is with my key embedded in the software and let the IP rate limits handle everything?

EDIT: I spoke incorrectly. The Audio DB uses my key by their request. They didn't want to issue keys to individual sites.

User avatar
Zer0xFF
Posts: 240
Joined: Fri Apr 20, 2018 9:18 am

Re: Remaining monthly allowance

Post by Zer0xFF » Fri Jul 06, 2018 10:20 pm

In this case, would you suggest I have the end users obtain their own API key? That's what I do for The Movie Database, The Audio Database and IMDB.
NO, your key will operate as a rate limit per IP for your users, thats the whole point of the public key.
users having their on key will have the exact limit imposed by using your key, everyones request and limits are their own not shared between everyone.

so yes, the IP rate will handle it, but it might be a good idea of showing the user their limit so they know not to over do it, with that said, it might be a good idea on my behave to disable when is the limit will be rest for you to show to users.

a private key, which we haven't release yet, is the kind of key that will have 1 pool of shared request limit.
Regards
Zer0xFF

Snogs
Posts: 12
Joined: Fri Jun 29, 2018 9:06 am

Re: Remaining monthly allowance

Post by Snogs » Fri Jul 06, 2018 10:25 pm

Zer0xFF wrote:
Fri Jul 06, 2018 10:20 pm
In this case, would you suggest I have the end users obtain their own API key? That's what I do for The Movie Database, The Audio Database and IMDB.
NO, your key will operate as a rate limit per IP for your users, thats the whole point of the public key.
users having their on key will have the exact limit imposed by using your key, everyones request and limits are their own not shared between everyone.

so yes, the IP rate will handle it, but it might be a good idea of showing the user their limit so they know not to over do it, with that said, it might be a good idea on my behave to disable when is the limit will be rest for you to show to users.

a private key, which we haven't release yet, is the kind of key that will have 1 pool of shared request limit.
Thanks for clarifying that.

I am showing the admins of the sites their remaining limit based on the 'remaining_monthly_allowance' response from the API..

Monthy API queries remaining: 988

Leo_Pride
Posts: 330
Joined: Mon Apr 23, 2018 2:10 am

Re: Remaining monthly allowance

Post by Leo_Pride » Fri Jul 06, 2018 11:06 pm

Yep, we reset it for you because the malformed calls on our end still counted against it.
We're not unreasonable. :D
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! 8-)

RVDSoft
Posts: 7
Joined: Thu Jul 05, 2018 8:37 am

Re: Remaining monthly allowance

Post by RVDSoft » Wed Jul 11, 2018 11:25 am

Leo_Pride wrote:
Thu Jul 05, 2018 9:24 pm
160 calls per day by that logic, each request can process 20 calls.
How do you make a request with multiple calls?

gforceca
Posts: 4
Joined: Tue Jan 15, 2019 4:42 pm

Re: Remaining monthly allowance

Post by gforceca » Fri Feb 01, 2019 2:17 pm

I second, I ran out of Remaining Requests doing the initial mirror of the DB. Anything can be done?

Leo_Pride
Posts: 330
Joined: Mon Apr 23, 2018 2:10 am

Re: Remaining monthly allowance

Post by Leo_Pride » Sun Feb 03, 2019 7:24 am

This is where you're supposed to use your private key.
The public key is for testing and end-user usage, and has a significantly lower limit.
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! 8-)

Post Reply