I have a few questions about making web requests and how they effect rate limiting.
So basically I have a web application that is going to want to make many requests to the twitch api. It does this for reasons such as the ability to log in with twitch and nice features etc…
Currently however in order to do something as simple as say, have the user see their twitch profile avatar when they are logged in, they have to ask me (the web app) who they are and where their profile picture is located, and my server has to make a api call to twitch to figure that out (I am caching btw). But the point is, that causes latency on my end either due to a twitch api call a database call or whatever.
So my goal is to share some of the api load with the users browser but I am unsure of the implications of that. So here is my questions about that.
In order to make api requests from the browser, would I have my web app send the browser my client id and they just use that?
If every time a user opens a page on my site (or clicks a link to another page on my site) and wants to find out the location of their profile picture, they would need to make another request, could this cause scaling issues with many users or is there a way to in the browser cache the twitch data between page loads. (i guess this is partially a question about js)
If a malicious user decides to take my client id and spam api calls with it, will that cause an issue with twitch/inturrept usage from my web app or other users, and how would I deal with that?
If a user has granted me an oauth token, is it beneficial to send to them to make api calls rather than my client-id?
If I have mixed usage of token using request and just request using the client-id from the browser, how will that effect the 30/120pm rate limit on helix?
Lets say I got a little bit crazy and added the ability to add a twitch user to some sort of group, and the field would autocomplete twitch users (simmilarly to the search bar on twitch.tv). Could the rapid api calls to both get users with simmilar names and then find their profile picture to put next to them as the user types cause an issue? This relating to high browser side usage like in #3.
The main point of this is to reduce the amount of api calls made to my webserver from the browser app, as well as reduce my session variable sizes and cache size, because my web app as is largely acts like a relay for data from twitch to my browser front end, and that increases latency and load times tremendously, even when I run the server on my local machine. So any advice anyone has on offloading server api access to the browser client would be appreciated.
Client ID’s are limited on what they can do with the Twitch API. Auth Tokens which are generated when a user logs into Twitch through your Twitch App and can allow you to do a lot more with the Twitch API on behalf of the user because they permitted it. So yes, to make requests from the browser you would need to send your Client ID or Auth Token to make requests from there.
When a user authenticates your app, that is when you should make a request to get basic information about the person authenticating your app. This would include the url to their profile picture which would be best stored in the users browser. Then when the user visits your web app again you can pull the url from their storage and embed it in an image tag which would cause the browser to make a request to obtain the image from Twitch on behalf of the user rather than your service.
Unfortunately, every time you require someone to log in with your Twitch App your Client ID is exposed in the url. If someone decides to use your Client ID with malicious intent then yes it could effect your Twitch App’s rate limit and usage.
4.This was partially answered from the first question but it would be best to use Auth Tokens for users because Client ID’s are limited on what they can do with the Twitch API. Auth Tokens can do quite a lot more based on what permissions where granted to them.
I have not messed with the Twitch API in a long time so I cannot give you an accurate answer but from what I pulled up on Twitch’s API documents I would assume this
Each client ID is granted a total of 30 queries per minute (if a Bearer token is not provided) or 120 queries per minute (if a Bearer token is provided), across all new Twitch API queries. If this limit is exceeded, an error is returned: HTTP 429 (Too Many Requests).
Bearer token being the Auth Token I was talking about in my past answers.
I’m not sure if Twitch disclosed an endpoint on their API that will allow you do a search of users based on keywords. They do offer a search on users but you have to be exact on the name which would always return a single user rather than multiple users. Unless they changed that because like I said I have not messed with their API in a long time.
Hopefully I have answered most of your questions and if not, hopefully someone else can.
Let me try to answer some of these from my point of view.
Yes, you can do that. That of course has the smallest rate limit and you might consider creating a key that is tied to an authorized Twitch account.
I do something like this with the profile picture. I cache the URL that Twitch returns and only update after 24 hours. This reduces the number of hits on the Twitch API. You could of course update more often than that but, I would still recommend a cache setup.
Yes, this could cause you problems now that they are looking to enforce rate limits with Helix in the future. Kraken v5 isn’t quite as limited and the odds of you bumping into problems is probably a bit less. How I handle this is using the MVC pattern and never showing my client ID to the web browser. Everything is done within the Controller and the client ID is never shown in the View.
EDIT: Of course, as the previous answer indicates, you may still have risk during the authentication process. This is why it is best to look at using the OAuth/Bearer tokens for requests.
Yes. Higher rate limits when you get to Helix for OAuth/Bearer tokens because they are tied to a known user (is my impression as to why Twitch raises the rate limits).
Each has separate rate limits. The OAuth/Bearer token method and the Client ID method. You can test this by using software such as curl to perform a lookup both ways and look at the X-Rate-Limit headers returned.
In general, rapid API calls could get you in trouble. Either you will hit a rate limit or be contacted by Twitch. Again, caching is your friend.