I know, that there’s an endpoint to get the number of followers for a single user. However, due to the API limit and due to the fact, that you have to perform one call per user to get their follower count, i would like to suggest to provide the total follower count in the users endpoint, too.
An easy way to get follower counts for multiple users in a single call would be helpful, but until something like that gets added (if at all), there are ways to help with running into API rate limits. For example, using an app access token to raise your limit to 120/min, or if there’s sufficient reason for it you could submit a request to have your limit raised above that.
Another option to think about would be to make use of webhooks, you could make a request to the follower endpoint to get a number, then use the webhook to keep it up to date (with some degree of error due to unfollows not being notified), and maybe if that is accurate enough you will not have to poll the follower endpoint as frequently.
I’ve developed a plugin for a CMS, that lists given streamers including some “basic” info (where i would see the follower count, too) and (if available) informations about their live stream:
Removing the follower count isn’t an option, because the new API already provides less informations, than the previous one (at least for those who are currently not live). The limit increase would be an option, but then, every (or many) user of my plugin would have to request it.
However, i personally don’t like the idea to make X calls for a simple number. It would also be better for the Twitch servers, if people would not have to hammer X calls just for a simple number
Every user of your plugin wouldn’t have to request a limit increase, unless you’re expecting each user to also go through the process of registering an app on Twitch and inputting their client id into your app for it to use.
Also, are you not performing any form of caching? If you take just Monstercat from your example, is your app really making every single end user send a request to Twitch to get Monstercat’s follower count? That’s very inefficient when you could just have a server make a single request, cache the result, and the end users get the data from that cache rather than make redundant calls to Twitch’s API. If you multiply that by the number of duplicate streamers that the end users may be requesting data for and that is quite excessive without caching.
“Every user” means “everyone using the CMS and using the plugin”, so they have to sign up on Twitch and get their own credentials in order to use the plugin.
What you see on the screenshot is cached data. It’s cached for 5 minutes. After 5 minutes, a background job updates the data and the next time you open the site, the fresh data will be displayed.
The process is simple: You define a list of channels you want to display on your site. The background job splits the list into chunks of max. 100 channels per chunk and performs one request per chunk to read the general channel information. Then, i am iterating through the result list and fetch the follower count for every channel. In my example, i made 4 calls until then.
After getting the general informations, i am going to fetch the stream data. The logic is the same: Split the list of channels into chunks, … 5 calls so far.
Last but not least, i am fetching the names of the games, that are currently being played by those channels, which are currently live.
At the end, i’ve made 6 calls for 3 channels, which is “okay”. However, this works max. 13 channels without hitting the API limit. But in relation, i could grab up to 1.000 channel- stream- and game informations at once, if the follower count would be available in the users endpoint (or if i relinguish the follower count). That’s way more than 13
There are exactly 0 duplicates Performance is something i really care about when developing my extensions for the mass.
From the way you describe it, you have each user making their own requests and caching client-side only. When I mentioned duplicate streamers I mean multiple end users all wanting data about the same streamer.
For example, if I was to use your app and also wanted data on Monstercat, GRONKH, and SoftCreatR, it would be redundant for me to make requests to Twitch for that data if you (and however many other users might want that data too) if there’s already someone else requesting it.
If you were to use a server-side cache, you could have an unlimited number of end users all want to see data on Monstercat, but it only ever be 1 request to each of the required endpoints every 5 min, as users would just use the same cache. Being a single point of making requests too means that you could use a single app token with 1,000/min rate limit, or higher, which would account for your needed usage, as well as not requiring every single end user having to get and enter their credentials into your app.
They’re not sharing any data across multiple instances of the framework and I don’t want to act as a proxy for the Twitch API. This could possibly solve the issues described, yes. But that may need more work at my end for a small user base. So I still prefer a solution from the Twitch devs, if possible.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.